Why the Claim That Code Was Never the Hard Part Makes People So Angry

• When That Sentence Comes Up in a Meeting, the Temperature of the Room Changes
• The Questions the Original Post Throws Out
• The Real Reason It Provokes Anger Is Equivocation
• That Does Not Mean the Other Side Is Entirely Right
• Split Code into Three Layers and the Argument Ends
• Measuring Which Layer Your Team Spends Time On
• Tools Are Worth Different Amounts at Each Layer
• So What Should You Practice
• References

When That Sentence Comes Up in a Meeting, the Temperature of the Room Changes

In a quarterly planning meeting someone says: "Writing code is not the hard part anymore, so we can focus more on what to build."

The person who said it probably meant well. But the engineers in the room go stiff. You want to push back and no good sentence comes to mind. Saying "code is hard too" sounds defensive, and letting it pass means that premise goes straight into next quarter's headcount plan.

The Questions the Original Post Throws Out

In a post published on August 8, 2026 that was heavily discussed on Hacker News, Senko Rašić meets this sentence head on. His method is not argumentation but asking questions.

If coding is easy, why was demand for programmers so high and why were wages so high? If coding is easy, why do thick books like Clean Code and The Pragmatic Programmer exist? If coding is easy, why do people get angry about their code being copied? And flipping the direction: if deciding what to build is the hard part, why do so many product people look like they cannot find their footing?

The conclusion refuses the either-or. It has to be both, and the piece ends with a sentence telling you not to outsource understanding, judgment, empathy, and taste to AI.

The Real Reason It Provokes Anger Is Equivocation

I agree with this rebuttal, and yet why that sentence in particular provokes anger can be explained a bit differently. The problem is not whether it is true or false but that the word changes meaning midway.

In the sentence "code is not the hard part," code first appears in a narrow sense: knowing the syntax, looking up an API, typing. In that sense the sentence is correct. Then, as the conversation proceeds, the same word quietly widens. By the time we reach the conclusion, code refers to engineering as a whole, and so the proposition "engineering is not the hard part" passes without anyone having proved it.

The listener gets angry because of that passage. To push back you first have to put the word back where it was, and doing that mid-meeting takes many sentences, and while you are at it the discussion moves to the next agenda item.

This structure works identically in other professions. In "design is easy now," design starts by referring to producing mockups and swallows problem definition; in "writing is easy now," writing starts by referring to polishing sentences and swallows the construction of an argument. Every time, the discussion goes off the rails at the same place in the same way, and the fact that the derailment lives in a word is rarely pointed out.

That Does Not Mean the Other Side Is Entirely Right

Here we have to hold the balance. The original sentence clearly has a true part.

Deciding what to build really is hard. Every stakeholder wants something different, what they say and what they need are different, and requirements change while you are building. Failure in this area is not recovered by however good the code is. A well-built feature nobody needed is just well-built waste.

So if you drag this argument into "code is hard vs. requirements are hard," it does not end at the place where each side is half right; it repeats without either half being acknowledged. The way out is to split the word.

Split Code into Three Layers and the Argument Ends

The activity we lump together as coding divides into at least three layers.

Once this distinction is in place you can see immediately where each claim is true. The statement that code is not the hard part is strongly true of layer one, partially true of layer two, and unsupported for layer three. And the reason the original sentence provokes anger is that it drags the truth of layer one all the way up to layer three.

Measuring Which Layer Your Team Spends Time On

This distinction is useful because it can be measured. To stop arguing by feel, you need to know your own team's distribution.

Two-week experiment: attach exactly one tag to each completed task

L1  spent most of the time on syntax, APIs, formulaic transformations
L2  spent most of the time deciding structure, boundaries, constraints
L3  spent most of the time weighing invariants, failure modes, migrations
RQ  spent most of the time figuring out what to build

After two weeks, look at the four numbers. Discuss this distribution instead of arguing.

Try it and the results usually differ a lot from team to team. A team building a new service is high on L1 and RQ; a team maintaining a ten-year-old system is overwhelmingly L3. And because these distributions differ, the two teams react to the same sentence in completely different ways. For one of them the sentence is a fact; for the other it sounds like their whole job was just erased.

It matters that a task gets exactly one tag. Allow several and everything gets three tags and the distribution disappears. Making people pick only the layer they spent the most time on has a side benefit: the more ambiguous the task, the more the act of choosing forces them to sort out what they actually did. If two weeks is not enough, stretch it to four, but you have to promise up front that the results will not be used in individual performance reviews or the numbers will not be honest.

Tools Are Worth Different Amounts at Each Layer

Once you know the distribution the next decision gets easier, because AI tools are worth different amounts at each layer.

At layer one the value is large. There is little room for argument here, and in fact most of the felt productivity gain comes from here. At layer two the value is conditional. If you can state the constraints explicitly you can get several good options, but if you cannot put the constraints into words you get a competent default back. At layer three the value is smallest, because a large share of the invariants and failure modes are written down nowhere and live only in people's heads.

So an organization thick with layer three that builds its headcount plan on the premise that "code is easy now" is exactly the organization that gets hurt the most. Conversely, an organization thick with layer one that delays adopting tools is losing out too. The same sentence has to lead to a different prescription in each organization.

So What Should You Practice

The original conclusion was not to outsource understanding, judgment, empathy, and taste. Put the layer distinction on top and that advice turns into more concrete behavior.

More of layer three can be moved into documentation than you would think. Turn invariants into executable checks rather than code comments, write known failure modes into the runbook, and record the alternatives you discarded when you decided a migration path. This is not for the tools, it is for the people. Knowledge that lives only in someone's head disappears when that person leaves the team, and at that moment the organization's layer three really is empty.

Layer two takes a slightly different practice. Skill at this layer is nearly identical to the ability to put constraints into words, so the habit of writing out the conditions you must satisfy as a list before you start implementing is itself the training. If you cannot write the conditions, you do not understand the problem yet, and a product that came out of that state cannot be reviewed no matter who made it.

And back to the meeting: the next time that sentence comes up, you can just ask back. Which layer do you mean? That one question turns the conversation from an emotional issue into a planning issue, and nobody in the room has to defend their job.

References

• "Code was never the hard part" is an insult to all programmers — Senko Rašić, 2026-08-08 — the questions and the conclusion quoted in this post are the content of that piece.
• The Hacker News discussion — a fair number of opposing opinions were posted, and those counterarguments are worth reading alongside it.
• Related post on this blog: When Friction Disappears, Taste Does Not Remain — the Path to Growing Taste Disappears
• The three-layer split and the two-week experiment do not appear in the original; they are a frame I put together.