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.

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

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

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.

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.

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.

> (Isn't that what sales is? Working with the customer to tease out the real thing they need solving?)

For any product of any complexity you can can essentially never successfully delegate that process to a non-programmer.

Indeed you can not that often even trust that the client employee doing the asking knows what it is they need. Almost certainly someone in the organisation who was not in the meeting is better placed to tell you what is actually required.

This task needs an analyst; that analyst needs to have experience of writing meaningful code.

[dead]

I think this is true when you realize "customer" means "coworker" or "person on the next team over" or "management" or "your intuition about the problem". Which all sort of have the same shape.

Agree. What a strange perspective. Engineering is what is hard, and that includes coding and non-coding activities but doesn’t require customer interrogation.

That has only been true in the largest corporation I've worked for (around $4bn annually). Even then, we (devs) had to challenge inconsistencies in requirements or incomplete specifications. The only job I've ever had where I could just do exactly what I was told and get away with it was right after I got out of college.

That job was often called a "business analyst" in "the old days".

Not in agency or consulting jobs.

“The best code is the code you didn’t have to write” - a wise coder

The point of the OP in this case wasn't code that compiles, but code that does what the customer wants. If the customer orders an email client but really wants a chat application, coding a working email client is not "correct". And insisting that the customer ordered the wrong thing won't change the reality of the matter.

Writing code doesn't have a notably higher (if at all higher, vs lower!) IQ requirement compared to some of the basic components of EE or MechE work. Programmer salaries have been driven up by the ability to write-once-sell-globally and the dramatic profit margin difference between that and, say, producing chips where there's a much higher fixed cost due to the need for more real material, tooling, etc. Many of those roles require a much higher-than-baseline-skill, but it pulls up the compensation competition for almost everyone else too. (Though even then there are a lot of unglamorous, line-of-business, internal-tools-programming work that's not paid particularly well even in a lot of parts of the US far from the big tech companies.)

I've watched dozens of people try to learn to code and fail, some definitely not for a lack of trying. Of those that did learn, only a fraction had the IQ or passion to be genuinely good at it.

The difficulty of it has absolutely been a bottleneck to the supply of good devs, keeping salaries high.

Product should, definitely, run user research along with Product Design. But what I find is that people in either have a problem imagining a solution that's a couple of orders of magnitude easier to build, but also much easier for our customers (usually boils down to making the right choices for customers — the savings are not in the common "choose good defaults", but in actually removing flexibility that's needed only in 1% of cases).

Thus, I insist on engineering being involved early to put real world constraints on wild ideation ("it would take 3 months for 5 engineers" quickly changes what's a must-have :)) — sometimes, a curious, critical mind can expose things like these without having to do the research or user testing themselves.

Now, throughout my 20 year career, it's been very rare to find a product person who will both understand customers deeply, tie their needs to business value, and be able to formalize the intersection of these in a form of good requirements for design and engineering to eventually build!

So I really believe an engineer's (and design) role there is to serve as a sanity check as they dive into actual building — does this really make sense? If they do not, they run the risk of a project completely failing or perhaps not even shipping once someone else questions the value of continuing to invest in this 3 month project 9 months in. ;-)

There’s a minimum karma requirement.

Understanding requirements means talking to customers. A customer can be anyone, even other devs that consume your code/product.