alt Hacker News“Code was never the hard part” is an insult to all programmers
Comments
> If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?
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.
The author might be missing the intent of the observation. Maybe they’re misinterpreting it.
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.
Everybody saying "coding was never the hard part" is really telling on themselves. Coding was never "hard" because most organizations were absolutely unwilling to take on any technical work that was hard. That tells us about business strategy and culture rather than anything about the fundamentals of programming or technical work.
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.
This feels like post-LLM coding romanticization. Before LLMs, people would regularly say stuff like "I could build this in a weekend" under a "Show HN" post. How many times have people said "I could build Twitter in a weekend". I've even found in a post-LLM world, that kind of language has only increased.
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.
I agree, the whole 'developers don't code' AI defense was pretty ridiculous. I also concur that development is going to get a lot harder. Anyone that has successfully used AI coding tools knows that you can get massive productivity increases but now I have to figure out how to get a bunch of hyper active child like coding entities with memory deficiencies to build stuff without going off the rail and introducing massive security problems or building something completely mismatched to the requirements. If you can do it, yeah you can get 10x results. But now I am engineering harnesses, architecture specifications, agent structures, statistically sampling, and formal verification systems to guide the code instead of writing the code.
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.
The answer to all these "if coding is easy" questions is that coding isn't programming (to put it in Lamport's terms).
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.
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.
The "code was never the hard part" is a narrative pushed strongly by designers, MBA guys and product managers. Even before AI, they've always treated programmers like low-lives, someone beneath them and completely replaceable like commodity. Ironically, of this entire group, it isn't programmers that are being replaced left and right. Whole product teams, designers are being replaced. Good coders are still in demand - because, someone has to fix the vibe coded mess. In design, there is no reference for good and bad. You either like a design or not. In code, something either works or not. That's why it's always hard to replace a programmer as opposed to a designer.
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.
In my peak programming years in Germany, about 5-6 years ago, every company that ever tried to hire me, wanted to do some sort of CRM for xyz. It’s fun when you build it once, but then you change the domain, and realize you’re essentially building the same thing, but for different people. I’d gotten so bored of it all by 2020 that I’d approach them right away, asking “are you building yet another CRM for xyz?” They didn’t like it, because it would undermine their work. But it’s true - thousands of highly-educated, well-paid people in Munich at the time, were essentially paid to build and maintain glorified sheets software for managing people and resources.
You can guess which companies and people were hit the hardest, when it turned out that all that software could eventually be generated by a machine.
Coding while definitely not easy, it was never the hard part.
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.
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!
No, it means you’re more than just syntax.
And that if you make a bot that produces syntax you haven’t produced a programmer.
Some workers are more 1:1 with syntax, like a developer from a gig platform or overseas contractor, the deliverable being code files.
But the staff software engineer deliverable should be software, novel outputs, a face in meetings, someone to blame if it all goes wrong, a member to fill out the ranks, a person to get coffee with and talk about adjacent things that open new doors, in a sales capacity it might mean travel and interpersonal stuff like drinks and talks to convince people to integrate, it’s thoughtful often emotional back-and-forth from frustrated contributors on GitHub that lead to changes and innovations, and other things of value that language models can never do.
I would say further that even if you model emotional intelligence, or the whole world even, unless AI has a face I can punch if it crosses some line and it knows it has a face, what its own face is and why that matters to itself, it will always fall short in terms of empathy. Our sense of empathy and emotion originated in the wilds among fear and terror and the thrill of catching and eating food, discovering others, and understanding the consequences of everything before me in this moment.
>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 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.
I guess my impression using these tools daily is that it hasn't diminished the need for my own technical expertise. The conversations I have with it are highly highly technical, and to me the insights come from both sides, I see things the LLM doesn't, and the LLM sees things I don't. It writes a lot of bugs that I have to spot, and writes designs that aren't correct. (This isn't a criticism, I do the same). I think the ideal world version of this stuff is complementary, but the current insane bubble economics mixed with the insane religious fervor make that unpalatable to the leading AI companies. (Like, I think Sam Altman said that anything below a trillion dollar IPO valuation is a "non-starter".) So, "nice coding tool", even if that's the BEST and most realistic outcome, is just not going to do it for them.
For me the hard part is remembering the "long tail" of the stuff I don't use long enough for my brain to consider it worth putting in the permastore. So I just spend a lot of time googling stuff I already "know" how to do, because the frequency is too low.
It's not hard, it's just bloody annoying. And that's my favorite use of AI so far. Telling it what the code should do, and it translates that into language X's stdlib incantations.
I also find this to be the optimal level of AI usage. If I let the AI run around the codebase doing other stuff, then I need to spend more time and energy later catching up. Whereas, if I stay "in the driver's seat", ask for tiny changes, and approve them manually, the mental model doesn't never gets desynced.
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.
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.
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.
This is a bit of a false dichotomy. The thing that isn't code (at least in some people's minds) isn't "requirements analysis". It's architecture, data modeling, deployment, inter/intra-team communication, triaging, prioritising, code reviewing, testing. It's all of software development, and not simply writing lines of code (which in itself can be hard of course.)
Coding is easy if you enjoy doing it, met plenty of professional programmers that hated it and never felt the desire to improve. To them it was a way to get a paycheck that paid reasonably well.
The truth of that statement depends on what you consider as "coding".
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.
One of the strongest teams I worked with, working on an extremely large and ambitious project used to answer a lot of product/executive type questions regarding missing areas that we knew how to author and could safely assume general design consensus “it’s just typing”.
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.
Nope, only those without a degree that cannot do anything else, e.g. the bricklayers on a building.
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.
I don't think I've heard a lot of people say "code was never the hard part". I have heard "Code was never the bottleneck", which is a different thing altogether and is objectively true at my company. The bottlenecks were and still are integrations, QA, requirements refinement, coordination, etc.
> If deciding what to build is the hard part, why do so many product managers seem clueless?
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.
In my experience the complexity of the coding challenges tackled correlates well with the talent of the engineers.
It is uncommon to find engineers doing work they find trivial outside of some consulting niches.
ya, it wasn't hard and that's why one of the highest paid jobs for decades
LLMs are the invention of the loom. Code is being industrialized.
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.
what is -coding-? only typing down some code? the hard part is always the design part, reading doc, reading other code, understanding the sum of the parts, making choices, until the code to write is (quite) -obvious-.
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.
> If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?
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.
Unpopular opinion: I fully believe that anyone who says "code was never the hard part" was an irresponsible coder who perhaps never had to work for themselves.
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.
I like heuristics, but find broad statements are usually a bad idea in IT/Software. Developers in particular are very quick to find holes in logic.
When I think of code, I like to compare it to old complex physical machines. Think automaton. If you zoom in enough, what you see is indeed somewhat simple. But zoom out and the answer changes.
Then there is maintenance, manufacturing, tooling, etc.
I suspect that as humans living in a physical world, we understand intuitively the vast knowledge and skills required to design and build different kinds of machines. Software tends to hide inside boxes that look similar, but are infinitely variable.
I think there is a de-facto distinction between different kind of programmers, we just need a clear names for them. Like, "builders" for folks who ship products and see code as an annoying intermediate step and "engineers" for people who build technically sound software.
I agree with the author that coding is objectively "difficult" but this is something I am good at, while dealing with people, changing requirements, bureaucracy, and maintaining work relationships I find challenging. I always say coding is the easy part of the job (for me).
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.
> 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.
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.
"If coding is easy, how come programmers were in high demand, and have demanded large salaries for years"
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 ...
"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.)The 8 hour work day was quite a victory but since it happened long ago i would really like to see how health and productivity in each occupation declines over time and by task. I expect not just the obvious jobs to have quite absurd numbers and vary a lot from person to person. One might imagine a gradually increasing hourly rate, a decreasing one or a combination of the two. Writing code i could probably do 2x an hour per day. Much respect for those who can do full days. If we imagine there to be roughly 500 defined occupations it seems quite doable to measure how "easy" coding really is.
> 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?
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...
There’s too many dimensions to make broad claims like this and it always makes me wince a little.
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.
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.
Ive been doing this for enough time. Code is rarely the hard part. Code rarely matters at all in my career experience.
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.
There is a half truth to code being the easier 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.
Coding something for the second time is much easier. Therefore, coding is easier than some other tasks in software engineering. Getting the spec is usually the harder part, except if following the spec is for really complicated products, like "one does not simply rewrite VIM" shows.
To be fair, the use of absolutes like "never" is a red flag. If the statement were "code is often not the hardest part", that's certainly plausible and debatable depending on context. The implication that coding is easy is what's offensive.
I believe there are some programming jobs in which the code is absolutely the easier part. Not all of us work in signal processing, integrated systems or have to push upstream to Linux kernel because the company we work for really needs a memory allocation optimization for its data centers.
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.