Comment by agentultra
7 hours ago
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.
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.
Well, it's true. In a world where code is commoditized, a PM who knows exactly what the customers' needs are will be much more successful than an engineer who does not. Not sure what is controversial about that.
A test doesn’t prove much.
Highly experienced programmers seem to have a hard time understanding this.
Why do we have tens of thousands of test cases and we still find new errors constantly? Why is our software so bloated and slow? We do we still have security breaches?
LLMs can be useful tools when guided by experts. I don’t think a PM with a dream is going to cut it in the long run.
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?
Apparently it is. Modern companies seem to prefer dysfunction over anything else. I have been trying to understand why for my whole career.
Competing incentives and the natural result of dealing with lots of people mostly
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.
I don’t disagree. I’ve worked on teams that definitely valued the non-coding skills more and it showed in their inability to deliver on certain requirements… mainly performance and stability.
But these are skills that can be taught to individuals.
But teaching an organization that their real bottleneck isn’t how fast they’re writing code; it’s producing production-ready software that people understand and are willing to take responsibility for… that’s much harder.
Many businesses want to treat software development like an assembly line and revert back to Taylorism. It’s knowledge work and there’s no royal road. Good teams get fast when they have the right mix of skills and trust from the organization.
What we’ve been delving into for the last decade has been a decline in the value of labour and work.
“Code isn’t the hard part,” isn’t meant as an insult at individual programmers or to devalue their work. That’s being done by big tech and their AI hype machine.