If you jump on social media these days, there is still a lot of rather uninformed commentary regarding ChatGPT. I also noticed a trend among non-technical people gloating that software engineers will soon be out of work because their job can now be automated as well. I will dispel this notion as it is, quite frankly, ludicrous.
Automation does indeed lead to jobs disappearing. This also affects white collar jobs. It is also important to note that software engineering is often at the core of process automation. For instance, I know that legacy banks often have teams 10x the size of a “neo bank” for the same work, due to highly inefficient processes, but also due to a workforce that is used to going to work on Monday, and get cracking after lunch on Wednesday. This is not much of an exaggeration, and this is a phenomenon you will find in most if not all established large companies. Even in BigTech people have been joking about certain companies being a place to “rest and vest”.
Software engineering will also be affected by increased automation, but this is normal for this field. In the early days, people manually translated code to machine instructions. Later on, this task was taken on by compilers, which made the entire job category of human compilers disappear, incidentally a position often held by women and a key reason for the misguided belief that computing used to be a female-dominated field. There likewise were people who spent their days solving the equations engineers set up. Of course, all of this is done by a computer nowadays, which removed the need of having human “computers”, i.e. people who perform computations.
Programming languages have become more high-level over the years, with some having a syntax this is quite close to human language, of course in fully formalized way. Then people began improving editors, turning them into so-called IDEs, i.e. “integrated development environments”. On an aside, ask an applicant for an engineering position what “IDE” stands for and chances are that they have no idea. Modern IDEs automate a lot of the boring tasks, particularly in more verbose languages. Just like auto-complete in your email app, those IDEs allow you to automatically fill in certain values and parameters.
In 2021, IDEs got a lot more powerful thanks to Github Copilot, which is essentially an AI-powered auto-complete tool. It can help you write code a lot faster. The basic “loop” is that you write a brief comment describing a piece of code. In response, you get a suggestion from this tool, which you afterwards modify. As a consequence, developers can be a lot more productive and, quite often, they also enjoy their work more because a lot of the repetitive tasks are being taken care of by an AI. Thus, experienced developers may end up being about 1.5 to 2 times as productive as they were before.
ChatGPT makes further promises related to software engineering. The most often-cited examples I have seen are providing an explanation for a piece of code or writing code based on a textual description. Some non-technical people seem very impressed by it but they do not quite understand what they are looking at. Oftentimes, they are looking at code at the level of the most basic tutorials. In contrast, the reason why software engineers are highly paid is because there are not a lot of people out there who can break down a problem into smaller tasks in a logical way. Furthermore, not a lot of people have a good enough attention span to dive into an existing code base, understanding part of it, and making a meaningful change to it. This is not easy work. In fact, it can be quite exhausting, which you would not guess if your perception of engineering has been influenced by bizarre mainstream messaging.
The difficult part of software engineering is to think in a logical way. Ideally, you should be able to approach problems in a somewhat autistic manner because that is how the machine operates. It does not make any inferences and instead does exactly what you tell it to do, nothing more and nothing less. To some extent, this can be learned but for most people this is nothing but an exercise in frustration. ChatGPT will, however, not be able to make the user thing logically. In fact, there is a bit of a circularity here, i.e. the people who can benefit from AI code generation are those who do not need it. They simply end up saving time.
In contrast, someone who does not know how to break down a task and does not quite understand logical implications will not get anywhere with Github Copilot or ChatGPT. They get code they do not understand and cannot even properly work with. In all fairness, there are people in this industry who have been getting by with copying code snippets they find online and making some modifications on a trial-and-error basis. They slam that square piece into a round hole so often until the cut-out of the hole cracks and the piece goes through.
AI code generation will likely lead to some job losses in software engineering. However, I think the people most affected are those who should not be in this industry to begin with. This includes the 20+ year veteran who never went beyond following recipes and who writes code that is 10x longer than it needs to be, and 1000x slower, and this is not an exaggeration. One bad engineer can also undermine morale of an entire team. Sure, they may be cheaper although oftentimes they are not, but they are not worth their money. We will likely see the bottom fall out at the entry level. To get your foot in you will need to perform at the level of a mid-career engineer today, i.e. someone who can work quite independently and solve complex problems. The junior level may thus disappear completely, and this category also includes low-performing engineers, which the industry has no shortage of.
In the long run, I think that increased automation is good. I have seen how productive small teams of high-quality engineers can be but also how little large teams full of dolts produce. In the future, good engineers will be able to write more good code, which should lead to an overall increase in code quality, at least in theory. In practice, however, we will probably go through a phase where non-competitive engineers try to compete on price, and some non-technical business owners may fall for this, thinking that they are making a great deal if they get five engineers for the price of one good one, similar to the outsourcing fad.
There are also good parallels to be drawn to other fields. Imagine you run the army. You have a certain number of positions to fill, and suddenly you have recruits who can perform at a much higher level than those in the past. Let’s say they are all twice as strong, or their reaction times are only half of the previous crop’s. You would be quite excited about this. Of course, the analogy breaks down once you consider the problem of “cannon fodder”, i.e. you may need some bodies that you can just throw at an enemy. Thus, you may probably want to shield your super soldiers from grunt tasks, which still need to be done. This, you would clearly have two classes of soldiers, your new class of super soldiers and grunts, because you still need them. Yet, if you then learned that you could use cheap robots to take the job of the grunts, you would happily agree to that. This is also what I see happening in engineering, i.e. grunt work will be automated away and the new bar for getting a job will simply increase, and exclude people who perhaps should not have gained entry into this field in the first place.
That makes a lot of sense, and especially for someone like me. I had a pretty backwards entry into programming. I was solving business problems and developing solutions before I learned how to code.
I was doing it by patching together APIs, googling and basically hacking things together, but I solved pain points for people. They didn’t care that I didn’t write any code.
I only started learning to code when I saw how much faster, easier and more productive I’d be if I knew how to code. I think this is kind of similar. If you can solve business pain points and come up with solutions, nobody cares if you wrote the code by hand. At least no business owners do. Only other programmers do due to ego and shit. Business only cares if you get shit done, they don’t care if you used a library, copilot or wrote it in assembly.
I don’t know how it is in the enterprise programmer world, but in the freelance world I know the higher earners are the ones who are the best at coming up with solutions. They’re problem solvers. Code is just the tool they use to solve problems. And these are business problems. Nobody cares about your hackerrank score.
Though I do get that in something like enterprise-scale software actual programming skills can become the main differentiator. Like if you’re algorithm is 0.1% faster you save the company millions in server costs. Outside of that environment though, business logic seems to be a higher factor.
What you describe is actually the more important skill. The typical junior engineer, and even plenty at the mid-level, cannot break down larger projects into small tasks in a logical way. Some come up with completely bizarre abstractions. The typical junior engineer gets handed a code skeleton and fills it in. Anybody who does not grow beyond this level probably should not work as a software engineer at all.