Navigating customer requirements and building something that satisfies both market's needs and company strategy can be an incredibly difficult and frustrating problem to solve. Especially if you need to also oversee the execution of the strategy. So not only you have to predict what they want or know the domain deeply enough to understand what they say they want is not what they really want, you also have to come up with a plan for executing your solution in a corporate environment.

There is a reason that books like "the staff engineer's path" cover topics such as local maximums, communication, establishing support for executing a plan or creating alignment on big efforts. In large corporate environments with multiple international customers, code is most of the time not the hardest problem.

Because programmers have generally been forced to wear additional, invisible hats that are essential to making the code happen in the first place.

Writing code is not hard. Writing correct code is. Knowing what is correct in a setting with paying customers generally involves interacting with those customers. Either directly or worse. The gigantic salaries paid to the most prolific employees is not due to their ability to write code. It is due to their ability to interrogate the shit out of the customer until they finally reveal the true requirements.

What I, and many people who’ve said, “code was never the hard part,” aren’t referring to the skill of an individual. It’s not the hard part of the engineering process of developing software. Programming languages have manuals. Many data structures are well documented. There are frameworks for damn near everything. While the difficulty of producing code varies by the skill of the programmer and the complexity of the problem domain; writing and understanding the code is a tractable and straight-forward problem. I can and have taught many people. People can learn.

What most people are referring to is that the hardest parts of producing software are all the things an organization has to do in the production of it. It’s not writing the code that is the hardest part for an organization. It’s getting everyone to understand the problems, working together, gathering requirements, developing specifications, validating releases, testing, etc. It can often look like herding cats and is probably harder.

The real conclusion is that programming is such a high-leverage activity that even technically trivial, low-quality programming is immensely valuable economically. That's not going anywhere, but maybe LLMs are going to make it all that much cheaper. (Which is mostly great! But I really don't look forward to the painful debugging and maintenance that reams of shit code will push down on programmers.)

But also, there still is a ton of programming that is fundamentally difficult. That's not going anywhere either. And LLMs are useful there too, but they're currently nowhere near replacing the expertise needed to do novel and non-trivial technical work.

In an ideal world, making mediocre code cheaper should leave more room for taking on harder technical challenges. In reality, this has always been dictated far more by non-technical factors—culture, leadership, trust, risk tolerance...—than by anything intrinsic to programming. But, at least for now, we can use the LLM hype to motivate the kind of deeper technical work that always made sense but was too uncertain or too open-ended or too long-term for non-technical leadership.

And we should also drop the bullshit "code was never the hard part" framing.

When you are looking at something that already exists, where all the requirements are defined, when all the edge cases have been decided, then coding was the easy part. People didn't "burn out" because it was difficult to figure out how to write SQL. People "burned out" because the requirements constantly changed, demand was ever increasing, and edge cases were constantly being triggered.

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

Classic engineer type opinion where every else is dumb, except for him. So many people have come to see leetcoding as an intellectual badge of honor, when most of us know its cultural rigamarole and the code written on the job will rarely reflect the type of work that will done.

I'm not saying coding is easy, plenty of people struggle with it. But as far as the job goes, unless you are a junior just grinding through JIRA tickets, coding was the easiest (and arguably the most rewarding) part of the job.

Encoding your ideas into a programming language is easy. Understanding that your ideas are bad is hard.

You have clients with multiple devices connecting to your backend simultaneously, while you mediate their interactions with your partner systems. Their versions might not be up to date. It's a distributed system. When was the last time you cracked open a distributed systems textbook?

When was the last time you built a system and stared reality right in face, that is: - can't trust your clocks - pick 2/3 of CAP - exactly-once delivery impossible - the code will need to be altered and released without downtime - hackers will try to exploit you for fun and profit - your manager doesn't want you wasting time getting the above right

Coding is the easy bit.

Has Claude code et al replaced programmers? Not really. And it will be a long time before it can - because someone needs to still instruct the direction of the code, the base architecture to build upon and that comes with real human experience.

The hard part has always been how to solve x problem. Coding is the last piece of that part, which while not easy is not the hardest.

The art of computer programming books are not about coding they are about computer science, i.e. figuring out how to compute solutions to problems.

Figuring out what to build is definitely not the hard part though.

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.

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.

Because they're not the ones deciding it, they just provide input for the Heads/VPs/managers who make the strategic decisions. And they are paid pretty well for this.

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.

Of course he is an AI consultant among other things.

The way I would define it, coding is to software development as cutting is to open heart surgery. It is the final part of the process after 99% of the decision making and application of experience has already been done. There is still some craft or "surgical technique" to it, but the hard part was surely everything that came before (requirements, architecture, design, etc, etc) that got you to the point where all you had left was a bunch of classes and fully specced out modules (and implied test cases) to code up.

I feel that some people, maybe including a lot of the people working at the AI companies, think that the software development job mostly consists of "coding", and perhaps in machine learning (not much code in an LLM!) it mostly does, but if you are a developer and define coding as the final "sit down and implement it" phase, then surely that is the easy part.

It was a very useful contraction in the right senior circles where there was a pretty good understanding of the meaning and decently reliable assumed consensus.

I eventually stoped using the phrase because it had started leaking deeper into the team and the impact on earlier career or less confident programmers was often no longer positive, it could be misinterpreted in lots of different ways but the most harmful was when it would further decimate confidence and discourage requests for help when something wasn’t obvious to the ultimate author.

As with almost every attempt to generalize in software engineering the repetition or extrapolation beyond the context in which it was intended can have negative side effects, it doesn’t matter if it’s a simple notion like “dry”, or a comment like “code was never the hard part”. None of these phrases survive context loss and still retain efficacy at general receivers.

Real engineering has always been about talking with the multiple parties, organising architecture meetings, taking down requirements, if no infra team available setup the whole CI/CD pipeline, and so on.

Programming could be done in whatever language, or low code/no code tool, solved the business problem.

Now what will remain to humans is a big question.

It isn't insulting. It's just a different use of the word "code" that doesn't cover all work that a programmer does.

Why exactly should a "programmer" who does not talk to the customer directly, be involved with this? How much more do we have to do on top?

I feel like this very often. I'm supposed to get a carefully written task with specific measurable outcomes and then I do so.

Besides that, have you ever tried to teach someone what a Rest API is who has 0 interest in it?

Regular CRUD code may not be the hard part, but just thinking systematically AND knowing the technology is a different level. None of the people who say that ever touched pointers or know the concept of heap and stack. Just talk to them, its crazy.

I watched a guy vibe code something and he couldnt explain to me where the "runner" pulls the data from. It said database but it actually went onto an FTP and hallucinated data out of a log it found.

I think we are getting to a point where people overestimate their abilities hard.

I'm not sure I follow the logic here. Wouldn't this mean that product design is hard?

That said, yeah, coding is hard. I suspect that those who claim that coding is not hard are high-level ICs. For better or for worse, as the size of a company grows and as one's career progresses, engineers will often tranform to professional box drawers, expert meeting goers, seasoned report writers, fierce gatekeepers...Anything but deep coders. Over time, they lose touch of the actual building and think that any code can be handled by people under them.

People like Jeff Dean, who still codes and optimizes things like TPU kernel code, is very rare.

Yes, there always will be artisanal weavers and a smaller number of them get paid a lot more money to do this by people who can afford it. Everyone else either started operating a loom or did something else.

Automated looms are now making mass amounts of textiles but the artisans are no longer doing the physical act of weaving. The artisans come up with cool designs, get feedback from customers, solve people's problems and outsource the rest (physical labor).

We are in the loom moment. Are you designing things people want? Are you doing the weaving? These two paths can coexist but they are diverging disciplines with diverging difficulties and diverging value.

Typing code into a computer is rapidly becoming physical labor now. The layer of creativity and problem solving is quickly rising to a level above the code since the code is a fluid now that comes and goes easily.

Probably is a question of terms: there is two things: -design- and -coding- (but could be anything as: building, drilling, turning, traveling..) so to make things without a good design is the regal way to problems, many times is a problem left by others, and in a world more and more complex and fast-changing can only be more and more worst. Hard to say what part is really the hardest, but starting with a bad design is no good.

And now probably LLM will solve some problems, but for sure these tech will create more and more new ones.

https://people.inf.ethz.ch/wirth/Articles/LeanSoftware.pdf

My take on that question is that programmers were in high demand because, for the last 60 or so years, it has been cheaper to write software for general purpose computers to automate things that were done by people and more rudimentary machines, e.g. accounting, manufacturing, music production, etc than it was to pay the people to continue doing those jobs. So, it continues a trend for programmers to be replaced by software, at least until something in the process breaks.

At its core, there is something difficult about programming. Fred Brooks talked about the need for perfection, Don Knuth about there being about 1 in 50 persons who had the mindset for computer science. But we haven't really been paid because it's difficult, we've been paid because we're cheaper than the alternative.

No matter how long you spend on architecture, no matter how carefully you plan your features, if you are an actually good developer there are choices that emerge only from the first draft of the code — things that you could do better, broader ideas that suddenly emerge and change your view of your own work, abstractions that become possible once you internalise the project through writing it, realisations that a requirement is unscalable, unworkable or unsafe, etc.

Nobody ever finds all those things only in the planning stage in any piece of code of consequential size or functionality: if it was easy, we'd all be doing waterfall development like 1970s consultants or using StP like 90s consultants, and none of those other ideas about coding would ever have emerged.

LLMs will just write the code. They will never have the rest of that experience. And I think any coder who doesn't have a visceral feel for what I said above is just bad at it.

"The code was never the hard part" is just edgelord AI evangelists masking denial with a pithy mantra. The code, its capabilities, the tooling choices, it's all indivisible from all the other hard parts.

But then these are often also the people who think they can use AI song or image generators to do the bulk of the work and "add the finishing touches". They also think "taste is all that is left" when the thing that gets us paid is not just our taste, it's our responsibility for and to our work.

The author's main thesis, that coding is hard, conflates what an individual finds easy or hard, with what is easy or hard for an average person.

Well, this is also an insult.

Cleanest way I read this is seeing how basically none of it makes any sense for someone coding as a hobby, or in any non-business context.

This is not an article about coding, it’s a promotional piece for business stakeholders.

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.

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

It's like saying 'Lawyers write documents!' for their job ... no, that's just an artifact.

Architecture, Systems, State, Integration, Algorithms, Pipelines, Platforms, Ops, Design, Communicating with other Eng, Working on a Team, Understanding Product/Product Marketing Requirements ... and of which the 'code' is just a small bit of the written part.

Honestly ...

Because companies resent that they have to take on risk and pay people to extract value from the market.

Ugh, why do we have to pay people to code, maintenance, etc. Lets pay people to extract more value for our bonuses and shareholders. Lets try to only hire heavyweights so that we don't get hung up on that difficult-to-measure coding process, knowledge transfer, messy human-ness. Oooh how nice, we can hire a fewer employees that know how to leverage code agents that free them up to think about that what REALLY matters...

In my career code was the hard part for the first few years. Then I got over the hump and everything else about my job was harder. Today code is the easiest and least interesting part. But I’ve also experienced in 13 years maybe… I’m going to say 2% of the world of professional coding. I bet if tomorrow I was asked to do some kernel optimization or make Postgres better or reverse engineer an emulator for some PLC something something, I would be deep into a land where code is the hard part.

In order to reduce the complexity of eventually coding something, you use modeling and code probes to validate the business model and then write the code.

This has been around since the days of batch programming and evolved through domain driven design principles.

The reality is the business can’t see that so they don’t invest in it and have no patience for it.

Agile wasn’t embraced because it was better. It was embraced because it was cheaper and faster.

Planning and modeling are the levers of complexity.

Shipping a working service or product matters and theres a lot of ways you can get there. The upside of good code is usually in maintenance and extensibility but theres a limit to how much those matter in the grand scheme.

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

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.

Coding is easy just like writing is easy. What makes the difference is what you write.

That doesn't make it inherently easy, but it is the easiest part to automate.

A modern LLM is perfectly capable of maintaining decent code quality and architecture (provided you ask for it) up to a few thousand lines of code, but after that it very quickly loses the plot if you're not designing your documentation right and keeping a hand on the architectural tiller.

Architecture is about staving off chaos for as long as possible given the maximum functionality you expect it to achieve. That's hard enough for a human, with a deep understanding of your business, to do. Architectures that endure is a hard problem, dwarfing the difficulty of writing the actual code. Choosing what product to build is also a hard problem if you expect to meet any success. What it does, what it specifically doesn't do. Sounds easy on paper, and if all you're doing is Sunday prototypes it feels almost trivial. But once you're doing a real product with real consumers, it's a very different thing.

LLMs don't fix that though. I see some truly awful code come out of them. And no, it's not just better context or use more skillz.md.

these two groups are telling me my time is numbered because of llm and ai when in-fact im struggling to see how ai doesnt replace them both

really good software engineers are expected to be experts in their job and that of the rest of the project team, these individuals are primed to be empowered by ai in a really disruptive way.

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

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

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.

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.

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.

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.

Typing is easy. Coding is hard. LLMs eliminate the typing and aid with all the other parts of writing code (where is the system that I want to mutate, how does it work today, debate the tradeoffs inherent in the potential plans of action).

What remains after factoring out the typing and the time spent assembling an understanding of code is opportunity cost. That's not an insult any more than memory managers are an insult to languages like C.

"Code was never the hardest part."

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

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

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.

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.

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.

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.

nothing has changed since then.

Debugging is hard.

2026 - "Coding was always hard, please don't lay me off."

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

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.

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.

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

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

There is probably as much 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.

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.

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.

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

"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;

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

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

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

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.

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.

tl;dr nothing has changed.

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.

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.

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

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

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.

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?

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.

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.