The coding portion has been reliably solved
Like I said, it was someone else’s original statement, but the more I thought about it, the more I find myself agreeing with it, for one simple fact:
It took me 10 years before I had issues with (old) code again
In my current job, I often deal with legacy software, project work, migrations and a lot of issues that aren’t the code itself, but rather time, budget or practical concerns that surround it. This was my original point of contact, that I haven’t had issues with how to write a single line of code for a long time - but I want to get back to that in the next point, because I realized that I do have issues with how to write code again.
Most large-scale software suites are written in a way that makes them reasonably simple to INTEGRATE into existing infrastructure, and simple to IMPORT data from other sources - but not in a way that makes it easy to get that data out and move to another solution. It makes sense from the view of a company, at that scale you don’t want to lose a million-dollar-contract if you can keep it running for one more year. Shitty for us developers, but I get it, it’s a dark-pattern that makes financial sense.
Now, you suddenly realize that you didn’t create enough dark patterns to survive against changing requirements, the whole company goes belly-up, and people like me get called in to help on migrating the functionality and data.
Now, someone like me comes along to be presented with a list of problems that are overarching (and kind of fun), but I want to focus on the coding issues:
Nobody has any sort of documentation for the tool, and the company doesn’t really offer trainings anymore. The available trainers are backed up for a long time, and nobody wants to wait like six months before starting the migration. I literally have a paper stack on my desk that smells of cigarette smoke and years of neglect with a printed documentation that has pages missing and handwritten comments on some pages.
The people who are actual experts in the old system have jumped ship and work somewhere else by now, you can’t even hire them.
I need to understand enough of the infrastructure and code to see if it is possible to export data, if the new tool has all the functionality of the old, if we maybe need to write middleware or callable endpoints to get the functionality the company needs.
I need to frequently just test and experiment to see if I can print out data, call an endpoint, maybe write to a database in a specific point of the process chain to get the data out that is otherwise stuck in the original system. Sometimes, I just write code and run it, in hopes that it either works or gives me an error I can use to reverse-engineer the function signature or parameter order.
I need to work with what I have, in the tools available, and with tools that are built specifically to be opaque and try their hardest to not give any information out.
Quite often, I have to either experiment if a function exists, does what I want, in which order to write the parameters.
There have been a few cases lately where my only hope was looking at the existing code to hopefully find a similar example. There were thousands of dollars and days of work, deadlines, all hanging by the thread of whether or not someone had written the right bit of code that I could learn from, years ago.
My point here is twofold:
It took me ten years, and specializing quite a bit, before I got into a position where I know what I want, but don’t know if the software supports it. You either know yes or no within the span of seconds these days.
All the problems I listed are remnants of how things used to be, and we have established standards today that these tools violate, either by choice or because those standards didn’t quite exist ten or fifteen years ago when they were put into production.
I believe that for most of us, chances are good these days that we struggle with the layers above writing code, not the code itself.
Most problems with coding have been reliably solved
You see, when I first started in professional programming about 15 years ago, we had a lot of issues with the coding side of things:
Without proper Intellisense, you often relied on books, other people who had built similar things before, and undocumented functions in the language of choice. I wrote VBA macros in Excel files, you had no debugger, no proper way of log output apart from printing results into cells in the spreadsheet, and I vividly remember somehow calling a webservice endpoint from within a spreadsheet. It’s a small miracle that I managed to make that work as a junior developer, there were days of just waiting and researching in between new ideas. Not just because I was young and stupid, but because there was no documentation for it, not even really online. I don’t even remember anymore why these things were built the way they were, all I know is that I was put in front of them while the experienced developers worked hard on making sure we could move on from those solutions. The point is this: I haven’t seen undocumented functions for a long time, and most tools these days have some form of Intellisense built into it.
When I first started, nobody had a way of automatically formatting code. The tools probably existed already, but nobody had them. Today, I just press alt-shift-F in VS Code (and several other tools) and never have to bother with religious opinions like if the opening curly bracket belongs inline or in its own line. We even have tools like StyleCop that prevent checking in code if it doesn’t match whatever styles and naming schemes the company uses.
Pretty much everyone uses Git these days, or SVN. When I first started, I worked for a company that had over 100,000 customers, but the tool I took over from the developer who got fired was not backed up to version control at all, we had the executable running on the server and a mess of code with commented paths on this guy’s local machine. That was it. Unthinkable today, but not that uncommon just a few years back.
IDEs used to cost money, and so much money that most of us could not / would not afford anything in our private work that we weren’t also using at work. Nowadays, we have VS Code and most IDEs have pretty usable free tiers - you can even get a trial of JetBrains.
There is a 99% chance that an LLM can answer the coding related question we might have. I have even been able to use it to write “JavaScript adjacent scripting languages” in some of the legacy tools, by explaining what functions I had available and asking it to write out complex for loops following that syntax. This is work that could take me days of trial and error, and would have been impossible to get help for on Google or StackOverflow.
We have reached critical mass in most coding tools where you can probably find training for it online, and probably cheap. I have vivid memories of trying to build a tool that could insert variables into placeholders in a docx document, and the ultimate solution came from a guy in India, on YouTube, working on a laptop with a fan that was so loud you could barely hear him speak. I am pretty sure that at the time, he was the only person who had made a tutorial for this functionality, and I can only assume that he worked for Microsoft because I could not imagine how else he figured out a completely undocumented process. Today, I can just import a library to write docx files.
For every problem that might come from wanting to run the code, we can rely on ready-made solutions like docker, Netlify and pythonanywhere. Nobody HAS to run a server in their basement anymore, with all the overhead and security risks that come from that.
Package managers are a thing now, offering most functionality we could need, written by someone who usually knows what they are doing. Yes, package managers have their own issues as we all know - but by god, I don’t EVER want to manually integrate classes from a downloaded package that will forever be impossible to update. We have come a long way since those days.
We have coding snippets, macros, plugins, freeware to bulk rename files.
We have ways to automatically lint / check / fix errors. I have even written my own in places where I saw enough source for human errors to warrant the effort.
Most tools these days have standardized to the point where you can reasonably expect the same things to work the same way, even if they are slightly different or the function uses different syntax. It takes a long time and some pretty edgy edge cases before you hit the limits of whatever language you are working in - at least to the point where you give up and rewrite the whole thing in another language.
I must say, I quite enjoyed ordering my own immediate thoughts about this original statement, I hope it proves useful to anyone else out there. It really made me realize how short the time span is between me working on a tool that wasn’t even backed up to version control, and today’s times when we can prompt a machine and reasonably expect usable code out of it. I have been working in software development for fifteen years now, and that is not a long time at all for the amount of changes we have gone through.