If you ask anyone what is the job of a software engineer, they will probably say "write code". In my experience, if I use 50% of my work week writing code, that is a lot. I think I may have achieved that a few times, and they were all in the context of hackathons. Most of the job is communicating: with your fellow engineers, the designers, management, cross-functional partners, users, etc. That is often to determine the answer to the question such as "What should I be doing?" or my preferred version "What is the problem I am trying to solve?". Because once I have a problem I can think of a few solutions and then start coding them.
In software engineering the solutions we are expected to provide are code. And code tends to not leave much space for ambiguity. In fact, computers are extremely good at unambiguously doing exactly what the code tells them to do1. Because if you look closely, what computers ultimately are, is just a set of tightly packed deterministic processes that we run on deterministic data. But Computers don’t do well with ambiguity. The more closely you look the less ambiguous the computers need the instructions to be, up to the point where they end up being a series of ANDs, ORs, NOTs, etc… And ultimately, as software engineers, what we do is being able to translate an ambiguous task into these extremely clear instructions
To start off let's have a quick look at the history of software engineering, as presented by me, a non-historian, trying to make a point2. While computers have evolved significantly since their inception, with things getting smaller, more efficient, and more powerful, the base units have remained more or less the same, excluding ongoing research on quantum computing. Simplified: We have a series of 1s and 0s (bits)3 going through circuitry connected by gates that do logical operations like and, not, or, etc... and return the result. These gates can then be combined to do specific operations like addition. And all of these circuits are combined to an instruction set that the programmer can then use, usually through a low level language like Assembly, to tell the computer to what you wanted it to do. People used to write code a lot of code in Assembly4, but it's a much rarer now. Most Software Engineers nowadays do not need to even know what Assembly looks like5. Later on compilers came along that made it possible to write slightly more human-readable instructions6, that were then translated to machine instructions. The compilers became more advanced, and with them the capabilities of the languages improved in what you could express through them. Just like a child gathers more vocabulary.
Nowadays, we have more specialised languages like Rust, JavaScript and Python, each with its own sets of strengths and weaknesses. A lot of algorithms have been abstracted away as well in common libraries we need only use. So new engineers learn more and more how to communicate in these new frameworks that the languages provide.
The big topic in the technology space nowadays is LLMs. With Github's Copilot there is increasing speculation about AI making the job of Software Engineers obsolete. Personally I would not be too concerned. With the use of similar technologies, auto-completes in IDEs have been getting more and more useful. When autocomplete appeared, automatically filling in the name of the functions no engineer lost their job. We were just no longer expecting the engineers to remember the name of the functions, their arguments, and most importantly which order they go in. With the usage of the mysterious AI, the auto-complete instead of auto-completing ca to catch it will catch the error, and throw it back out, because that's mostly what we do anyway.
In the state they are nowadays, I am not too worried about LLMs magically being able to start being able to write code. But let's assume that LLMs became advanced enough that they are able to create correct code7 based on what you told them. What you then have: is just another compiler. Then instead of using JavaScript as a language in which the engineer communicates to the computer, they use spoken English, that the LLM translates to JavaScript that then gets translated to Machine Instructions, eventually. But, as we are already seeing in the increase of talks about prompt engineering as a buzzword and study, that English we will use to "speak" to the LLM is likely not going to be the same as we use when speaking with each other, at least if we want to get the desired results. And at this point will it not be just another programming language?
In the business world companies tend to want to make money, so ultimately that is the problem they are trying to solve. How they go about it is solutions. The bigger the company the more it can do to achieve that goal. But because there are so many people doing different things, it may not be entirely clear to the software engineer who is writing up the animation for the like button on Facebook, on how that has anything to do with making the company more money. And the important thing is, they don't really need to. Their skill is to be able to tell the computer which pixels on the monitor to light up blue.
But this engineer themselves got their instructions from someone who probably told them to "make the like button more fun to click". They themselves probably got instructions from someone else that "we want to drive up engagement on posts", who probably got instructions from someone who said "we want people to interact with more posts", who got the prompt that "we want people to see more ads", which ultimately came from the original problem statement of "we want more money." Each iteration clarifies the problem further until there is one single set of instructions, the code, but the disambiguation does not stop there, once the engineer writes the code, the compiler translates it to a set of instructions that get sent to the processor, and then there are a lot of electrons firing in circuits. If you were to just look at the electrons firing it may take you a while to tell that it's just doing a thumbs up animation.
At every level, each person removes one layer of ambiguity up to the point where it's just LEDs lighting up on a screen, in the right way. But if you go to a computer and just tell it what you want it will probably sit there silently and not do it. You can't expect it to understand you and magically do what you intended it to do. Similarly, if you were to go to the Engineer who was doing the thumbs up animation and present them with the problem, they would probably shrug their shoulders and probably not very successfully try to do it, if they try at all. Ultimately this also falls under my belief about one of the biggest and most important differences between a senior and a junior engineer, and that is how much ambiguity are they able to remove.
Computers get their instructions from the software engineer, who get their instructions from their seniors, who get their instructions from their managers, who get their instructions from their customers (in a very simplified communication model). As instructions don’t come bottom up, but from the top of the communication funnel, every layer has to sift out ambiguity to create a more and more concrete set of instructions for the lower levels up to the point where we have the computer doing the thing we want it to do. Once we've done that we probably need to clearly communicate it back up, and the cycle begins again.
1 Much to the chagrin to software engineers like me, who need mnemonics for left and right, and would argue the computer should have been able to tell that when I said right, I meant my other right.
2 If you want a less biased version I am sure Wikipedia can provide you with a slightly more detailed and significantly less biased portrayal of said history.
3 Which is if we start things a bit later (pun intended). Technically if we consider the first computer to be the Bombe inputs were not bits, but letters which were set on mechanical gears.
4 You know the famous Apollo mission photo of Margaret Hamilton? Those were a lot of instructions.
5 Though some may try to write entire games, like Snake, in Assembly as a form of either scientific self-flagellation or ostentatious peacocking.
6 If one can call FORTRAN or Lisp readable.
7 And not the most statistically likely correct code.