“Code was never the hard part” is an insult to all programmers

Chainsaw isn't better than the lumberjack.

> Is The Art of Computer Programming a light summer read? Is SICP a coffee-table book?

I still read TAOCP occasionally as a hobby. The combinatorial algorithms and data structures are just fascinating. That said, this argument seems irrelevant to majority of the programming jobs. I doubt most engineers will ever need to implement anything mentioned in TAOCP, thanks for all kinds of powerful abstractions.

It’s not that coding is easy, it’s more that coding was not the bottleneck in the process at large organizations. It was (and still is) getting agreement on what to build, meeting with stakeholders, and dealing with the ever-changing priorities.

A lot of people enjoy coding, it’s the rest of the job they don’t like. That’s why it feels hard.

If a tool was going to come along and automate away a huge part of a programmer’s job, I think most would want that tool to eliminate the meetings, ambiguity, scope creep, and administrative work… not the coding itself.

My best days at work were days with nothing on my calendar, when I could just put on some headphones and make something. At the end of the day I felt like I accomplished something and had something I could see and use to show for it; I finished the day happy and energized. Contrast that with a day full of meetings, fire drills, and busy work, where at the end of the day I’m mentally and emotionally drained, wondering if I should quit to stock shelves at the local grocery store. Which day sounds “harder”?

I don’t know about where everyone else works, but defining the details of what to build seems so hard that no one actually does it, so it falls on us as we build things. During one project I got a directive from the CIO (which has only happened 1 time in 20 years) to get what I was working on done in 4 weeks. I made all the decisions myself when it came to the details and had something mostly working in 2 weeks (I skipped all meetings and any other distractions during this time). Several months later, the bureaucracy came into play. The principal architect on the project, who I never talked to before the CIO told me to get it done, finished his design and some details needed to be worked out. One such detail was a port list. It took 4+ months of meetings to get that done, and it still required constant tweaking after that for another year. There was a half dozen other things like that in the same project. So yeah, the initial code was pretty quick and fun to write, and then it was followed by 2-3 years of hell, that probably should have been worked out before we started coding. I ended up having to go back and re-write a bunch of stuff to align with the design that was decided on over a year after the deadline the CIO gave me. In most cases, I think the updated code is worse, as the bureaucratic design creates a lot of operational work that my original design avoided entirely, but I digress.

Coding is not programming.

Typing code is indeed not the hard part, programming is.

These comments reveal a stark reality: most HN commenters have never worked on a really hard problem. They think hard problems are leetcode hards that have a prescribed list of known techniques to apply.

They think communication, alignment, gathering requirements, and other political bullshit is the hard part because they have never actually solved or had to grapple with a truly hard problem.

That’s fine, but it shows the corporate programmer who is probably in meetings all day has a vastly different reality than those of us who have had to solve open problems with no solution written somewhere because there is none.

"Code was never the hard part" misses the point but so does this blog post. This blog post from 2011 is worth reading and really cuts into the middle of the dreads-of-programmer.

https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

  Don’t call yourself a programmer: “Programmer” sounds like “anomalously high-cost peon who types some mumbo-jumbo into some other mumbo-jumbo.”  If you call yourself a programmer, someone is already working on a way to get you fired.  You know Salesforce, widely perceived among engineers to be a Software as a Services company?  Their motto and sales point is “No Software”, which conveys to their actual customers “You know those programmers you have working on your internal systems?  If you used Salesforce, you could fire half of them and pocket part of the difference in your bonus.”  (There’s nothing wrong with this, by the way.  You’re in the business of unemploying people.  If you think that is unfair, go back to school and study something that doesn’t matter.)

Agreed.

"Code was never the hard part" is the dumbest thing I've ever heard.

Making something work, has always been easier than making something someone can read. AIs also, seem to benefit from clean abstractions, appropriate code reuse, etc. (coincidentally, the thing they suck most at).

It's the same thing with english, except that english doesn't have a compiler. Comprehension is the only measure of communication if you're talking about a human language. Programming shares the same goal. Both, often also need to do something else useful. Programming, and lawyering, have a lot more in common than people think.

We're creating a culture of sh*tting on codebases so the highest paid execs can cash out when things get tough. It isn't a new phenomenon, but it's one we'll need to endure until enough people lose enough money that the accountants start taking notice and start saying "you should be more careful, or you'll lose your shirt". In the interim, the people that care are working insane hours to try to protect the things they believe in from inevitable doom, and risking being fired to do it. There is a balance to both sides, and the jury is out on whether or not anthropic/openai/alibaba can save us from the future we are creating now with short-term goals.

Code still is the hard part. Or at least one of them.

Code, is written in a language. Language is opinionated. Things written in that language are also opinionated. LLMs often have horrible opinions.

I'm not insulted. I actually agree with that even when I was doing some more "hardcore" low level system programming.

Figuring out what code to write and what not to write was always hard.

The code would come out easier the more time I spent thinking and designing and talking about it with others.

of course, YMMV

Writing code to do a thing is easy.

Writing code that's logical and easy to follow, that can be extended in several likely dimensions without major plumbing work, and that doesn't contain "gotchas" for the maintainer, is not at all easy.

He is right though Coding was hard for many.

Farming was also hard, manual work wise and now machines overtook. It's still hard because of marginalization.

It will happen to Coding, Consulting, Creating work, etc as well.

"The labor is valuable" is basically the refrain of every single laborer in every industrial revolution.

The point isn't that labor isn't "valuable" it's that "value" here is a moral position. This same thesis could have been said about basically any mechanized industry.

There is no putting the genie back in the bottle. You can't un-invent the nuclear bomb, or the printing press, or the steam engine. We need to find a politically stabilizing way forward, and that means we need political coalitions that don't consume themselves with infighting.

Right now we can't even work together to build housing for young people... how the hell are we going to get through this mess without actually trying to build something bigger by making sacrifices.

interestingly ai has reignited the craft of performance and efficiency in programming. overall in the macro timeline i think the profession is going to be in a better place

To some degree the defense just popped up because it’s part of the AI effect, at least in my opinion: https://en.wikipedia.org/wiki/AI_effect

As computing systems become increasingly capable and encroach in our territory that distinguishes us and lead to our success as a species, intelligence (whatever that is or isn’t), we redefine the problem and handwave away the new capabilities.

It’s getting increasingly more difficult to do that in knowledge domains with current frontier agentic systems. They’re not AGI, but they start to make it increasingly difficult to move the goal posts for many people’s comfort.

We really need a lot more philosophers, sociologists, and frankly economists working on this problem: in an era where physical needs were mechanized away and increasingly aspects of the knowledge economy are shifting away, what does it look like in modernity? How do we sustain or adapt our current economic models? What new models may be needed? Do we need to continue to enforce this whole work to survive in an environment where much work is disappearing or at the very least shifting around.

No, we’re not there yet. You still need experts to guide things around, but it’s becoming increasingly easier to do more in this space with less humans. That’s not a trivial change in the US where we put most our eggs in this whole knowledge economy basket.

Almost all of us would agree if this was just better articulated:

"Code was never the hardest part."

There you go. Doesn't imply that coding is easy.

do you know how many eBay clones were out there after Ricardo? how many people built twitter clones? building the website was never the hard part, making people get to it and use it was always the costly and hard part. nobody talks about embedded device programming when they say code was never the hard part.

> If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?

There's probably a lot wrong with the "coding was never the hard part" take, but this quote right here shows that the author is not willing to engage with the actual idea that folks who say this are espousing. Because if the author was discussing these ideas on good faith, he'd know that the answer is obvious: there's much, much more to a software engineer's job than just coding, and that other stuff is very hard to do well, and people pay for that.

Again, I'm not saying the "coding was never the hard part" folks are right, but I really, really hate straw men.

Coding is just a small part of a modern software engineers job. And some may think it isn’t the hardest part.

> Why was there so much stress, overwork and burnout even before AI started churning out 5000-line PRs?

Programming used to be a rare skill. Not so much now. In fact, it hasn't been for well over a decade.

My current employer started aggressively hiring for programmers in India in the early 2010s. They get paid a fraction of what our software engineers do in the US. There are many talented engineers in India, and those who get hired by us either find a way to come to the US for an enormous pay increase, or use us as a stepping stone to quickly find better work. And my employer is seemingly fine with this. They expect these cheap employees to do programming, not engineering.

Programming may not necessarily be easy, but it is cheap. It has become a relatively common skill, driving down its market value. A lot of tech companies were slow to figure this out because times were good, interest was low, and investment was flowing.

AI is waking people up to a truth that has been around for a while now.

This is dishonest. Nobody said "coding is easy" in a void. They said "code isn't the hard part" - in the context of LLMs. The obvious implication being that the actual speed of writing code wasn't the bottleneck. The implication is not that it's easy to think of what to write, or that any of the other parts of coding are easy.

No, code was always difficult.

To be precise, it depends on the domain. The people who could actually write algorithms or core implementations were always a minority. Programmers like me mostly did copy-paste from Stack Overflow or assembled libraries.

It's not that code wasn't difficult—it really was.

In CRUD apps, about 70~80%of the work was building the same thing over and over, so once you got familiar with it, most of it was repetitive practice. But the number of people who could actually create something new was always small.

Most business programs had issues that arose in the application stage, the application layer. In this application layer, only a very small portion involved difficult logic. Most of it was just applied.

The problem is that people often romanticize the lower layers beyond their own, compilers and low level systems, calling that 'real programming,' and in doing so, they make programming seem harder than it is. In reality, the coding that most people make money from is mostly at the abstracted layers. The infrastructure beneath those layers is owned by giant corporations. If you work at one of those giants, that's fine. But beneath them are countless consumers paying those giants, and the coding that targets those consumers isn't that difficult.

In the end, whether coding was difficult or easy depends entirely on which layer you're working in.

What's certain is that coding was difficult, and it still is.

That quotation is coming from programmers themselves.

Managers and execs aren’t saying this it’s the programmers and coders themselves making the claim that coding was never the hard part.

It is still an insult though. It’s an insult to themselves. It’s the lie all programmers including me tell themselves as reality itself insults us. Coding WAS the hard part.

That’s exactly what we were good at. Now our skills are getting owned by automation. How do we face reality shitting in our faces? We lie. We fabricate a reality that’s more acceptable. We frame our environment in a way that still validates our existence. If AI has invalidated all of my programming skill then I need to find something else to support my identity.

> Code was never the hard part

And yet I spent a majority of my career fixing mistakes, including my own

I feel like you're getting hung up in semantics such that your essay doesn't say the obvious: coding is "easy" relative to confidently knowing how and what to do next at every stage.

The comparison does not imply that coding is an easy thing to do, just that it's easier than being really, really good at the bigger picture.

What Carmack did wasn't hard because writing C is hard.

The software world has an abundance of mediocre coders that just happen to be good at writing e-mails, meetings, architecture (but not really), powerpoints, navigating customer requirements and product design. It’s in their interest to downplay coding skills.

While the former can certainly be challenging, it’s by far not rocket science. Any reasonably intelligent human can discuss requirements or design a product at a decent level.

Writing code at a decent level is beyond the average reasonably intelligent human. If your mind doesn’t tick a certain way, you will not be able to do it and it will be painfully obvious to anyone that can do it.

I always said programming is 80% thinking and only 20% coding.

nothing has changed since then.

Is it just me, or is this article arguing against a straw-man?

Isn't the real argument that "writing code is not the hard part"? As in, reading and understanding is the hard part. Figuring out what and how to change is the hard part.

Writing is the last 1% that happens after you have already finished the 99% of talking to people, figuring out what needs to be built, building up context about the codebase and surrounding infrastructure in your heard, planning the actual changes.

Depends on what you work, if you optimize algos and low level stuff I think it's an insult if you're like 95% that have fairly easy issues and just juggle data around it isn't and code has never been the problem. Even now the issue where I work is the actual solid requirements and technical plan before the implementation. I move higher up to something like architecture/rm since AI coding is pretty decent and does the job.

Insisting that code is the hard part is like insisting that spelling & grammar are the hard part of being a writer

Business has detested IT forever. It is basically considered blue collar work they felt held hostage to as it was 'brain' based instead of 'muscle' based, and it threathened to expose the grift of clueless "management" (not all is). They yried to placate with CTO, and l created tech diluted CIO and CISO titles for themselves, but the fear and loathing is as strong as ever.

    I have met many programmers throughout my career, and very few of them want to talk to stakeholders, much less customers (exceptions are freelancers and founders, especially of software development shops). And, “having clarity on the priorities” boils down to “just tell me what to do and don't switch it up every two days”.

I think the statement "code was never the hard part" is true but it's relative.

Programming is not easy and it takes years to master. Some people became really good at solving complex programming puzzles and 'Code Jams' and focused on it. Unfortunately, the same aspect which made this skill highly visible and highly praised, is what made it easiest to automate.

All those medals, trophies and certificates... not the mention advantages at big tech software job interviews... Came at a cost.

Meanwhile there is a whole group of people who have been honing their skills in software design, architecture, distributed systems, security and other less visible, less rewarded skills who have been ignored by the markets. These people still can't be automated.

It's a large problem space so after a decade or two, the coding aspect feels small relative to all the theory and experience surrounding it.

I met many senior people who didn't take programming seriously as a skill, long before LLMs.

One time, when I was at university, one of my math lecturers was boasting about the superiority of math as a discipline and said to the class "Software engineers... There are no software engineers; they're programmers."

That statement was never true but it's much more obvious now. The fact that a lot of people shared this belief highlights the fact that these other skills were invisible.

There is probably as much engineering (if not more engineering) involved in delivering a complex, reliable software project as there is delivering a complex skyscraper project in civil engineering... It's the same kind of activity; lots of interdependent parts, each with their own constraints and requiring many decisions to be made with lots of tradeoffs. At least with a skyscraper, the customer requirements are relatively very stable.

Code was never the hard part

I roll my eyes at this when thinking about the poor JavaScript developer that cannot write code without things like jquery or React.

If code were so easy there wouldn’t be so much bloat and slow garbage in the world.

long said that success is 1% idea, 9% implementation and 90% other stuff like marketing that I don't care about.

whenever someone says this I assume they mean a crud react app which is a small part of what 'coding' encompasses

> If coding is easy, why is software so damn buggy?

Debugging is hard.

It’s not that coding is easy. That misses the point. The point is, coding is recurrent. Automation follows recurrence, not ease.

> I don't mean to imply there are no developers that simultaneously care deeply about the craft of software development and really empathize with the customer. I do believe they might want to see a professional about a split personality disorder, tho.

This is a specific attitude I try to beat out of juniors. You will not be dismissive of the point of this exercise.

It seems to me like two things can be (and are) true: programming can be hard in absolute terms, and is also the easy part of the thing that we call “software engineering.”

This is the kind of thing where everyone just talks past each other because "coding" can refer to a ton of different things. I think we've all had the experience of having to write large mechanical boilerplate or refractors which was definitely highly automatable coding. I think we've also all has the experience of being utterly dismayed at how hard it is to write certain logic, especially with LLM "assistance". I've spent the last couple days marveling at how consistently fable introduces race conditions into a complex state machine I'm maintaining. Coding can be hard, or easy sometimes

Too many people on hacker news sound like blacksmiths at the beginning of the industrial revolution. Get with the times, artisanal handwritten code is worthless

Geez people.

Sometimes coding is hard. There are two types of hard things: algorithms and architecture. LLMs are good at algorithms, not good at architecture.

Most of the time coding is not very hard, it’s filling in the blanks, implementing the business logic, writing boilerplate code. LLMs are good at this too.

Saying AI can do all the code isn't even accurate either though that's what's weird about all these takes

As soon as the context builds up high it just starts doing things straight up wrong

I've been trying to network a simple tactics game with AI and it just is a hydra of sync issues despite clear explanations of what they are and bug reports and desired end-states.

As a coder/programmer/programmer analyst/senior technical staff/software developer for over 60 years, I approve this message.

Someone said this?

Microsoft did research on this and it was found that only 14% of time was writing code.*

That 14% might have been hard, but it is definitely still the smallest part of being an engineer.

* https://www.microsoft.com/en-us/research/wp-content/uploads/...

Tech is not the issue, people are

"If figuring out what to build is the hard part, why do so many product managers seem clueless" - because people

"LLMs may be good at coding" - they are not;

Code is the hard part if you are John Carmack or in a similar position where you have to squeeze every drop of performance from a hardware. That is the minority of programmers.

It's a strange choice of something to take personally. It doesn't mean code is supposed to be easy for everyone at all times, just that past a certain point of your own personal path towards mastery the utility of not having to write code diminishes and the complications of delegating rise in proportion to the shrinking gains.

Great article. Nice pragmatic and cool-head take on what is going on. Thank you for posting this.

Side note: I so forgot about the "Don't make me think" book! Thanks for reminding this exists. I submit this should be part of "Software Development 101", right there alongside SICP.