![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
silveradept[The December Days theme this year is "Things I Used To Fully Believe About Myself." Some of these things might be familiar, some of them might be things you still believe about yourself, and some of them may be painful and traumatic for you based on your own beliefs and memories. The nice thing about text is that you can step away from it at any point and I won't know.]
#8: "I am not a coder."
The RNG decided to be merciful and give us a lighter topic for this post.
Despite coming of age during the part of history where minicomputers and microcomputers were getting hooked up to networks in great quantity thanks to the Hypetext Transfer Protocol and the accompanying Hypertext Markup Language producing what we now think of as The Internet, but is actually more properly title the World Wide Web (as The Internet encompasses place with different protocols, like Gopher, file transfer protocols (and FTP itself), news readers, and other things built on top of the Transmission Control Protocol / Internet Protocol and the ARPANet network expanded past the Department of Defense and various universities), my interest in technology mostly stayed with games and playing games rather than jumping out into the world of electronics assembly, solder flux, wiring, circuits, circuit boards, and programming.
Which is not to say that my father, the electrical engineer, didn't try to teach me all kinds of things about electronics, their assembly, solder, wiring, circuits, circuit boards, and programming. Things I mostly resisted because I wasn't interested in learning about them at the time, but which I did apparently learn and am able to deploy in service of my own STEAM-related programming, as well as being able to diagnose and fix things (or try) or otherwise have a good enough idea in mind to assemble a circuit and understand how it works. So that when I was building a light painter in vain hope of doing a program of that nature, to know the likely reason why an LED glowed very brightly for a bit and then stopped working was because I let the magic smoke out by running too much direct current to the LED. I was sheepish about going back to the Radio Shack and getting the resistors that had been suggested to me by the clerk when I bought the other components, but I did know that was what I needed, and could calculate about how much resistance I needed to put in the circuit to prevent it from overdriving the LED, and while I can't read a resistor band without a handy color guide, I did get the right resistors and assemble the circuit properly the second time around. And then proceeded to assemble several more on that template, using different-colored LEDs for the painting exercise. The program itself was a flop, but the circuitry worked like a charm.
Which is not to say that I learned nothing about programming and computer operations as a child. Early on in the DOS era, with the computers that could, for example, change their clock speed between 8 and 16 MHz using a keystroke combination, Pops used a program called Automenu to make it easier to select which pieces of software he (and the kids) wanted to use when they were on the computer. Automenu basically abstracted the DOS commands needed to get into the correct working directory and then run the program in question and allowed someone to give more human-readable options to choose from, rather than having to remember potentially arcane commands. And because Automenu had a built-in editor, it was relatively easy to analyze the syntax of any given menu entry and then replicate it, just changing the description and what the commands were to run the program. I was very, very young when I went spelunking in that space to see if I could get my games to run from Automenu. Many of them did, even though I didn't fully understand the DOS syntax that I was replicating. So long as the commands that I had memorized worked, and I put them in the right place, most of the games happily loaded themselves, and I was happy. One of them, a game called Sharkey's 3D Pool, did not, and the error message that it gave me was detailed and helpful enough for me to conclude the game itself needed a larger chunk of memory than was available while running Automenu. (TSRs, friend, always fucking up your memory allotments.) So I asked Pops for help about what I was doing wrong. The program loaded, but then it exited with the error about being out of memory, and I wasn't sure what I could do to fix that. I think he might have been suitably impressed that I had grasped enough of what was going on to successfully replicate what had worked before in Automenu and extend it to new things that he was willing to help point me in the right direction of where I needed to go next. At which point I found out that to successfully run Sharkey's 3D Pool, I had to leave the safety of Automenu and free up the resources it was taking up and directly use the command line to get to where the executable was and run it. In its place, however, I had been taught the Change Directory command (cd), which allowed me to traverse the filesystem directly and access other disk drives while I was at it.
This was also the era where BASIC programs would be printed in books for kids to type into their own computers and run to see what they did. I did a few of those, too, although it was obviously easier to do BASIC things on Commodores and Apples at the time. DOS needed a program to run for that, I believe. But if those programs that I carefully typed in and then ran for myself, once I had an idea of how they worked, I'd go tinker around in them to see what I could do by changing text or numbers and then running it again to see how it changed things. Even for the games that supposedly had difficulty levels of their own, it was often easy enough to go into the source that you had typed and tweak the numbers until you had the right amount of satisfying challenge for yourself, or to do ridiculous steamrolling of your puny opponent.
So a lot of my approach to technology, electronics, and code is not only in the service of getting games to run (and trying to figure out which floppy was free to serve as the boot disk this time), but also is an experimenter, tinkerer approach that works best when I see an idea and then say "but what if we did it this way, instead?" There's almost always learning of some sort that happens, where the concepts underneath things get exposed and examined, and then get understood and integrated as the desired tinkering moves farther and farther afield from the original and increases in complexity. For contrast, I'm putting in someone who is trying to build a sort of curriculum for use with kids to not only let them experiment with Free/Libre Open Source Software, but also to install the values of FLO into kids. As a child of the command line myself, I like the idea of starting there and expanding outward, but looking at this and hearing the child and parent talking together about the successes so far, I realized the thing that I didn't hear enough about was the scaffolding part. One of those Libre values is that people should be able to examine and modify existing programs, and I think that requires following the interest of the learner and then putting in the explanation about Libre values when they run into something they want to modify but can't. Or when they run into the paywalls and micro-transactions for something they and their friends are playing together. But also that the adult in the scaffolding relationship has work to do to see where the child might benefit from the use of FLOSS or learning coding languages to continue pursuing their interests.
Okay, fast forward from the time of BASIC programs, variable tinkering, messing with some .ini files, to the era of HTTP and forum games and websites and, yes, GeoCities, before it was acquired by Yahoo! and shuttered. (We're not quite to the era where we start blaming Brad in his dorm room, or or where Flash is ubiquitous, but we're not that far away from it, either.) I realize that HTML is not a programming language, as such, but even though it is a markup language to tell a browser how to render a document and it has an accompanying styling language in the implementation of Cascading Style Sheets, it really seemed like one with all the ways that will pages could be rendered with those two languages working hand in hand. (The actual programming and scripting languages of the web at this time are Perl, PHP, and JavaScript, assuming my memory isn't terribly faulty.) GeoCities offered people an "address" on the Web, like they were neighbors on street blocks, and some space to experiment with HTML and build all of those un-slick, animated GIF-encrusted pages to declare our love for things, to have guestbooks for visitors and webrings to find similar interests across sites, and to realize just how badly Frontpage and a lot of WYSIWYG editors abused the HTML specification to produce the visual elements they wanted. By the standards of today, those pages were terrible from design standards (and also HTML 3 and 4, without a lot of the multimedia integration that HTML 5 has), but they also had exactly the right environment for experimentation and learning. Make a change, reload the page, see how it changes. Develop entirely offline and perfect your styling along with your content, and then, when ready, upload it for the world to see. (And then make some fixes because inevitably something went weird for someone, which usually meant something like "they were viewing it in a non-optimal resolution!") It was amateur, both in the sense that the old hands and the professionals would use with their faces curled in a sneer, yet another member of the Eternal September now interacting with more than just the newsreaders, but also in that people would design and build things they found aesthetically pleasing by not having to confirm to a style guide or a corporation's conservatism or an advertiser's diktat.
I learned a lot of HTML in those days, and that knowledge sticks with me even in the much slicker world we are in, because those tags are still found and used when I'm constructing entries, or stories, or performing maintenance on the archive of my professional accomplishments. A fair amount of the CSS stuck, too, even if I don't go diving into Style System code and I use an already-constructed CSS framework for that professional archive. When I hit grad school and had to learn to construct a database-backed website that used Ruby on Rails for AJAX, XHTML, and CSS, the only thing that I needed to learn-learn was the Ruby on Rails component, and that made it much easier, since I was only learning one programming language and associated framework rather than a programming language, a markup language, and a style sheet language all at once. And because I needed tools that would make developing and testing that website easier, I built a Linux install on a second hard drive and started learning how to use that as my primary computer driver, because Windows development was kind of miserable for me. So I ended up, as I suspect a lot of Linux people do, in the hybrid space of having GUI tools and shell tools and using whichever suits best at the time.
I tried to bring that knowledge into my work, as well, but I ran into the problem that IT (probably correctly) didn't want the staff poking around in their production databases, and (probably wrongly) didn't provide us with snapshot copies of databases so that were could learn and practice skills and do more sophisticated data analysis and filtering on our own, rather than petitioning them to create a report for us and demonstrating enough people wanted that report for their own purposes for it to be worth the time and effort to build and maintain it. This, despite having written an analyzer tool that would be very helpful for me when I have to make decisions about collection maintenance, I can't use it, because I don't have access to the real data, not am I allowed to run programming scripts or install environments or run anything not totally approved by IT on my work machine. These are sound security decisions. I do not blame IT for making them. I just want the ability to put my thought process into code and run it, so that I don't have to painstakingly shuttle all the books back and scan them individually and then put back the ones that are doing fine. Instead, I can leaf through all of the ones not on the list to check for damage and then bring the marginal ones back for further analysis. (There's those FLO values showing up again: I want my computers to do what I tell them and to be able to use tools that let me tell them what I want, instead of being forced to do it someone else's way because that's the only way that's been approved.)
Had you asked me if I was a coder at any point in this narrative, I would have told you no, because I didn't program for a living, nor did I spend significant amount of my free time programming or even building web pages and sites. Even after I became a fully accredited information professional and learned many of the secrets of translating human to machine and back again, if you asked me whether I was a coder, I still would have told you no, because I'm still not writing code as a hobbyist or as a professional, pay no attention at all to the increasing number of Linux-based systems that I'm juggling and keeping updated. No, no, I'm still a user first, just one with better search skills who can more rapidly find someone else's code snippet and use it for my purpose, or find a code snippet that does 95-99% of what I do and that I can study and poke at it long enough to extend it out a little to include my use case. Or troubleshoot when things go wrong on a system. Or install Arch Linux. (Multiple times, at this point in my life.) Or take an end-of-life Chromebook and turn it into a functional Linux laptop. (Also multiple times, at this point.) These are still things where I say even now "no, no, I'm a user, I'm following the install instructions / blog posts and letting the scripts do the heavy work. I'm just tinkering around the edges with the configuration files."
I think it become the most obvious how much I was kidding myself when I got the Home Assistant Blue as a present and then began to do things, fix things, extend functionality, write entirely new functions, bridge devices with communication protocols and pipes, and otherwise make the Home Assistant do things that it can do, but didn't necessarily have built-in functions for all of those things. Or build things to feed the Home Assistant data in a form it wanted so I could then ship that data to somewhere else, and write some mixed programming code and HTML to get it to display correctly on the target device, as well as learning a little bit more about regular expressions and their use in the process. But I'm still a user, right? I still don't produce code as a profession, and I don't build scripts and run them on a daily basis, right? I just put them together when I need to do something, and I do it with a lot of consulting references and adapting already-created scripts. That's not coding, right?
On the other hand, I have stolen a couple marches on my workplace, though, to make certain tasks easier and more automated in the last year. There was the project where we needed to take all of the under-17 cards that had become 17-and-over cards and sort them into their proper places as either Adults or Reciprocal Borrowers, which was going to be an aaaawful lot of hand-changing records, one at a time, and crossing them off the list. Cue the information professional going "There's got to be a better way than that," and getting my hands dirty in the power search options and filtering decisions until I've created a search of all the people who fit the criteria of needing their cards updated and dumping it into a record set. Then double-checking my work to make sure I've got the right idea in mind, because if I screw this up, it's a change in production (I told you IT really should keep backup snapshots so we can test these ideas before deploying them) and then, when it seems to be right, crossing my fingers and doing the bulk changes. Which work. And pass spot tests from the list to make sure things that were on the list were appropriately changed. And then I do it again with the other locations in my region, to be really sure that the process works. Which it still does, and then I publicize the method to everyone else and save them a shit-ton of time doing their own changes.
And because I was just setting it up for 2024 yesterday, the other thing I've done to make life easier is change an Excel template that the organization uses to record statistics that come in by voicemail or e-mail to the reference services accounts. (Which will eventually be counting an expanded set of interactions as several different services are consolidated into one.) Turns out that Excel understands how to increment dates, and so I could set up a chain of cells formatted for dates whose formula was "look at the cell before you in the chain, add one." Rather than having to input all the days of the year by hand, using this chain, I only have to input the first day of the month in the right place, and then trim off any date cells before that day and any date cells after the last day of the month. I only input 12 dates, and I push the delete key a few times to remove the unnecessary dates, and I've set up an entire year's worth of statistics collection in fifteen minutes tops, including copying the template cells twelve times, one for each month's tab. If Excel ever breaks that functionality, I'll have to do something more clever, assuming I'm still working with this organization, but that saves at least a half-hour to an hour every year that could be put to more productive use. (And makes sure that there aren't any typos, either.)
But neither of those things is coding, either, right? Putting in Excel formulas and building search query syntax isn't programming, is it?
As it turns out with a lot of these "I don't" or "I can't" statements, the correct response to me saying that is to interrogate what I mean when I say that. When you calibrate to "can create ex nihilo," you think that you're not doing something you absolutely are. And, as I have snarled at least a few times as I have gotten older, there are very few times in your life or your work where you will be expected to do something completely from scratch and memory, without references, scaffolds, or materials to consult to help you build the thing. Pops mentioned that for many of the examinations he undertook, the professors would allow someone to write as many formulae as they wanted on the cheat sheet they could bring with them. Because the point was not that you had the formulae memorized, the point was that you knew in what situations to use them. (Insert the joke about the six thousand dollar chalk mark here.)
I do not code professionally. I do not consider myself anything more than an amateur at many things related to code and its creation. But I can code, or learn how to do that thing in code, and that makes me a coder. (And that makes a lot of other people coders, too, even if they will be met by gatekeepers telling them Stallman says you must code in this obscure a language to ride the ride.)
#8: "I am not a coder."
The RNG decided to be merciful and give us a lighter topic for this post.
Despite coming of age during the part of history where minicomputers and microcomputers were getting hooked up to networks in great quantity thanks to the Hypetext Transfer Protocol and the accompanying Hypertext Markup Language producing what we now think of as The Internet, but is actually more properly title the World Wide Web (as The Internet encompasses place with different protocols, like Gopher, file transfer protocols (and FTP itself), news readers, and other things built on top of the Transmission Control Protocol / Internet Protocol and the ARPANet network expanded past the Department of Defense and various universities), my interest in technology mostly stayed with games and playing games rather than jumping out into the world of electronics assembly, solder flux, wiring, circuits, circuit boards, and programming.
Which is not to say that my father, the electrical engineer, didn't try to teach me all kinds of things about electronics, their assembly, solder, wiring, circuits, circuit boards, and programming. Things I mostly resisted because I wasn't interested in learning about them at the time, but which I did apparently learn and am able to deploy in service of my own STEAM-related programming, as well as being able to diagnose and fix things (or try) or otherwise have a good enough idea in mind to assemble a circuit and understand how it works. So that when I was building a light painter in vain hope of doing a program of that nature, to know the likely reason why an LED glowed very brightly for a bit and then stopped working was because I let the magic smoke out by running too much direct current to the LED. I was sheepish about going back to the Radio Shack and getting the resistors that had been suggested to me by the clerk when I bought the other components, but I did know that was what I needed, and could calculate about how much resistance I needed to put in the circuit to prevent it from overdriving the LED, and while I can't read a resistor band without a handy color guide, I did get the right resistors and assemble the circuit properly the second time around. And then proceeded to assemble several more on that template, using different-colored LEDs for the painting exercise. The program itself was a flop, but the circuitry worked like a charm.
Which is not to say that I learned nothing about programming and computer operations as a child. Early on in the DOS era, with the computers that could, for example, change their clock speed between 8 and 16 MHz using a keystroke combination, Pops used a program called Automenu to make it easier to select which pieces of software he (and the kids) wanted to use when they were on the computer. Automenu basically abstracted the DOS commands needed to get into the correct working directory and then run the program in question and allowed someone to give more human-readable options to choose from, rather than having to remember potentially arcane commands. And because Automenu had a built-in editor, it was relatively easy to analyze the syntax of any given menu entry and then replicate it, just changing the description and what the commands were to run the program. I was very, very young when I went spelunking in that space to see if I could get my games to run from Automenu. Many of them did, even though I didn't fully understand the DOS syntax that I was replicating. So long as the commands that I had memorized worked, and I put them in the right place, most of the games happily loaded themselves, and I was happy. One of them, a game called Sharkey's 3D Pool, did not, and the error message that it gave me was detailed and helpful enough for me to conclude the game itself needed a larger chunk of memory than was available while running Automenu. (TSRs, friend, always fucking up your memory allotments.) So I asked Pops for help about what I was doing wrong. The program loaded, but then it exited with the error about being out of memory, and I wasn't sure what I could do to fix that. I think he might have been suitably impressed that I had grasped enough of what was going on to successfully replicate what had worked before in Automenu and extend it to new things that he was willing to help point me in the right direction of where I needed to go next. At which point I found out that to successfully run Sharkey's 3D Pool, I had to leave the safety of Automenu and free up the resources it was taking up and directly use the command line to get to where the executable was and run it. In its place, however, I had been taught the Change Directory command (cd), which allowed me to traverse the filesystem directly and access other disk drives while I was at it.
This was also the era where BASIC programs would be printed in books for kids to type into their own computers and run to see what they did. I did a few of those, too, although it was obviously easier to do BASIC things on Commodores and Apples at the time. DOS needed a program to run for that, I believe. But if those programs that I carefully typed in and then ran for myself, once I had an idea of how they worked, I'd go tinker around in them to see what I could do by changing text or numbers and then running it again to see how it changed things. Even for the games that supposedly had difficulty levels of their own, it was often easy enough to go into the source that you had typed and tweak the numbers until you had the right amount of satisfying challenge for yourself, or to do ridiculous steamrolling of your puny opponent.
So a lot of my approach to technology, electronics, and code is not only in the service of getting games to run (and trying to figure out which floppy was free to serve as the boot disk this time), but also is an experimenter, tinkerer approach that works best when I see an idea and then say "but what if we did it this way, instead?" There's almost always learning of some sort that happens, where the concepts underneath things get exposed and examined, and then get understood and integrated as the desired tinkering moves farther and farther afield from the original and increases in complexity. For contrast, I'm putting in someone who is trying to build a sort of curriculum for use with kids to not only let them experiment with Free/Libre Open Source Software, but also to install the values of FLO into kids. As a child of the command line myself, I like the idea of starting there and expanding outward, but looking at this and hearing the child and parent talking together about the successes so far, I realized the thing that I didn't hear enough about was the scaffolding part. One of those Libre values is that people should be able to examine and modify existing programs, and I think that requires following the interest of the learner and then putting in the explanation about Libre values when they run into something they want to modify but can't. Or when they run into the paywalls and micro-transactions for something they and their friends are playing together. But also that the adult in the scaffolding relationship has work to do to see where the child might benefit from the use of FLOSS or learning coding languages to continue pursuing their interests.
Okay, fast forward from the time of BASIC programs, variable tinkering, messing with some .ini files, to the era of HTTP and forum games and websites and, yes, GeoCities, before it was acquired by Yahoo! and shuttered. (We're not quite to the era where we start blaming Brad in his dorm room, or or where Flash is ubiquitous, but we're not that far away from it, either.) I realize that HTML is not a programming language, as such, but even though it is a markup language to tell a browser how to render a document and it has an accompanying styling language in the implementation of Cascading Style Sheets, it really seemed like one with all the ways that will pages could be rendered with those two languages working hand in hand. (The actual programming and scripting languages of the web at this time are Perl, PHP, and JavaScript, assuming my memory isn't terribly faulty.) GeoCities offered people an "address" on the Web, like they were neighbors on street blocks, and some space to experiment with HTML and build all of those un-slick, animated GIF-encrusted pages to declare our love for things, to have guestbooks for visitors and webrings to find similar interests across sites, and to realize just how badly Frontpage and a lot of WYSIWYG editors abused the HTML specification to produce the visual elements they wanted. By the standards of today, those pages were terrible from design standards (and also HTML 3 and 4, without a lot of the multimedia integration that HTML 5 has), but they also had exactly the right environment for experimentation and learning. Make a change, reload the page, see how it changes. Develop entirely offline and perfect your styling along with your content, and then, when ready, upload it for the world to see. (And then make some fixes because inevitably something went weird for someone, which usually meant something like "they were viewing it in a non-optimal resolution!") It was amateur, both in the sense that the old hands and the professionals would use with their faces curled in a sneer, yet another member of the Eternal September now interacting with more than just the newsreaders, but also in that people would design and build things they found aesthetically pleasing by not having to confirm to a style guide or a corporation's conservatism or an advertiser's diktat.
I learned a lot of HTML in those days, and that knowledge sticks with me even in the much slicker world we are in, because those tags are still found and used when I'm constructing entries, or stories, or performing maintenance on the archive of my professional accomplishments. A fair amount of the CSS stuck, too, even if I don't go diving into Style System code and I use an already-constructed CSS framework for that professional archive. When I hit grad school and had to learn to construct a database-backed website that used Ruby on Rails for AJAX, XHTML, and CSS, the only thing that I needed to learn-learn was the Ruby on Rails component, and that made it much easier, since I was only learning one programming language and associated framework rather than a programming language, a markup language, and a style sheet language all at once. And because I needed tools that would make developing and testing that website easier, I built a Linux install on a second hard drive and started learning how to use that as my primary computer driver, because Windows development was kind of miserable for me. So I ended up, as I suspect a lot of Linux people do, in the hybrid space of having GUI tools and shell tools and using whichever suits best at the time.
I tried to bring that knowledge into my work, as well, but I ran into the problem that IT (probably correctly) didn't want the staff poking around in their production databases, and (probably wrongly) didn't provide us with snapshot copies of databases so that were could learn and practice skills and do more sophisticated data analysis and filtering on our own, rather than petitioning them to create a report for us and demonstrating enough people wanted that report for their own purposes for it to be worth the time and effort to build and maintain it. This, despite having written an analyzer tool that would be very helpful for me when I have to make decisions about collection maintenance, I can't use it, because I don't have access to the real data, not am I allowed to run programming scripts or install environments or run anything not totally approved by IT on my work machine. These are sound security decisions. I do not blame IT for making them. I just want the ability to put my thought process into code and run it, so that I don't have to painstakingly shuttle all the books back and scan them individually and then put back the ones that are doing fine. Instead, I can leaf through all of the ones not on the list to check for damage and then bring the marginal ones back for further analysis. (There's those FLO values showing up again: I want my computers to do what I tell them and to be able to use tools that let me tell them what I want, instead of being forced to do it someone else's way because that's the only way that's been approved.)
Had you asked me if I was a coder at any point in this narrative, I would have told you no, because I didn't program for a living, nor did I spend significant amount of my free time programming or even building web pages and sites. Even after I became a fully accredited information professional and learned many of the secrets of translating human to machine and back again, if you asked me whether I was a coder, I still would have told you no, because I'm still not writing code as a hobbyist or as a professional, pay no attention at all to the increasing number of Linux-based systems that I'm juggling and keeping updated. No, no, I'm still a user first, just one with better search skills who can more rapidly find someone else's code snippet and use it for my purpose, or find a code snippet that does 95-99% of what I do and that I can study and poke at it long enough to extend it out a little to include my use case. Or troubleshoot when things go wrong on a system. Or install Arch Linux. (Multiple times, at this point in my life.) Or take an end-of-life Chromebook and turn it into a functional Linux laptop. (Also multiple times, at this point.) These are still things where I say even now "no, no, I'm a user, I'm following the install instructions / blog posts and letting the scripts do the heavy work. I'm just tinkering around the edges with the configuration files."
I think it become the most obvious how much I was kidding myself when I got the Home Assistant Blue as a present and then began to do things, fix things, extend functionality, write entirely new functions, bridge devices with communication protocols and pipes, and otherwise make the Home Assistant do things that it can do, but didn't necessarily have built-in functions for all of those things. Or build things to feed the Home Assistant data in a form it wanted so I could then ship that data to somewhere else, and write some mixed programming code and HTML to get it to display correctly on the target device, as well as learning a little bit more about regular expressions and their use in the process. But I'm still a user, right? I still don't produce code as a profession, and I don't build scripts and run them on a daily basis, right? I just put them together when I need to do something, and I do it with a lot of consulting references and adapting already-created scripts. That's not coding, right?
On the other hand, I have stolen a couple marches on my workplace, though, to make certain tasks easier and more automated in the last year. There was the project where we needed to take all of the under-17 cards that had become 17-and-over cards and sort them into their proper places as either Adults or Reciprocal Borrowers, which was going to be an aaaawful lot of hand-changing records, one at a time, and crossing them off the list. Cue the information professional going "There's got to be a better way than that," and getting my hands dirty in the power search options and filtering decisions until I've created a search of all the people who fit the criteria of needing their cards updated and dumping it into a record set. Then double-checking my work to make sure I've got the right idea in mind, because if I screw this up, it's a change in production (I told you IT really should keep backup snapshots so we can test these ideas before deploying them) and then, when it seems to be right, crossing my fingers and doing the bulk changes. Which work. And pass spot tests from the list to make sure things that were on the list were appropriately changed. And then I do it again with the other locations in my region, to be really sure that the process works. Which it still does, and then I publicize the method to everyone else and save them a shit-ton of time doing their own changes.
And because I was just setting it up for 2024 yesterday, the other thing I've done to make life easier is change an Excel template that the organization uses to record statistics that come in by voicemail or e-mail to the reference services accounts. (Which will eventually be counting an expanded set of interactions as several different services are consolidated into one.) Turns out that Excel understands how to increment dates, and so I could set up a chain of cells formatted for dates whose formula was "look at the cell before you in the chain, add one." Rather than having to input all the days of the year by hand, using this chain, I only have to input the first day of the month in the right place, and then trim off any date cells before that day and any date cells after the last day of the month. I only input 12 dates, and I push the delete key a few times to remove the unnecessary dates, and I've set up an entire year's worth of statistics collection in fifteen minutes tops, including copying the template cells twelve times, one for each month's tab. If Excel ever breaks that functionality, I'll have to do something more clever, assuming I'm still working with this organization, but that saves at least a half-hour to an hour every year that could be put to more productive use. (And makes sure that there aren't any typos, either.)
But neither of those things is coding, either, right? Putting in Excel formulas and building search query syntax isn't programming, is it?
As it turns out with a lot of these "I don't" or "I can't" statements, the correct response to me saying that is to interrogate what I mean when I say that. When you calibrate to "can create ex nihilo," you think that you're not doing something you absolutely are. And, as I have snarled at least a few times as I have gotten older, there are very few times in your life or your work where you will be expected to do something completely from scratch and memory, without references, scaffolds, or materials to consult to help you build the thing. Pops mentioned that for many of the examinations he undertook, the professors would allow someone to write as many formulae as they wanted on the cheat sheet they could bring with them. Because the point was not that you had the formulae memorized, the point was that you knew in what situations to use them. (Insert the joke about the six thousand dollar chalk mark here.)
I do not code professionally. I do not consider myself anything more than an amateur at many things related to code and its creation. But I can code, or learn how to do that thing in code, and that makes me a coder. (And that makes a lot of other people coders, too, even if they will be met by gatekeepers telling them Stallman says you must code in this obscure a language to ride the ride.)
no subject
Date: 2023-12-09 01:50 am (UTC)