Speaking/writing English is easy. Writing literature at the level of Shakespeare is hard. Writing educational content that makes hard concepts accessible like Grant Sanderson is hard.

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.

But I must insist: "building a car" is not hard (millions of children do so every year with Pinewood derby style box car kits), building a "real car" that you can use and that passes regulations is harder, but knowing the difference between the two is where the real hard work is.

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.

> Writing code is not hard. Writing correct code is.

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.

How many programmers operate under that kind of regulatory and operational constraint regime? I think most don’t.

(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.)

90% of code wouldn't pass a basic audit, let alone any sort of regulatory scrutiny. Developers are building the easy version most of the time.

The problem is that non-technical people just see The Code. And now when they prompt an LLM they also see The Code. Voila - finally we don't need those pesky engineers.

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.

Your analogy breaks down because code is not heavily regulated as cars are.

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.

For me this metaphor only makes the original point more credible.

Absolutely there can be a bunch of hard things wrapped around easy things. When those things can't be separated neatly than it doesn't make sense to separate them such that we can call the easy parts easy (or even parts really).

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).

I mean, I think the point is, every discipline isn't ever that discipline in a vacuum, it touches the real world, and we build meta-structures around said things that may not look like programming, but certainly require deep programming SME.

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

The reason people say "writing code isn't the hard part" is because the only thing an LLM saves effort on is typing code into the computer. You still have to know what the code should do, and you still have to review the code the LLM generated to make sure it is reasonable. In other words, you still have to do the hardest parts of your job, and the LLM only saves you effort on something which was no real effort to begin with. That is why they are an ineffective tool, because they are helping you with the bits you don't actually need help with.

I don't agree that "the coding was never the hard part" in general, but it is true at least often.

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.