Hello! I’m back.
Why am I back? Well, I became mildly upset about a problem I’m seeing and I’m hoping I might bring some sanity to the conversation. A bit of calm. So, grab a cup of herbal tea, settle in. This one’s a doozy.
Is programming going away?
I just got off the phone with a newly graduated Computer Science student who’s been on the job search for a year and a half. This feels wildly unfair. When I graduated (not that long ago), the phrases “newly graduated” and “job search for a year and a half” were never in the same sentence. But here we are. She asked me, “Is the market going to recover? What do you think about the future of programming?” I took her question and assumed that part of what she was worried about was AI. Is AI going to keep her from getting a job?
That’s the question I keep hearing from new programmers - spoken or implied. They want to know, and I don’t blame them. I’d like to know too. Unfortunately, all I have are ideas. But I think they are good ideas, so let’s explore them.
No
My best guess is no. AI will not obliterate the need for programmers. And I think the belief that AI will do away with programming indicates a misunderstanding of software’s nature. So, let’s answer that question first. What is software? What is it made out of?
What Is Software Made Out Of?
That’s a more difficult question to answer than you might expect. You can answer it in different ways and at different levels of analysis.
Let’s first answer it like a materialist, who’s only interested in definitions that concern matter. They might say that software is the flow of electrons in a computer chip. That’s certainly true. There’s just one problem - it’s not a useful definition. In what way does thinking of software as electrons in a chip help us create good software? Maybe thinking in that way will help us write highly performant software. But it certainly won’t help us manage complexity. It’s just too concrete of an explanation to be useful. Let’s get more abstract.
Instead, let’s answer the question as someone willing to entertain the idea that real things exist in the abstract as well as the material world. From that view, what is software made out of? Well, then it’s made out of code. Code is like words on a page. Materially, it’s made out of ink and paper, but in the abstract, words have actual meaning and they exist as an entity separate from the paper, not made of matter, but real nonetheless. Code is in the same category. It’s not of the material world, but it matters. Freaky to think about.
And what’s the code made out of? It’s made out of mental constructs. I’ll call on the great Fred Brooks1 to back me up on this.
In his great article, No Silver Bullet, Brooks takes a note from Aristotle and divides software into essence - “the difficulties inherent in the nature of software” - and accident - “those difficulties that today attend its production but that are not inherent.” He defines the essence of software (what it’s made out of) as follows:
The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions.
Fred P. Brooks - No Silver Bullet
So the essence of software is the constructs and concepts we create in our heads which get represented in the code as functions, classes, data, etc. The accidental parts of software are everything else - the languages, the frameworks, the IDEs, the hardware it runs on - all accidental, and in my opinion, subordinate to, the essence.
This is a big point to make, so I want to make it really clear:
Software is made out of thought. Therefore, your job as a software engineer is not merely to write code. Your job is to think. The code you write is simply the delivery mechanism for your thinking, just as the words of an author deliver the idea they wish to express. To the degree that you can express clear thinking in clear code, you are a good programmer. This takes two skills, which together make programmers valuable -the ability to think clearly, and the ability to understand the technical intricacies of some programming language or tool.
Sometimes writing the code helps clarify your thinking, or concretize it, in just the same way an essayist begins writing to see what comes out so they can filter out the bad ideas. That’s a good reason to write code. Sometimes code gets written simply to see if something will work, that’s fine too. Just remember, the code is not the value you provide, the value you provide is your thought, concretized as code. That code becomes a program once it’s compiled and running on the target machine. This program provides value to a user only if you thought through it clearly first. It provides value to your product team only if you thought clearly enough to anticipate and defend against future changes. The value provided is a direct result of thinking and expressing.
To the degree that you can express clear thinking in clear code, you are a good programmer.
Back to the Question
So, how does all this relate to AI?
Suppose we have the ultimate AI coder. It can code an entire system for you in an instant if you ask it to. All you have to do is tell it what you want, wait a bit, and bam there’s your product. Shh… I hear a product manager coming.
Let’s have this bot create an online retail store to sell off the excess clothes in your house.
“Hello bot, can you make me an online retail store to sell off the excess clothes in my house? It needs a web-based storefront, integrated payment through my Stripe account, and an administrative portal where I can upload photos and new clothing to list for sale. It should be mobile responsive so I can use it while I’m criss-crossed on the floor of my closet without having to get out my laptop.”
“Great idea!” says the bot. “I’ll get started.” And it spits out a first prototype in a few moments.
Is that prototype going to be exactly what you want? No way. It can’t be, because you don’t even know what you want yet. Suppose you realize you’d prefer a different color scheme. So you have to specify the color scheme to the bot. Oh, and what picture to show on the landing page. And then you notice that login should actually hook up to Apple login, not just Google. And then you think maybe people should bid on items, so you can get more cash for that retro Luis Vuitton suitcase you bought in Paris. So now you have to tell it that. In a scenario like this, you might as well give it everything you can think to add to the store. It’s gonna be a complex store.
Iteration after iteration go by and your chat thread with the bot grows longer and longer, and ever more precise. Eventually, it gets complex enough that you have to refer to previous messages in the chat history to resolve contradictions. Now you have to manage your chat history. You think it might be easier to split up the chat history into bite size sections you can analyze one at a time. You just reinvented modules.
Now when your app hits the web, you go to use it and realize that bids aren’t getting prioritized in the order you want, so you have to specify that to the bot. You update the bidding module. The chat bot handles it with no problem, it’s a perfect coder.
If you took all the text you fed that AI and saved it to a file, what is it? It’s code, in every sense of the word. It’s a reasonably precise and comprehensive specification for how the online store should operate. It’s thought-stuff concretized into words. It can be compiled down into a program by feeding it to an AI who generates code which generates machine code which runs on the computer.
So you see, even if chat bots become perfect coders, we’re just operating at a different level of abstraction. We’re still thinking, which is our job. Therefore, we’re still doing our job - even though it changed radically.
Now, it’s worth asking yourself if you want that job. But past that, to stay relevant all you have to do is watch and experiment as new developer tools come out with AI integration.
Some More Historical Context
Many programmers who have been around longer than me remember days when new web frameworks, like Django or Rails, would make it so anyone could program. People thought they would lose their jobs then.
Before then, no-code and low-code solutions were going to be the end of programming. Product managers would just have to input their precise, comprehensive specification into the no-code system and then… oh wait. It turns out that coming up with the precise comprehensive specification is the hard part. And most of these no-code solutions weren’t flexible enough to handle that level of specificity so programmers were required to understand and utilize the minutiae of the no-code tools or even to extend the tools for the businesses using them.
Even before then, programmers were worried when high level languages came out (like C), because that meant programming didn’t require intimate knowledge of the inner workings of the machine the code was running on. You know those guys who literally coded in binary by flipping switches on ancient machines that took up rooms of space? They had the same concern.
Companies have always been trying to axe programmers because making software is complicated, and the smart people you need to do it are expensive. But as long as you as a programmer are someone who can handle complex thinking in a changing environment - you’re ok.
The point is, the level of abstraction keeps moving, but the essence of software hasn’t changed. Higher levels of abstraction enable us to be more productive. Historically, demand for software has outpaced production. I see no reason that won’t continue to be the case. If those assumptions hold, there will be jobs to fill as a programmer. In the near term, people are banking on something they wish would happen, so they implement hire freezes and my friend can’t find a job. It’s sad, but I think it’s temporary.
Don’t worry.
Further reading:
Fred Brooks wrote The Mythical Man-Month, an essential read for all software engineers despite it’s ancient publication date of *gasp* 1974.
Clear thinking and good writing. Well done.