alt Hacker NewsThe 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.
Replies
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
It’s getting everyone to understand the problems, working together (etc)…
There are manuals for this too, and interestingly enough this has been studied since the Romans at least! Is it then really the hard part?
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.
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.
If what you're saying is true we are moving into an era where rockstar product managers are going to be more in demand than programmers since they can do all of what you mentioned above.
And typically (though not always) product managers have better people skills than programmers and consequently they might be more effective at the "gathering requirements" and "working together" bits you mentioned above.
Even much of the "validating releases" and "testing" parts should also be things that a decent PM should be able to wrangle now by themselves with some LLM agents to assist them. Afterall, why bother about code quality of a testing harness. So long as the PM can keep a coherent test case list and have end to end tests that cover them, programmers can leave that to them as well.