That's like saying "building a car is not hard, building a real car that you can use and that passes regulation is".
IOW, writing code is hard in every reasonable context.
Likewise, coding is easy. It's just writing, and any child can learn it. Coding is not programming, and the hard part of the job lives in that distinction.
Any teacher of a low level CS course knows this is completely untrue. In my CS 101 course our problems were relatively straightforward and short, and lots of people struggled mightily to the point of dropping the course. IMO coding requires a particular way of thinking that a large subset of people just aren't good at, and as someone whose done tons of screening interviews at college recruiting fairs where I give relatively easy problems and ask someone to code a solution, I will tell you the idea that anyone can do it is just false.
In it's original context, it's very clear what "Code was never the hard part" was referring to, that of all the steps of product development (ideation, requirements, design, implementation (coding), deployment, operations, maint, etc.), that code was not the hard part. That's the meaning we should be discussing, and I agree with the author, I believe coding very much was the hard part. Since Jeff Dean and Sanjay Ghemawat were recently in the news, I recall some stories about them fixing issues with the search index in the early days of Google where there were random bit flips that were causing the index to be corrupted, and they fixed it and coded a durable solution. This is very much just a code-specific problem that very, very few other people would have been able to solve.
English has simple conjugations. That makes it much easier to learn to speak intelligibly even for adults. Old English dropped many of the complicated word endings because it was used by Anglo-Saxons with Vikings and Normans.
Understanding of grammar and rules of a language is like having good bricks, but building a stylish house is more than just using good bricks. It's a higher level cognitive exercise. Schools attempt to teach this, but i think they fail quite miserably (look at how essays had to be written by students, and how poorly most are written).
Methinks you're splitting the wrong hair here.
The truly difficult work is knowing when your client/boss asks you to "build a car," do they really just want/need a small Pinewood derby box car as a toy, do they need a four-door sedan that can legally drive on major highways, an 18-wheeler freight truck, or do they actually need/want a bicycle, or a shopping cart, or a railroad box car, or information about how to take public transit that will serve them cheaper and easier than anything you could build in their timeframe and budget.
That's what people mean when they say that code was never the hard part.
[1]: https://missiongraduatenm.org/college-dropout-statistics/#:~...
[2]: https://www.coursmos.com/college-dropout-statistics/#:~:text...
The fact that children cannot do it does not mean that it is particularly hard, and computer science attracts a lot of people who just like video games and have no mathematical ability.
I think that the fact that programmers were/are doing a lot of the job that other positions take credit for is significant. Others can get by on bullshit, but the programmer's job in turning that bullshit into code forces them to make something real out of it through a combination of back-and-forth interrogation and just making it up when necessary. Turning handwaving into a product is a skill that programmers have, and is why AI isn't helping tech-illiterate businessmen create things that work.
Now add the time dimension - keeping code correct as the business and the people in it change.
That's how I explain to people that LLMs will not replace us developers.
Timestamp is: 36:42-39:55
I believe Graeber perfectly predicts the problems, in 2019, with vibe coding creating immediate "value" from production, but failing to produce true value through maintaining the system (like one continually washes a cup to give it value over time).
But it doesn't give value, it prevents value loss.
I don't know why people are telling themselves maintenance work is virtuous. It's waste. It's necessary waste, and doing the work may be virtuous, but the work itself is pure waste. Fighting entropy.
EDIT:
I wish we talked more about the need for low-maintenance patterns and products. In this industry, many of us already recognize this instinctively, but we often misattribute the problem to "complexity". Think of e.g. rather substantial niches and common practices among developers, like static site generators, no-build-step development, or on the backend side, the popularity of header-only libraries in C and C++. All these tend to be labeled as reducing dependencies, but that's just the means - what they do is they minimize independently rotting parts. The build system isn't bad because it's complex - it's bad because you have to constantly babysit it. Conversely, a static site once rendered will open ~forevermore, and so will a piece of C/C++ code that relies on single-header libraries.
Similarly, the popularity of containers is in large part this. All the mess isolated in a self-contained bundle that is preserved against rot, at least for a while. Inside, there's nothing to maintain - it works until it's not needed, or until the "outside world" changed too much, at which point you throw the thing away and get a new one. Etc.
It keeps thing operational. Software changes because requirements changes, the context it is used it changes, or just the iterative nature of it where features are rolled out over time so that users can immediately start getting some functionality if not all that was originally planned (MVP).
Maintenance work is neither virtuous nor waste. Its just nature of the things we build.
I agree however with the part on more talk about low-maintenance patterns and products. IMO its often the trade-off between velocity vs quality/technical debt. So it happens, industry is favoring more and more towards velocity for delivering features that often add little value to the users, just because $$$, competition and maybe the grind culture.
Would you not say that this is essentially labour holding up the value?
And I agree about low maintenance products being necessary, the example of the static site is good because the files could be described as becoming a stateless transformation of data!
The few people who manage to write good quality production apps with AI are developers whether they like it or not and that number isn't high enough to obsolete existing developers.
You are conflating "not understanding how to build software" with "not knowing how to write code". Most developers I've crossed paths with couldn't build a consistent library, let alone a complete, well written, architecturally sound and useful application. Sure, I also know plenty that don't fall into that category but those are the few.
Problems with deploy? Ask claude, use ssh with key-based auth and he will take care of it :) just saying.
I've been writing code "almost daily" for the last 35 years; been doing it professionally for at least 29 years. I've been around, and my peers consider me a proficient developer. I've built stuff ranging from embedded/os level development to DSL languages, from 3D programming to VBA macros. I wrote software used by me, and wrote software used by millions. In some cases, I've maintained products written by me nore than a decade. By your definition, I must be wrong, truth is I can afford to be wrong - my job is not writing code, is designing solutions. Writing code is often the easiest part, and we're mostly automating it. Thank god.
This already goes over the heads of most non-developers.
I think you're misunderstanding my point. It's not that LLMs aren't a useful tool or that they won't replace some developers. But rather that software development as a specialty won't go away because most people can't build software with LLMs in a way that won't blow up.
(In interesting ways this is programming’s greatest boon and curse: if we treated it more like building bridges or cars, the world would be a very different place.)
I had to make some software changes to an old medical device this year. The overwhelming majority of the effort was understanding what the customer wanted and giving them feedback into how that would change the existing system and the risks associated. Then, creating a plan to follow the necessary standard (IEC62304) and creating the associated documentation and getting it reviewed and approved.
The actual code that changed was probably only around 100 LOC but the project took several months. Heck, the code was simple enough that an intern could have done it.
(The distinction I’m making is between the code that operates the medical device and the code that operates the app I make doctors’ appointments in. The latter is subjected to a different - and lighter - regime than the former.)
Because when I submit building plans, they are manually reviewed and approved (or denied) by registered architects, engineers, and planners employed by the authority for just this purpose.
I'm sure other highly regulated industries also have their code audited.
There are the executives, the lawyers, the product managers, sometimes the designers, who to varying degrees determine this before they land in the requirements the programmer sees. But there are also the libraries and APIs the company pays to handle compliance so that the company and the programmer doesn't. The programmer implements the library (and may not even had a say in or necessarily care which one was chosen).
I mean, this was drilled into me at uni — that software was not likely to escape regulation forever and that you can't know with certainty how all the code you're writing will be used when you're not observing the use.
For example, under what constraint regime should the calculator app bundled with an OS be written? It's just a little bundled toy app. Until someone under pressure uses it to calculate a medicine dose, expecting it to be a calculator like it says.
Perhaps this gives away my age more than anything else.
This captures a sentiment I have often felt when people don't take bugs seriously. Or don't take it seriously that they introduced regressions. You should feel personal responsibility for your bugs. When your shit doesn't work, and people are trying to use it, you are basically hurting them, personally.
But it seems with the increase of AI coding, the industry is going the other direction. Nobody seems to care about bugs introduced by slop coding. Except perhaps the users.
I honestly have failed to see the value of anyone wearing an official "Software Architect" hat in my 20 years of being in or leading high performing software development teams: yes, we built and maintained complex systems with multi-team dependencies, did that effectively and maintained and evolved them over time.
I've seen an Architect who is still doing the coding, but they are never available when you need them. I've seen an Architect who is always available, but so far removed from actual project that their advice is only somewhat worse (if they are good — or a lot worse if they are bad) than what a good senior in the team engineer or tech lead would offer. And an Architect who would happily design for the use cases that might come in 2 years (read never) using complex abstractions only they can understand, leading to decoupling of architectural pieces to 10 teams which could be built better by 1 or 2.
Do I want our industry to be regulated by these folk? No.
I have nevertheless always written code on the basis that it might one day encounter proper scrutiny.
Ultimately in the parallel universe where chartered software engineers became the norm, the scenarios you are talking about would be different, for structural reasons.
It's never going to happen in this universe.
However, I am currently in an enterprise org suffering from compliance/certification overhead while pretending that they do all of the good stuff topped with a highly infectious NIH syndrome (we build our own payment system, authentication system, wrap all the levels of cloud platforms and mobile platforms...). Trying to put more quality in gets opposition from... Quality Engineering, which is a separate department of people who've never written a line of code in their lives — because they need to be consulted and give a stamp of approval on any change, even if it's for the better :O We've got highly specialized roles of Software Architects, System Architects, System Engineers, Quality Engineering, System Validation, Software Validation, System Verification, Software Verification... It frequently becomes funny trying to make a single decision ;-) I don't have to imagine a world where something like this happens, because it exists in some enterprise orgs.
But the fact of life is that even in actual civil engineering, at every phase of building, there is a step of reviewing construction as it is built when constructions actually diverges from the project (happens quite a bit). Most of these get approved if they are not detrimental to the core function and structural integrity — this leaves the opportunity to contractors to actually do what makes more sense from their experience and still pass inspection.
This group of people would never understand that because they are mostly optimizing for appearing useful and invaluable, instead of for business or customer value.
Yeah — perhaps unsurprisingly an industry struggling to cope with absurd complexity and change has invented and in some cases reinvented a lot of the kind of tooling and process that engineers were talking about in the 90s.
The level of quality needed (or imposed) will vary. It is a wide spectrum from dealing with banking/transactions (money at risk) to brake controllers and auto pilots (human lives at risk). But there is a lot of this, all over the world.
I work somewhere in the middle (rather slow but extremely heavy industrial equipment, where emergency stop is always a safe if costly option). There are domains where emergency stop is not a thing though: some systems on an aircraft in flight, a pacemaker, etc.
My point is though, that there is a ton of code where stakes are higher than "oops, I guess we will fix it next sprint". And while not all of that have regulatory constraints, sometimes a company realises that the financial cost of issues significant enough that it is worth holding themselves to higher standards anyway.
For those cases where it is true, it is pretty much like your example, and the distinction is there in your example just like theirs. You supported their point.
This is worth saying precisely because of this difference - people see huge amounts of bad code generated by LLMs and think it is equivalent to carefully written code because the results look similar at first glance and they don’t bother to read it.
Communicating like this is to try to get them to understand that The Code is barely about the text on the screen and is instead about much more - both abstract in the code (but how on earth do you explain that to someone nontechnical without just sounding like "no trust me my job is really hard, I promise.") and also in all the external stuff - the world The Code lives in (users, ops, support staff...).
Is it a perfect analogy? Of course not, and I'd never explain it like this to someone technical. But they're not the audience.
---
Adjacent: I've always gotten the feeling that even the most well-meaning/trusting nontechnical leaders have always been fairly nonplussed by software complexity and software development.
Deep down, they seem to think it can't possibly be that hard, despite the fact they can't write it themselves. Sometimes, even worse, they have dabbled in writing small, or even medium-sized solo projects. And think - well isn't software engineering just doing that but with other people? And their attitudes can reflect them, sometimes all the time, sometimes just slipping through when under duress like delayed projects etc.
And yet despite their attitudes, they then also find:
- if they try to outsource, they have a bad time
- if they try to proooompt, they have a bad time
- if they try to pay less, they have a bad time
and so the invisible hand of the free market itself forces their hand in paying prodigious salaries and fighting to retain talent. And all throughout they remain internally nonplussed even if they manage to keep up appearances.
That said, it's still reasonable to think that once (and only once) the hard part is done, then the easy part is easy. It would just be wrong to think that you can do the whole thing without having to do hard parts. I think the argument here is that with AI this is more possible—that the tasks are more separable. Even if it's the same one person doing the hard stuff and then passing what they learned to the AI to do the easy stuff.
Two reasons they might not separate well (there are others):
- If in a company's product development it's hard(er) to have one person doing H and another doing E, then you're generally going to have one person doing H and E. More or less, this means a person can only do E easily if they do H beforehand. So hard things are required no matter what.
- People come in whole persons. If people skilled/educated to do H tend to be the same people skilled/educated to do E (can be because of how programming is educated, but also can be because there aren't that many programmers), then you're always going to be plugging programmers who have both H and E into roles and it'll probably be more efficient to plug them into roles requiring both rather than just H or just E. You could, within that population, determine who is comparatively advantaged (and we do do this mildly with senior vs junior or with "architects"), but plugging a person into an E-only role is going to involve that person questioning what happened during the H part beforehand. In part because they're good enough at H to question it, but more importantly because they're implementing the H such that they're aware when their E might not be as easy as it could be.
Both of these seem like they might be less true now with AI (and also perhaps because there are more programmers).
Even in academia, you have meta structures that you constantly need to think about.
Of course, you can keep trying to isolate the "pure" thing from the "accidentals", but it's not going to work when the work gets sufficiently complex