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

In which world are you living? For most programming jobs, the code is absolutely the easiest part of the whole thing, which is just gatekept into absurd bureaucracy and ceremony. Even if coding became 100x faster with 0 errors tomorrow, the software in most companies would still move at a snail's pace.

Exactly! Try reading a large C code base.

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.

Someone said this?

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

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.

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.

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

    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.

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.

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

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;

Insult it one thing, it’s also not true in the slightest which is the bigger issue.

> If coding is easy, why doesn't everyone just build ten variations of a thing and see which pans out?

Because it is hard. :). Writing good code - takes years of practice.

Good article if you read it all.

> Those decades spent fighting memory bugs in C or C++, with the scars to prove it, are worthless in the age of Rust, Go, Python and JavaScript.

For most people sure. I’ve had GC kill a service in production, or even just tank p99. And I think a decade of C gives you a massive head start with rust. Less screaming “WTF WHY?” at the compiler anyway.

> Code was never the hard part

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

Since not everyone seems to be familiar with human communication:

The phrase "X is the hard part" means that X is the hardest part, not that all the other parts are easy.

Maybe the author has a skill issue, as they conflated "software engineering" with "coding".

It is all the parts of maintaining the software with time and engineering with all the moving parts (not the coding) is the point of why software engineering exists.

>If coding is easy, was Carmack just at the right place at the right time?

Yes, it's fairly axiomic that he was "just at the right place at the right time" because there are dozens of modern "boomer shooters" on steam that are not nearly as successful as DOOM or Quake. You might counterargue that its always harder to do something thats never been done before but that would only be a tacit admission that coding actually was the easy part in that case.

It's more accurate to say "code was only the worst bottleneck in a multi-bottleneck system". The second-worst bottleneck has been promoted to first. And it might be only marginally better.

> talking to users ... good code ... we should aim for both

tl;dr nothing has changed.

Code generation was never the hard part. Knowing wtf you’re supposed to actually write was always much harder and this hasn’t changed. It’s not hard to write a loop or an if-statement. It’s hard to actually solve a problem with them at production scale. Carmack’s Fast Inverse Squareroot is not hard to write - it’s hard to figure out how to even do one in the first place. Writing it out is the easy part.

Claude writes 90% of my code but the bottlenecks always were and still are:

* getting clear requirements from product

* getting the damn code reviewed so I can merge it

Neither of these are fixed. Frankly, overuse of AI has made both of these worse. Claude brained product owners going hog wild with Claude Design are a nightmare to deal with, and the volume of absolute trash quality code being submitted for review is soul crushing.

No, using AI to automate code reviews is not acceptable. Code Review isn’t about a systematic checklist (though they can help) it’s about making sure people understand the actual changes being made to the system because it’s people who are accountable for what happens in production. LLMs can be part of the process of reviewing code but they suffer from the same issues as any other chatbot based tools (hallucinations, context confusion or not enough context, getting bogged down in impossible code paths or other minutia, etc…) so you have to review that review carefully too. Human judgment is still king.

These days my job is primarily reviewing offshore slop and making sure it’s in a good enough state to merge. I’m doing merge and release management way more than actually coding (and it sucks btw because I actually enjoy coding with or without agents). If the quality of the code turned in for me to review and merge is any indication, engineers/system architects are going to have their hands full.

Then let the code monkeys be insulted then.

Good riddance to the overpaid coders.

And hello cheap replacements!

The bottom line has improved. And that's good for business. Which was the only thing that mattered. Regardless of any reactionary sentimentalism.

The author's primary misunderstanding in my opinion is that time consuming is being conflated with hard.

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

There is more to those roles than just coding. In fact the more expensive "programmers" often do not code themselves.

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

Something being time consuming is different from something being hard. There are simple factory jobs that also demand overworking.

>Why did companies seek 10x ninja rockstar coders and subject them to leetcode interviews—surely, a junior fresh out of college could churn out something if it's so easy?

Building software takes time and since velocity is important companies wanted people who could increase velocity.

>If coding is easy, why do we have doorstoppers like Clean Code and The Pragmatic Programmer? Is The Art of Computer Programming a light summer read? Is SICP a coffee-table book? Why do we have bootcamps or even whole college degrees dedicated to it?

So authors can make money? Programming is learned by a ton of kids on their own there is no need for boot camps or college degrees just for the benefit of being able to program.

If coding is easy, was Carmack just at the right place at the right time? Why do we consider Fabrice Bellard a genius?

The earlier you are to a field the easier it is to have your impact recorded. In markets with first movie advantage being earlier also helps a lot. A lot of people were able to program so what made them earlier than others was not just being able to program.

>If coding is easy, why are people angry at AI (or anyone else) copying their code? Why do they act like they've poured their sweat, soul, and copious amounts of time into something so trivial?

Again something being time consuming doesn't mean it was hard.

>If coding is easy, why do many now feel like their identity and professional purpose are being stripped away from them?

When you spend a big percentage of your life doing something it becomes part of your identity regardless of difficulty.

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

Because making bug free software takes a lot of time and resources. Those resources have a higher return on investment elsewhere.

>If deciding what to build is the hard part, why do so many product managers seem clueless? Why aren't there rigorous 10-step interviews for them? Why aren't they getting paid more than the developers?

People are clueless because it is hard. Pay is not based off of difficulty.

>If deciding what to build is the hard part, why aren't market researchers, usability experts and—hell, customer success—considered rockstars in a software company? If “understanding the customer” is harder, why are business analysts looked down on as pencil pushers?

Because the company finds it cheaper to outsource? A ton of companies have their employees setting up and using telemetry to understand their customers so it's not a one dimensional thing.

>If implementation is easy and finding demand is harder, why are programmers upset when the salespeople promise a new feature to a customer to close the sale? They've found a genuine demand, something people will pay for!

Programming takes time and resources. These may have a higher return on investment elsewhere than this niche feature. It may make maintaining the entire product take more resources to support a niche feature.

>If coding is easy, why doesn't everyone just build ten variations of a thing and see which pans out?

Again building entire products takes a lot of resources. And 10x the cost of building every product is not going to be competitive in the market.

> If deciding what to build is the hard part, why do so many product managers seem clueless?

The divide between product managers and developers mimics the artificial divide between humanities and STEM.

You divide workers into competing groups, then make they outperform each other.

In reality, practically all humans can both become excellent coders and acquire deep product skills as well. We can also learn a wide variety of other skills in a single lifetime. The only blockers on that are social and psychological, you're meant to not believe that is possible.

All this talk about code in this adversarial role with product comes from that, and all of it dissolves under almost any valid critical angle. The engagement with this kind of discussion takes place exclusively in that aforementioned social layer.

TL;DR weak bait

Code really is the easiest part. That doesn't mean code is easy. It means everything is hard, and code is just the least hard part. The best programmer in the world will still create bugs. Therefore you need something else to account for and deal with the eventual bugs.

In the rest of the engineering world, the way you do that is by standards bodies developing reliable, tested, certified methods to build things that avoid common problems. Pipes that are certified to a certain PSI or UV exposure. Wires certified to a certain amount of amperage, wetness, heat. Nails certified with a certain metal grade, tolerances.

Those standard parts are then used in a certified building method for a specific application at specific usage criteria. 3x 12d nails in one kind of wood joint. Beams spaced 24" apart, with 3/4" CDX plywood spread load. You don't guess or follow trends. You don't do what you think is "clean" or "beautiful". You solely follow the engineering standards and code. Now you don't have to think much, and your results are highly reliable. The job becomes easy.

Software doesn't have professional engineering and building standards like that. So humans literally just make this shit up as they go, making software however the zeitgeist of HN says "feels good". This results in unpredictable, unreliable software products that are hard to build because nobody agrees on the "right way".

Somebody read a blog post, or a slogan or quip on a Wikipedia page, and decided on their own interpretation of how that generic advice would drive their work. Software engineers only talk to other software engineers, so they don't realize how incredibly unscientific, inefficient, unreliable, and difficult their work is. Trying to make something predictable and reliable is therefore very hard. Not because writing the code is hard, but because the entire software product lifecycle is basically vibes. The uncertainty, variability, and lack of reproducible standard parts makes figuring out how to build something become way more complicated than it should be.

The actual lines of code are easy to read and write. But without the standards common to every other engineering discipline, the rest of the job is a slog.

The software development profession is in the midst of upheaval. Nobody knows how the AI revolution will play out in the end, but it is clear many aspects of work and life will be transformed—including programming.

I'm still not seeing it.

I'm seeing a lot of loud people, a lot of LOC produced, and a lot of people angrily pointing to their sideprojects... but no massive impact outside our bubble. Remember it's 2026, we are 5 years into this hype, the models are better than ever, and all the software we used around us is basically in the state it would have been in had we projected 2021 tech 5 years into the future ("in 2026, there will be... another backend JS runtime!")

I'm afraid all the personal anecdotes of technologists have not translated to real world results... other than negative ones like GitHub now having 0 9s of reliability.

Of course I suppose I'm "coping", as if I wouldn't be over the moon if AI had made me 10x productive... but maybe, just maybe, a lot of people really like talking to chatbots?

Don't get your panties in a twist over marketing slop selling AI to companies

[dead]

[dead]

[flagged]

A pretty weak essay.

The arguments are couched in questions… which all either have ready answers or imply strawman arguments that few are making.

I suspect it’s emotional and indirect because the author understands how poor its arguments are. That leaves open the question of why do the blog post at all, but I guess bloggers have to blog, whether or not they’ve got anything to say. An angry, emotional, vague post probably gets a nice amount of views.

Making software is no longer very hard. It's becoming a few steps up from burger flipping. Maybe somewhere around line chef.

There's still some skill involved, but the skill is mostly in manual testing, and accurately phrasing what went wrong. The AI is better at debugging than people are, and the code isn't great, but perfectly adequate for pretty much everything. And it's even fine at system design these days.

It's interesting realizing how mind numbingly thoughtless my job has become.

Don't get me wrong, I wouldn't mind it if this was skilled work, but it just isn't.