![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
silveradept[This Year's December Days Theme is Community, and all the forms that it takes. If you have some suggestions about what communities I'm part of (or that you think I'm part of) that would be worth a look, let me know in the comments.]
I expected more of the technical things to go early in this sequence, but the randomizer does what the randomizer does.
I think the community of people who are programmers is another one of those "bigger on the inside" groups, where there's a set of people who have credentials, computer science degrees, or do it as their job, or have a formal structure they work within, or have published their works, or work on big projects, that most people would say, "yep, those are programmers," and then there's a bigger group outside of them who are people who regularly do code-related things but wouldn't consider themselves to be programmers, either because what they do doesn't match that smaller group, because they don't want to be associated with that group, or because they don't do it often enough to think they're part of the group.
Researchers and data scientists are almost always part of the programmer community, since they have to run and write code to turn their raw data into analysis and different forms that might suggest useful further avenues of inquiry, or lines of best fit, or other such things that can be computed manually, but do better by having computers do it. And there are definitely librarians and archivists who do code work, because their systems are large, interlinked, and often obtuse about producing useful statistics, records, or processes that will be helpful in determining what's getting used, what's not, and where good directions of collection development could go. And, more often than not, those librarians have to deal with interfacing with other resources, their proxy systems, and other such fun things, whether they do or don't have an IT team to also help with that.
Where I think the biggest groups of people who don't recognize their programmer skills are those office wizards who can make spreadsheets do strange things, have macros and mail merges and templated documents ready to go, and can otherwise make the office suite do everything that it is advertised to do, and a few things that it might not be advertised to do. Microsoft Excel's formula language has been Turing-complete since 2021, and in that linked post, the people writing the post refer to it as a programming language. Some of the Easter eggs that have been developed in Microsoft Office products certainly showcase what those software products are capable of, although perhaps the most cursed application developed so far is in the family of using Microsoft Excel as a backend for Representational State Transfer items, which also involves a lot of Visual Basic and interoperation from the C programming language. Regardless of my opinion about the can/should divide when it comes to embedded scripting, macros, and the rest of the ways that documents can become dynamic instead of static, the people who do that kind of work are doing a fair amount of programming, just not in a language that many people would recognize.
I refer to myself here as part of the "Script Kiddie Division," because a large amount of the interactions I have had with code, or with modifying code, has been taking someone else's work and either using it in my context, or making a tweak or two to it to suit my purposes and otherwise running it mostly unmodified, in the same way that the script kiddie finds the tools of others and then deploys them, mostly unmodified, to do whatever mischief or malice they want to wreak upon the Internet, whether for lulz or for other purposes. I do these things without necessarily understanding them at the code level, but instead because they are advertised as working, they claim to do the thing that I want, and they are available to test and see if they do both work and do the thing I want them to do, or can be convinced to do the thing I want them to do.
This tendency started early, as I am of the age where entire programs in BASIC would be printed in "beginning to code" books, in the same way that they now use Scratch or other block-based interfaces or languages like Python to do the same. I've also talked before about studying Automenu as a child and trying to replicate its syntax to extend it to other games I wanted to play. Game Genies also had the suggestion that any combination of their letter interface could work, if someone were willing to test them out, but they also had a code book with the ones that were known to work, because most people don't want to have to write down all their code choices and observe any effects of what might happen. If, instead, we knew which registers and memory bits were being modified by each of the letter combinations, we could probably do a better job of figuring out which strings would be more fruitful than others. (Although we might not find some of the multi-line codes that were present.) It also turned out, thanks to the knowledge of The Internet, that I could modify the rules.ini file for a game like Command and Conquer: Red Alert, and thus change the gameplay experience for my single-player gaming. (I only changed one thing, honestly - I made the ore mining give three times as much income as it was initially set. So, presumably, it did that for both sides, so I wasn't giving myself an unfair advantage.) In any case, even though I knew I would not be as good or as generally-knowledgeable about computers and programming as some of my friends, I figured that I would always learn enough (usually to get a game running or to activate a useful cheat) and that would be something that might come in handy later. (There's a name for this! It's called just-in-time learning.)
So, with a little bit of BASIC and a few bits of here and there, my first brush with having to do a significant amount of programming was when I built a personal web site in the era of free web sites being available for people to build with. And that was less programming as it was using a markup language to build a static site, but it did teach me useful concepts like the need to close your tags, check your brackets, and make sure that you leave comments to yourself about what you're doing here so that when you come back to it, you understand what's happened. (The site I have for holding my professional CV and several of my publications and presentations is similarly static, and just upgraded to frames because I was tired of having all of my navigation on every page. Which produces the problem of pages without navigation on them if you go to them directly. I haven't solved that one, yet, but I suspect that if I were to try and do it, there would be a lot more Javascript on the site, and I'm trying to keep that to a minimum and only use HTML and CSS as much as possible.) Learning how to build, update, fix errors, fight bugs, try to puzzle out the box model, and test out the various tags and selectors and what they did gave me some decent concepts to work with, at least for messing around on a personal site. I didn't do much for it other than use it as a personal sandbox, and in that era, where tags like blink and marquee were still in use, there were a lot of personal sandboxes around, or sites built with one specific idea in mind. (I could have gotten into fic here, had I made the right connections, but alas, it was not to be.)
My first thorough introduction to programming was in graduate school, where one of my foundations courses required that I program a real database-backed application that had a web interface and a form and everything. The graduate student instructor for the course looked at some of my early code options, with a long sequence of nested if statements, and then asked me what the last language I had programmed in. "BASIC," I replied cheerily, and he then proceeded to explain to me things like && syntax, where I could get all of my if conditions into one line, rather than spending a line on each one of them. I still sometimes like to write out all of my if conditions, one to each line, with indentation, to make sure that I have the logic flow all together, before moving things into a more condensed form. It also helps me make sure that I'm at the right levels of work if I write it all out and then collapse later. In any case, while I wouldn't call the application that I ended up writing pretty in any kind of way, it functioned, and it met the requirements of the course. So I learned a little bit about Ruby and the Rails framework for it. As I now look at that project, I'm not very fond of the way that Rails chopped up a lot of my complete pages into partials, because the Asynchronous Javascript and XML (AJAX) part of it that would rewrite what was displayed on the screen through manipulation of the Document Object Model (DOM) needed to have each of the possible elements that could be on the page separated out into their own partial pages, to be stitched and restitched together by the Rails framework and webserver. Having to remember where I'd stashed a particular partial, and what I'd named it, and having to remember what was in my database and the relations between fields and tables was not very great for me. I'd had to do all the bits that were planning out the database schema, and naming the tables, and figuring out their relationships, all as assignments in the class, so I wasn't flying completely without maps and instrumentation, but it was definitely difficult to keep all the moving parts in my head as I was programming, creating, and troubleshooting.
Having gone through it, though, I tried to put my programming talents to use in my workplace, and that pretty well went nowhere, not just because there weren't, say, test servers to run code ideas against and see if I couldn't build myself a useful list, but also because when I was trying to build something useful, like a way of randomizing participants in a game tournament that didn't have randomization or tournament modes, I got into difficulty with my manager because other staff persons were saying that I wasn't paying attention to the participants in the programming, when the programming was letting them do what they've done best in gaming, making sure that they traded controllers regularly enough, and trying to make sure that tempers didn't flare too greatly. Of course, these are the same people and manager who likely disapproved of my occasionally wading in to the fray with the participants. In any case, the person who would have been encouraged to keep with the coding, and given tools and playgrounds to do work with, is a very different, and possibly less traumatized, person regarding their workplace and managerial competence. Regrettably, there's still not really any playgrounds or sandboxes for staff to test out ideas they might have, whether in code or otherwise, because our IT department is run with shoestrings and electrical tape, just like every other part of operations in a chronically underfunded organization.
At that point, I mostly just went into brumation about code. I was using stuff, sure, but the closest project that I could have contributed to would have been Dreamwidth, and I still wasn't willing to learn cursed Perl or even more cursed BML to do much to contribute on that end. (Also, because even though I know Dreamwidth is an environment that wants to be welcome to beginners and to teach them what they need to know on it, I felt intimidated by all of these people who did know what they were doing. Yes, this is where you insert Things Real Dreamwidth Programmers Do.) And also, that was a significant part of my life where I had someone siphoning a significant amount of my time, energy, and cope for her own purposes, so even if I had wanted to get involved, I probably would have been excoriated over it, or have it looked at with suspicion. My ex wanted to try and understand me better, which was fine, but she often tried to understand me better in a way that would get to us doing things together, when some of the things I wanted to do were me things, either at the outset, or always. Me, with other people who were not her, was rarely-to-never something that she approved of, and if she did, it almsot always came with strings and costs.
Fast forward more, because we're still not doing much with code at work, although I am maintaining the EeePCs and putting them to work with some code that someone else wrote out for me to display slideshows and otherwise keeping them running on stripped-down Linuxes, and then I get to a different relationship, where not only am I running my Linux box full time and out in the open, there are little gadgets that keep appearing because other people also would like to have computers, and we would like them to have network access, and there's a certain amount of sysadminning that I'm doing anyway. Also, I'm continuing to maintain my professional website and catalogue my CV and all the achievements that have happened in my career so far, so I'm getting back into the nature of website stuff with a service that gives me about the same level of sophistication that my sandbox website had, because Old Web is still sometimes looked upon fondly. All of these things, save maybe the website pages, are still stuff of the nature of using other people's code and scripts for the grand majority of those tasks, but it's getting comfortable with stuff and once again marveling at the flexibility of a general-purpose computer or two. Then the home automation toy shows up, and the code bits begin again in earnest, because now there's some amount of needing to get stuff to work the way that everyone here wants it to. Getting voice assistants to work properly, getting intent scripts to go well, automating, configuring, and eventually putting together scripts and files and using the tools available to me so that stuff goes well. There's lots and lots of just-in-time learning going on now, as well as so much grabbing things and seeing if I can make them work with a few modifications, or to get something to work with what the code wants and expects. Still very much the Script Kiddie Division for most things, building on the back of a really strong codebase that already handles a lot of the devices and their outputs in a nearly plug-and-play manner, and some bits that are dropping in other pieces of code until they work, even if I don't fully understand the hows or whys of their working.
And then. A few weeks ago, in one of my social spaces, someone was complaining about having exported lists of prompts from certain kinds of exchanges, and how it was going to take a very long time to put them into a spreadsheet so they could be searched and manipulated, one prompt at a time. Everyone agreed that doing it one line at a time was going to be miserable. I looked at the form of the prompt lists, and I thought about, and then described, what I expected a script or automation to do with such a thing, and what the output of it would look like. At which point I realized that if I could describe the thing and what it was supposed to do, I probably could also create the thing, since it was essentially text manipulation. After fiddling a bit to see if it would work well in shell scripting (no), I settled on Python, since it's supposed to be well-documented and well-tutorialed and I would have a decent chance of understanding what I was doing without having to do a lot of messing around. And then, piece by piece, with search engine queries to help me find the right form and function, I built scripts to ingest a file, line by line, store elements from read-in lines in an array, concatenate the elements together that would output a desired line, write out the line to an output file, and then start it all again with the next line.
The script went through a few revisions to make things easier for me, but most of what I was doing was harmonizing the inputs, and then examining the outputs, noting where there were obvious problems, harmonizing the inputs again, re-running the script, and then, when satisfied, taking the output files and renaming them so that a new input file could be brought in and processed. It took me a long weekend's worth of time, including breaks for work and sleep, to process the input files, then correct things and reprocess until I was satisfied. When all was done, two scripts of less than 50 lines (discounting comments and whitespace) turned about 110k-115k of input lines (the easy way of doing line count on the files overcounts the number of real lines, because of things like random line breaks in the middle of prompt lists, index lines, header lines, and other things that were not actual prompts) into a little over 412k of output lines (which might be a small undercount, because I definitely didn't spot all of the situations where something didn't render exactly correctly unless it was big and obvious.)
I did that thing. From scratch, with consultation of reference works, in proper engineering form. And got the thrill of watching lines scroll by on my console as the script did the work. I did that thing. I want to find faults with it, so that I can claim it wasn't real programming, or discount it as not perfect, and therefore, not worth saying anything about, because having to admit to my own competence in things is sometimes terrifying. (Mostly in the department of "Is someone else going to come and piss on my parade?") It worked, and it worked in the way that computers do, and I built it, and this is probably what people get as the feeling of how powerful working with code actually is, when you can put your idea into existence and you find out that it works just fine. And that you've accumulated enough knowledge (or enough knowing where to look for things) that the code does run, does work, you can fix the problems, and then you can look at the end result and go "Huh, I nearly quadrupled the number of lines of output compared to input, but they're in exactly the form that someone wants so they can do further manipulation with it. And it was a pair of very small scripts that did all of this heavy lifting."
So, yeah, I'm still probably going to mostly reuse other people's work when I can find it and if it does the job I would like it to, or tweak their things to my purposes, but it's also something to know that I can do the thing that I usually set as my bar for "actual skill" - creating a thing completely out of nothing and successfully having it do what I wanted it to.
I expected more of the technical things to go early in this sequence, but the randomizer does what the randomizer does.
I think the community of people who are programmers is another one of those "bigger on the inside" groups, where there's a set of people who have credentials, computer science degrees, or do it as their job, or have a formal structure they work within, or have published their works, or work on big projects, that most people would say, "yep, those are programmers," and then there's a bigger group outside of them who are people who regularly do code-related things but wouldn't consider themselves to be programmers, either because what they do doesn't match that smaller group, because they don't want to be associated with that group, or because they don't do it often enough to think they're part of the group.
Researchers and data scientists are almost always part of the programmer community, since they have to run and write code to turn their raw data into analysis and different forms that might suggest useful further avenues of inquiry, or lines of best fit, or other such things that can be computed manually, but do better by having computers do it. And there are definitely librarians and archivists who do code work, because their systems are large, interlinked, and often obtuse about producing useful statistics, records, or processes that will be helpful in determining what's getting used, what's not, and where good directions of collection development could go. And, more often than not, those librarians have to deal with interfacing with other resources, their proxy systems, and other such fun things, whether they do or don't have an IT team to also help with that.
Where I think the biggest groups of people who don't recognize their programmer skills are those office wizards who can make spreadsheets do strange things, have macros and mail merges and templated documents ready to go, and can otherwise make the office suite do everything that it is advertised to do, and a few things that it might not be advertised to do. Microsoft Excel's formula language has been Turing-complete since 2021, and in that linked post, the people writing the post refer to it as a programming language. Some of the Easter eggs that have been developed in Microsoft Office products certainly showcase what those software products are capable of, although perhaps the most cursed application developed so far is in the family of using Microsoft Excel as a backend for Representational State Transfer items, which also involves a lot of Visual Basic and interoperation from the C programming language. Regardless of my opinion about the can/should divide when it comes to embedded scripting, macros, and the rest of the ways that documents can become dynamic instead of static, the people who do that kind of work are doing a fair amount of programming, just not in a language that many people would recognize.
I refer to myself here as part of the "Script Kiddie Division," because a large amount of the interactions I have had with code, or with modifying code, has been taking someone else's work and either using it in my context, or making a tweak or two to it to suit my purposes and otherwise running it mostly unmodified, in the same way that the script kiddie finds the tools of others and then deploys them, mostly unmodified, to do whatever mischief or malice they want to wreak upon the Internet, whether for lulz or for other purposes. I do these things without necessarily understanding them at the code level, but instead because they are advertised as working, they claim to do the thing that I want, and they are available to test and see if they do both work and do the thing I want them to do, or can be convinced to do the thing I want them to do.
This tendency started early, as I am of the age where entire programs in BASIC would be printed in "beginning to code" books, in the same way that they now use Scratch or other block-based interfaces or languages like Python to do the same. I've also talked before about studying Automenu as a child and trying to replicate its syntax to extend it to other games I wanted to play. Game Genies also had the suggestion that any combination of their letter interface could work, if someone were willing to test them out, but they also had a code book with the ones that were known to work, because most people don't want to have to write down all their code choices and observe any effects of what might happen. If, instead, we knew which registers and memory bits were being modified by each of the letter combinations, we could probably do a better job of figuring out which strings would be more fruitful than others. (Although we might not find some of the multi-line codes that were present.) It also turned out, thanks to the knowledge of The Internet, that I could modify the rules.ini file for a game like Command and Conquer: Red Alert, and thus change the gameplay experience for my single-player gaming. (I only changed one thing, honestly - I made the ore mining give three times as much income as it was initially set. So, presumably, it did that for both sides, so I wasn't giving myself an unfair advantage.) In any case, even though I knew I would not be as good or as generally-knowledgeable about computers and programming as some of my friends, I figured that I would always learn enough (usually to get a game running or to activate a useful cheat) and that would be something that might come in handy later. (There's a name for this! It's called just-in-time learning.)
So, with a little bit of BASIC and a few bits of here and there, my first brush with having to do a significant amount of programming was when I built a personal web site in the era of free web sites being available for people to build with. And that was less programming as it was using a markup language to build a static site, but it did teach me useful concepts like the need to close your tags, check your brackets, and make sure that you leave comments to yourself about what you're doing here so that when you come back to it, you understand what's happened. (The site I have for holding my professional CV and several of my publications and presentations is similarly static, and just upgraded to frames because I was tired of having all of my navigation on every page. Which produces the problem of pages without navigation on them if you go to them directly. I haven't solved that one, yet, but I suspect that if I were to try and do it, there would be a lot more Javascript on the site, and I'm trying to keep that to a minimum and only use HTML and CSS as much as possible.) Learning how to build, update, fix errors, fight bugs, try to puzzle out the box model, and test out the various tags and selectors and what they did gave me some decent concepts to work with, at least for messing around on a personal site. I didn't do much for it other than use it as a personal sandbox, and in that era, where tags like blink and marquee were still in use, there were a lot of personal sandboxes around, or sites built with one specific idea in mind. (I could have gotten into fic here, had I made the right connections, but alas, it was not to be.)
My first thorough introduction to programming was in graduate school, where one of my foundations courses required that I program a real database-backed application that had a web interface and a form and everything. The graduate student instructor for the course looked at some of my early code options, with a long sequence of nested if statements, and then asked me what the last language I had programmed in. "BASIC," I replied cheerily, and he then proceeded to explain to me things like && syntax, where I could get all of my if conditions into one line, rather than spending a line on each one of them. I still sometimes like to write out all of my if conditions, one to each line, with indentation, to make sure that I have the logic flow all together, before moving things into a more condensed form. It also helps me make sure that I'm at the right levels of work if I write it all out and then collapse later. In any case, while I wouldn't call the application that I ended up writing pretty in any kind of way, it functioned, and it met the requirements of the course. So I learned a little bit about Ruby and the Rails framework for it. As I now look at that project, I'm not very fond of the way that Rails chopped up a lot of my complete pages into partials, because the Asynchronous Javascript and XML (AJAX) part of it that would rewrite what was displayed on the screen through manipulation of the Document Object Model (DOM) needed to have each of the possible elements that could be on the page separated out into their own partial pages, to be stitched and restitched together by the Rails framework and webserver. Having to remember where I'd stashed a particular partial, and what I'd named it, and having to remember what was in my database and the relations between fields and tables was not very great for me. I'd had to do all the bits that were planning out the database schema, and naming the tables, and figuring out their relationships, all as assignments in the class, so I wasn't flying completely without maps and instrumentation, but it was definitely difficult to keep all the moving parts in my head as I was programming, creating, and troubleshooting.
Having gone through it, though, I tried to put my programming talents to use in my workplace, and that pretty well went nowhere, not just because there weren't, say, test servers to run code ideas against and see if I couldn't build myself a useful list, but also because when I was trying to build something useful, like a way of randomizing participants in a game tournament that didn't have randomization or tournament modes, I got into difficulty with my manager because other staff persons were saying that I wasn't paying attention to the participants in the programming, when the programming was letting them do what they've done best in gaming, making sure that they traded controllers regularly enough, and trying to make sure that tempers didn't flare too greatly. Of course, these are the same people and manager who likely disapproved of my occasionally wading in to the fray with the participants. In any case, the person who would have been encouraged to keep with the coding, and given tools and playgrounds to do work with, is a very different, and possibly less traumatized, person regarding their workplace and managerial competence. Regrettably, there's still not really any playgrounds or sandboxes for staff to test out ideas they might have, whether in code or otherwise, because our IT department is run with shoestrings and electrical tape, just like every other part of operations in a chronically underfunded organization.
At that point, I mostly just went into brumation about code. I was using stuff, sure, but the closest project that I could have contributed to would have been Dreamwidth, and I still wasn't willing to learn cursed Perl or even more cursed BML to do much to contribute on that end. (Also, because even though I know Dreamwidth is an environment that wants to be welcome to beginners and to teach them what they need to know on it, I felt intimidated by all of these people who did know what they were doing. Yes, this is where you insert Things Real Dreamwidth Programmers Do.) And also, that was a significant part of my life where I had someone siphoning a significant amount of my time, energy, and cope for her own purposes, so even if I had wanted to get involved, I probably would have been excoriated over it, or have it looked at with suspicion. My ex wanted to try and understand me better, which was fine, but she often tried to understand me better in a way that would get to us doing things together, when some of the things I wanted to do were me things, either at the outset, or always. Me, with other people who were not her, was rarely-to-never something that she approved of, and if she did, it almsot always came with strings and costs.
Fast forward more, because we're still not doing much with code at work, although I am maintaining the EeePCs and putting them to work with some code that someone else wrote out for me to display slideshows and otherwise keeping them running on stripped-down Linuxes, and then I get to a different relationship, where not only am I running my Linux box full time and out in the open, there are little gadgets that keep appearing because other people also would like to have computers, and we would like them to have network access, and there's a certain amount of sysadminning that I'm doing anyway. Also, I'm continuing to maintain my professional website and catalogue my CV and all the achievements that have happened in my career so far, so I'm getting back into the nature of website stuff with a service that gives me about the same level of sophistication that my sandbox website had, because Old Web is still sometimes looked upon fondly. All of these things, save maybe the website pages, are still stuff of the nature of using other people's code and scripts for the grand majority of those tasks, but it's getting comfortable with stuff and once again marveling at the flexibility of a general-purpose computer or two. Then the home automation toy shows up, and the code bits begin again in earnest, because now there's some amount of needing to get stuff to work the way that everyone here wants it to. Getting voice assistants to work properly, getting intent scripts to go well, automating, configuring, and eventually putting together scripts and files and using the tools available to me so that stuff goes well. There's lots and lots of just-in-time learning going on now, as well as so much grabbing things and seeing if I can make them work with a few modifications, or to get something to work with what the code wants and expects. Still very much the Script Kiddie Division for most things, building on the back of a really strong codebase that already handles a lot of the devices and their outputs in a nearly plug-and-play manner, and some bits that are dropping in other pieces of code until they work, even if I don't fully understand the hows or whys of their working.
And then. A few weeks ago, in one of my social spaces, someone was complaining about having exported lists of prompts from certain kinds of exchanges, and how it was going to take a very long time to put them into a spreadsheet so they could be searched and manipulated, one prompt at a time. Everyone agreed that doing it one line at a time was going to be miserable. I looked at the form of the prompt lists, and I thought about, and then described, what I expected a script or automation to do with such a thing, and what the output of it would look like. At which point I realized that if I could describe the thing and what it was supposed to do, I probably could also create the thing, since it was essentially text manipulation. After fiddling a bit to see if it would work well in shell scripting (no), I settled on Python, since it's supposed to be well-documented and well-tutorialed and I would have a decent chance of understanding what I was doing without having to do a lot of messing around. And then, piece by piece, with search engine queries to help me find the right form and function, I built scripts to ingest a file, line by line, store elements from read-in lines in an array, concatenate the elements together that would output a desired line, write out the line to an output file, and then start it all again with the next line.
The script went through a few revisions to make things easier for me, but most of what I was doing was harmonizing the inputs, and then examining the outputs, noting where there were obvious problems, harmonizing the inputs again, re-running the script, and then, when satisfied, taking the output files and renaming them so that a new input file could be brought in and processed. It took me a long weekend's worth of time, including breaks for work and sleep, to process the input files, then correct things and reprocess until I was satisfied. When all was done, two scripts of less than 50 lines (discounting comments and whitespace) turned about 110k-115k of input lines (the easy way of doing line count on the files overcounts the number of real lines, because of things like random line breaks in the middle of prompt lists, index lines, header lines, and other things that were not actual prompts) into a little over 412k of output lines (which might be a small undercount, because I definitely didn't spot all of the situations where something didn't render exactly correctly unless it was big and obvious.)
I did that thing. From scratch, with consultation of reference works, in proper engineering form. And got the thrill of watching lines scroll by on my console as the script did the work. I did that thing. I want to find faults with it, so that I can claim it wasn't real programming, or discount it as not perfect, and therefore, not worth saying anything about, because having to admit to my own competence in things is sometimes terrifying. (Mostly in the department of "Is someone else going to come and piss on my parade?") It worked, and it worked in the way that computers do, and I built it, and this is probably what people get as the feeling of how powerful working with code actually is, when you can put your idea into existence and you find out that it works just fine. And that you've accumulated enough knowledge (or enough knowing where to look for things) that the code does run, does work, you can fix the problems, and then you can look at the end result and go "Huh, I nearly quadrupled the number of lines of output compared to input, but they're in exactly the form that someone wants so they can do further manipulation with it. And it was a pair of very small scripts that did all of this heavy lifting."
So, yeah, I'm still probably going to mostly reuse other people's work when I can find it and if it does the job I would like it to, or tweak their things to my purposes, but it's also something to know that I can do the thing that I usually set as my bar for "actual skill" - creating a thing completely out of nothing and successfully having it do what I wanted it to.
no subject
Date: 2024-12-29 05:05 am (UTC)no subject
Date: 2024-12-29 05:49 pm (UTC)It was mostly the feeling of "this works, and I made it! I can't believe it's working! I'm not supposed to be a programmer, how is this working this well?" It is satisfying, but mostly it was "this is going to go south any minute now, and yet it keeps not doing that."
no subject
Date: 2024-12-31 06:33 am (UTC)Also, I'm here to tell you, "this is going to go south any minute now" is not uncommon while programming. I assume you know about source control to be able to roll back to before things went south.
no subject
Date: 2024-12-31 07:05 am (UTC)And because it's not complex, that's why I think I'm still not a real programmer.
no subject
Date: 2024-12-29 07:04 am (UTC)no subject
Date: 2024-12-29 05:50 pm (UTC)no subject
Date: 2024-12-31 06:29 am (UTC)I feel... Seen
Date: 2024-12-31 07:28 am (UTC)Except... I'm not. I'm a real programmer who works in Excel and VBA, with (most of) a part-time degree in Computer Science and the Job Title 'Software Engineer'.
I work for bankers and, mostly, the anthropologically-fascinating subset of them we call Traders...
And that's a good place to be, because there's enough money in the custom-UI, custom-numeric-analysis they do, to create a reasonably lucrative niche for dedicated developers and fixers for their spreadsheets.
Hence, me.
The trick is making damn' sure to know their business and how they work, and *work with them closely*.
I enjoy it! I've written about a quarter of the code that 'real programmers' might in their career - 90% of it VBA - and the rest of it is the visual UI development of time-critical business processes.
...Plus, of course, un-borking the spaghetti mess of code and sheet logic in formulae which has metastasised from the work of brilliant but misguided individuals who can code, but can't think about data and processes in a structured way.
The worst such messes come from 'real programmers', far better qualified and credentialled than I, who are dismissive of Excel and slap-in a mess of fixes to a tool that they consider beneath their dignity.
...A couple of months of that is sufficient to screw up the spreadsheets beyond recovery, declare the mess impossible to support, and Replace Spreadsheets With Proper Applications.
I love that: a year later, the failed Proper Software is rejected by the traders, who carry right on using spreadsheets, and hire-in RAD developers with the Excel skills and trade floor experience, on the desk's own budget - 'desk hires' - who answer to the senior traders, not the IT Department.
Which means that, on a good contract, I get to sort the mess out, get them trading faster and more profitably, and leave them with simplified, reliable, and fast trading tools.
At which point, the IT Department notice, formalise my hire into an IT reporting line, and move me off the trading floor into an open-plan office full of business analysts and project managers, and restart the cycle of Replacing Spreadsheets With Proper Applications.
I get let go, rubbling my hands in anticipation of my return, a year or two later, as a Desk Hire.
I love the work, even the truly unmanageable spreadsheets - that's the ultimate untangle-the-string logic puzzle - and I love working with traders.
Even (or perhaps especially) the difficult ones: none of them are stupid, all of them have a ruthless focus on time and effective results, and they appreciate it when someone's giving the m better tools and a better workflow.
And, on a trading floor, they are empowered users - not faceless, helpless blobs who are given crap software that sort-of-works with something that's not really whatever they need to do, and have internalised the fact that they are powerless and must tell managers that 'their' IT is wonderful!
And... I love Excel. It's visual, and only an API call (or a COM interface) away from bringing in high-performance analytics that's been coded right to the metal.
Please don't tell 'Real Programmers' that.
Re: I feel... Seen
Date: 2024-12-31 03:09 pm (UTC)