QA was always seen as second tier compared to software engineering; AI may upend this relationship and provide lessons for all fields as to the shift in value of different job skills.
One of the best courses of study I took in college was a series of courses called Science, Technology, and Society. It covered the history of science and engineering. By far my favorite story was around the invention of the atomic bomb as it not only illustrates how society can shape scientific advancement, but it provides some well-deserved schadenfreude for the Third Reich.
In physics today, theoretical physicists are the rock stars. Experimental physics is not quite as glamorous. This was not the case in the early part of the twentieth century in Germany, a country with a craftsman and engineering culture. Back then experimental physics was the premier specialty; theoretical physics was second class. Also second class back then, were the Jews. If you were a Jewish physicist, it was very difficult to get an experimental physics appointment, you were related to theoretical physics. As the century unfolded many of those physicists left Germany for the US. When it came time to develop the atomic bomb, guess which country had the theoretical physicists needed to develop the bomb and guess which one didn’t.
In software engineering today QA (quality assurance) takes a back seat to software engineering. It’s understandable; software engineering creates features which creates customer value while QA catches bugs. Bugs can destroy value (e.g., software that’s too buggy), but it can’t create value. While an airplane or pacemaker shouldn’t have bugs, if a website has the occasional bug, most people accept it.
When done poorly, QA are relatively low skilled workers who just try to poke and break things. When done right, QA engineers are a strong combination of product and software engineering with a creative mindset. The best QA engineers understand the business needs and look for edge cases to explore. Top QA engineers are fantastic to have on your team.
Both software engineering and QA are getting more and more automated. QA has gone from manually pressing buttons and confirming the correct response to automated QA in which code is written to automate the pressing of buttons and verification of the response.
Software is becoming more automated as well. Back in my day we had to deal with manually parsing bytes read from a file or writing sorting algorithms by hand. Modern languages do this and more out of the box. Each generation abstracts away another layer. Third-party libraries further encapsulate rote functionality allowing for off-the-shelf features with little or no coding. With the growing popularity of LLMs and tools like GitHub Copilot more and more base code will be written by AI.
The skills needed by programmers in the future will be higher level and closer to the business. It will be less about knowing how to write lines of code (and knowing where to put the semicolon), and more about thinking through the high-level concepts that generate business value.
The question everyone needs to ask is what I outlined in prior articles such as Why AI Isn’t (Yet) Ready to Take Your Job. If the bulk of your value-add is automatable tasks (e.g. lawyers pulling up prior case law and writing briefs) that is going to change.
If the value of software engineers is knowing where to put the semicolon, it’s going to become far less valuable. (Good) QA engineers and product managers, both of whom know how to think through and even expand the business use cases, will see their value to the companies increase over time.
This isn’t going to happen immediately and it’s not going to fall off a cliff. What we will see is that knowledge of coding (grammar and constructs) will decrease as the value of the knowledge of business increases.
We’ve already seen some of this. The standard computer science curriculum includes a whole section on data structures and algorithms (how to sort and search data). In my day we had to know to implement quicksort. Today you can just call the sort() function and the built-in, optimized sort has been written for you. Of course, high end developers still are valued and need to know this.
Consider drivers. If you were a chauffeur in 1920 you needed to know how the engine of the car worked because you had to constantly fix it. Today you can be a chauffeur while treating the car like a black box (you don’t even need to speak the language of the country in which you drive since apps will communicate that for you). The technological advance has made the detailed knowledge of engines far less relevant. However, if you’re a racecar driver while in theory you just need to drive around the track, in reality understanding in minute detail how the engine works lets you eke out every bit of performance which is needed at that level. Software at high volume or low latency has the same high performance knowledge requirements and always will.
In the case of atomic physics, a new frontier opened which created a shift in the demand for a certain type of physicist. With software engineers, we may also start to see a shift in the demand curve of software knowledge versus knowledge of business value; related roles, like QA and product management, may start to capture some of the value (and compensation) traditionally allocated to software engineers. This is one example in one industry, but we’ll likely see similar patterns in other fields.
It’s critical to learn about corporate culture before you accept a job offer but it can be awkward to raise such questions. Learn what to ask and how to ask it to avoid landing yourself in a bad situation.
Investing just a few hours per year will help you focus and advance in your career.
Groups with a high barrier to entry and high trust are often the most valuable groups to join.
