At the start of my career I was being paid for the code I wrote.

By the end of my career I was being paid for the code I didn't have to write.

One of the nicest complements I ever got from a coworker was that he was astonished how much I accomplished with so little code. Everything I built was designed to be easily and quickly extensible with minimal changes, I planned my structure for future needs.

That is why high paid programmers have been in demand, because learning that takes more than intelligence, it takes wisdom.

I think "Code was never the hardest part" is more fair.

Code itself can absolutely be difficult, but it's seldom the most difficult part of a project. Generally the hard part is actually figuring out what you want, and how to achieve what you want, then the actual code is pretty straightforward in most cases.

I've been programming since the the 1980s and I'm not insulted by the idea that code isn't the hard part.

Given a well-defined set of requirements, writing correct code (pre 2026 LLMs) IS a hard task. There is only a small set of the population that, even after several years of training, can write correct code; this scarcity is what made coding one of the highest salaried professions.

However, coding in itself generates no value to a business. A business makes money by solving its users' problems; coding is just one of the means to do so.

This article is directionally correct (although a bit verbose) in adding that the best programmers did not ONLY write correct code, but also expanded their scope to understand how best to solve user problems.

Starts with a rant that appeals to hardcore programmers and then tells them to adapt.

Of course he is an AI consultant among other things.

It seems the author has misunderstood the point of the common narrative and has torn apart what’s essentially a strawman.

The degrees, the books, that’s not the supposedly easy part. That’s the HARD PART, and it’s actually the “what you build” thing. What you build is the code architecture, knowing how to conjure objects, methods, modules, lambdas out of thin air in a way that faithfully represents a real-world problem. Literally the shape of the resulting code. It’s not product or CS.

The easy part is supposed to be actually typing out the code, putting the methods together, remembering method names and syntax quirks.

All of our developers are now using agents. We're not hand-writing code at all anymore. And yet, some of our developers deliver stories in an hour, others deliver similar complexity stories in a week. Executives are surprised to discover they cannot simply turn over a product-authored jira story and have it yield a single agent-written PR. There is still significant work that happens between the point at which a story is written, and the point at which correct prompts are input that generate the code that fits the requirements. Very significant work. I think that when people say "code was never the hard part", they're only guilty of eliding the point that "code was never the only part" or "the hardest part", and that there's so much other stuff that programmers do at various levels of competency, and that... perhaps up to now it was easy for product folks and execs gloss over since they just put us all in one bucket of "people that write code".

Yes, writing code that (appears to) work was not the hard part. Even before LLMs you could find very cheap contractors on Upwork or through offshoring companies to write "code".

Well-engineered code is hard. It still is. Code that is reliable, extensible, maintainable, scalable, legible, understandable is hard. Code where the specs and the "why" behind it were pressure-tested via thought and good intuition.

You seem to be misunderstanding the premise of the statement. Go write, "print 'foo';" and copy and paste that statement one hundred thousand times. Congratulations, you just wrote one hundred thousand lines of functioning code! Was that hard? No? Okay, so how is this different from other code? The difference is that it's easy to _understand_ how that code works, because it's the same behavior repeated over and over. So, writing code is easy, but understanding code is difficult! And, when we code with AI, undertanding is precisely the part that it can't handle, even though that's where almost all of the value is!

I never had burnout from writing code; I had burnout from PM changing priorities every day or from tickets being half-baked. Also been burned out from being awakened that switch in somewhere in the Middle East had high CPU usage, which I was on call for for some reason (I wasn't on the network team, but that team didn't have bandwidth to be on call)

Writing code is easy; that's why I do it as a hobby on weekends as well. I don't have to sit through five arch review meetings that talk about how we are going to name the class rather than what the API contract is supposed to be.

Sure, writing good C is hard, and writing PHP (used to be) hard because language design is full of inconsistencies. There is so little "hard" code that I wrote for money. Plenty of somewhat harder things that I wrote for myself because it's entertaining. There was a time when I had to spend more time getting a pull request ready than actually writing code in that PR.

Coding is the act of translating an algorithm or system design into a specific programming language/framework/libraries domain. That part was never the hard part as it was mostly about learning the syntax/conventions etc of that stack and then doing the translation. The hard part is about coming up with righ algorithms and system design for your particular software and evoling that over time without breaking it (the "evolving over time" part is the most tricky part).