Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- All of our developers are now using agents. We're not hand-writing code at all anymore. And yet, some of our developers deliver stories in an hour, others deliver similar complexity stories in a week. Executives are surprised to discover they cannot simply turn over a product-authored jira story and have it yield a single agent-written PR. There is still significant work that happens between the point at which a story is written, and the point at which correct prompts are input that generate the code that fits the requirements. Very significant work. I think that when people say "code was never the hard part", they're only guilty of eliding the point that "code was never the only part" or "the hardest part", and that there's so much other stuff that programmers do at various levels of competency, and that... perhaps up to now it was easy for product folks and execs gloss over since they just put us all in one bucket of "people that write code".by tunesmith
- 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.
by gt0 - Yes. I've also heard it said "code was never the bottleneck"by __s
- 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.
- No, code was always difficult.
To be precise, it depends on the domain. The people who could actually write algorithms or core implementations were always a minority. Programmers like me mostly did copy-paste from Stack Overflow or assembled libraries.
It's not that code wasn't difficult—it really was.
In CRUD apps, about 70~80%of the work was building the same thing over and over, so once you got familiar with it, most of it was repetitive practice. But the number of people who could actually create something new was always small.
Most business programs had issues that arose in the application stage, the application layer. In this application layer, only a very small portion involved difficult logic. Most of it was just applied.
The problem is that people often romanticize the lower layers beyond their own, compilers and low level systems, calling that 'real programming,' and in doing so, they make programming seem harder than it is. In reality, the coding that most people make money from is mostly at the abstracted layers. The infrastructure beneath those layers is owned by giant corporations. If you work at one of those giants, that's fine. But beneath them are countless consumers paying those giants, and the coding that targets those consumers isn't that difficult.
In the end, whether coding was difficult or easy depends entirely on which layer you're working in.
What's certain is that coding was difficult, and it still is.
by jdw64 - If you’re struggling at formal thinking, coding will be hard for you. I’m not talking about designing software with higher concepts, like thread, network IPC, web application routing, gui,… but more simpler one like basic data structures (list, tree, maps, graphs,…), algorithms (search, sort, balancing trees,…), and paradigms (procedural, functional, oop, relational,…).
I’ve met a lot of programmers where those concepts where only words and not something they have understood. A snippet of code is either something they have to learn or copy, it’s not something they can fluently manipulate. It’s the difference between having to use a dictionary and sample phrases and speaking the language fluently. The former is a chore, while you don’t even notice the latter.
by skydhash - 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.
by neya - IMO it goes both ways. Each side can look into how they see the other side to understand the psychology of the other side.
Also I write good code and managers are thrash.
by ozgrakkurt - 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.
by mrkeen - > Encoding your ideas into a programming language is easy.
This is still difficult. Sometimes the programming language or the programming methods you want to use effect how you desing the system on an abstract level.
by ozgrakkurt - LLMs can write TLA+ models just fine. It can help even with small mobile apps. Surprisingly, simple TLA models were able to find design/workflow issues almost in every of a few vibe-coded apps I've tried on vacation.by d0mine
- Those computing ideas (like distributed systems, concurrency and task scheduling) can even be found in even a single program/system. They are often entangled with even broader concepts, like visual layouts, security (authentication, authorization), communication and encryption, control systems, signal processing,… And those are often accidental complexity.
The essential complexity can be easily resolved by talking to domain experts. You will get a nice requirements document afterwards. That’s when the engineering and management concerns appear.
by skydhash - Nope, coding was still the hard bit. Every failing programmer would jump into architects or prod management but not the opposite way.by varjag
- 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.
by nemothekid - One of the Stack Overflow founders wrote about all the programmers who see SO as a series of CREATE TABLE statements and miss the rest of the trees.by inigyou
- You are putting a lot of words and judgements into the authors mouth.
Why exactly is it acceptable to not just do your role and expect the underlying requirements to be correct and measurable, especially when there are separate roles whose sole purpose is to do exactly that?
by mawadev - 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.by bluejay2387
- This is all the stuff that the frontier labs are going to ship by default next year. Except for the architecture specifications, which agents can already do adequately for most system today.by a2ff6eeb0
- >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
Development is essentially becoming management.
by logicchains - Code is the written representation of your idea how to solve a problem.
Now you tell someone else your idea and have to hope they get it. Otherwise you have to argue, rephrase, start all over again.
We are back to the tree-swing project management, but we added another layer
by croes - No one seems to mind the quality drop though. The buyers of this stuff could never discern.by maxrev17
- 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.
by tikhonj - It is hardly any different from reviewing or debugging the code quality of most offshore deliveries.by pjmlp
- Those corporations that undertake the actually difficult bits of programming end up charging so much money, to the point that people go out of to not use them though. Splunk, Oracle Database, Spanner, Datadog, VMware. We don't live in an idealized world divorced from business and money, unfortunately, but worse, software developers are notoriously cheap and hard to sell to. If I did the hard work and made a compiler that generate code that runs 10% faster, I should have a solid business. Even Intel couldn't make a business out of icc though. So the code is the hard part but business is also the hard part and it's a miracle any of this stuff ever gets off the ground.by fragmede
- > 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.
Genuine question and not trying to be snarky here, I am actually curious: what fields or types of programming does this apply too? I think I've read anecdotes online about people in fields I previously (a few years ago lol) thought "oh yea an llm will never be able to help with that" and now see articles about how llm's are doing just that.
by ryan_n - It's not really telling on oneself. Like you said, the easy stuff (e.g. basic business process automation i.e. constructing simple database queries) happens to be economically high ROI right now. Something like 3d graphics or signal processing or whatever are comparatively niche and less likely to pay as well. Most jobs that people will actually pay for are actually pretty mindless. Even for the more "advanced" jobs, it's likely the domain knowledge and not the programming per se that's difficult.by ndriscoll
- 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.
by agentultra - 1000%. The expense of writing software was and still is high.
Whether it’s commercial software company or an internal team writing custom software, the return on that investment depends on many things outside of the code itself.
by jaynate - Getting everyone to understand the problems, working together, etc, etc are issues that are inherent to organisations.
They’re orthogonal to AI and to the actual hard technical skills needed to execute on a specific strategy. And if the technical skills are lacking, it doesn’t even matter how good an organisation is at collaboration, whereas hard skills plus organisational disfunction are a known successful pattern :)
Many people did look at this through an individual lens and claimed that design skills, domain knowledge are the truly important abilities. I remember reading on HN at least a couple of popular articles claiming that. Actually, they’re all important and having great design skills without matching coding skills is IMO not really possible. The code feeds into the design, the requirements, the architecture and shapes them.
by blub - Organization is too abstract here.
It also depends on how you model the problem. You can easily say the hardest part is hiring people if you are the boss. Since the people you hire can do everything else that needs to be done.
Managing and motivating people is the hardest part for the person who is doing it.
If you are hiring you might say it is harder to find good managers than programmers.
It is not measurable who did a good job at what as almost everything requires a group of people doing different things.
You can see how pointless this is becoming as we don’t have a measure for anything.
This kind of problem requires assumptions because it doesn’t hing on anything natural.
For example, if you start by believing salary indicates value then you can go from there.
In the end there are millions of managers, millions of programmers, millions of ux designers etc. It is kind of funny to suggest doing any of these is inherently harder than the other.
Just imagine you are judging a project. You have everything about it recorded. How hard do you think it would be to judge who had more part in the outcome in what way? If 10 people judged it separately, how many would have similar opinions etc.
It is impossible to judge even for a specific case, so it is a joke to consider to find the universal rule for it.
In the end it is ok to believe something but it is also important to not forget that it is a belief
by ozgrakkurt