4 ms·

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

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.

blub 2mo ago
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.
- agentultra 2mo ago
  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.
jaynate 2mo ago
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.
ip26 2mo ago
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?
- agentultra 2mo ago
  Apparently it is. Modern companies seem to prefer dysfunction over anything else. I have been trying to understand why for my whole career.
  - nunez 2mo ago
    Competing incentives and the natural result of dealing with lots of people mostly
  - stefan_iarca 2mo ago
    [flagged]
hannofcart 2mo ago
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.
- satvikpendem 2mo ago
  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.
  - pnt12 2mo ago
    Why not have the customer talk to an llm and iterate on the plan? Many customers will appreciate the 30m back and forth replacing the multiple hour meetings. People are subtracting a lot of hard parts from their thinking, and think it's simpler than it is. What happens when the test suite isn't testing the real thing? The ci/cd doesn't even start? There is a bug requiring a hot fix ASAP? The code is growing into a nasty meatball and spaghetti dish, and the llms just turn shift it around. What about when the agent starts thinking in circles and neefs guidance to start working? I'm not a ludite: I use llms every day, but I try not to be a meat proxy. Some one off scripts are vibe coded, but applications need real maintainable code. My prediction for winners and losers: some companies will lay off a ton of programmers and replace with AI, with short term success but long term big problems. Other companies will use llms to boost productivity, but keep their engineers responsible for the health of the products. Short term gains won't be as impressive, but productivity will be higher and the company will be competitive in the long term.
ozgrakkurt 2mo ago
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
nrlucas 1mo ago
Two things... Firstly, I agree with you on all those things. One aspect of the programmer you are missing is managing complexity in a system. This i find to always be the main goal of the programmer. As design changes, it's easy to code a solution, it's hard to anticipate the direction, build extensible systems, and not compromise other demands that happen now. Another is communication. Using code to express a solution concisely, in clear language, and with an abstraction that doesn't compromise that correspondence to reality.I often have to steer an AI model a bit to use the correct terms and I will often "rephrase" their code to match my view of the world.

blub 2mo ago

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.

agentultra 2mo ago
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.

jaynate 2mo ago

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.

ip26 2mo ago

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?

agentultra 2mo ago
Apparently it is. Modern companies seem to prefer dysfunction over anything else. I have been trying to understand why for my whole career.
- nunez 2mo ago
  Competing incentives and the natural result of dealing with lots of people mostly
- stefan_iarca 2mo ago
  [flagged]

hannofcart 2mo ago

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.

satvikpendem 2mo ago
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.
- pnt12 2mo ago
  Why not have the customer talk to an llm and iterate on the plan? Many customers will appreciate the 30m back and forth replacing the multiple hour meetings. People are subtracting a lot of hard parts from their thinking, and think it's simpler than it is. What happens when the test suite isn't testing the real thing? The ci/cd doesn't even start? There is a bug requiring a hot fix ASAP? The code is growing into a nasty meatball and spaghetti dish, and the llms just turn shift it around. What about when the agent starts thinking in circles and neefs guidance to start working? I'm not a ludite: I use llms every day, but I try not to be a meat proxy. Some one off scripts are vibe coded, but applications need real maintainable code. My prediction for winners and losers: some companies will lay off a ton of programmers and replace with AI, with short term success but long term big problems. Other companies will use llms to boost productivity, but keep their engineers responsible for the health of the products. Short term gains won't be as impressive, but productivity will be higher and the company will be competitive in the long term.

ozgrakkurt 2mo ago

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

nrlucas 1mo ago

Two things... Firstly, I agree with you on all those things. One aspect of the programmer you are missing is managing complexity in a system. This i find to always be the main goal of the programmer. As design changes, it's easy to code a solution, it's hard to anticipate the direction, build extensible systems, and not compromise other demands that happen now. Another is communication. Using code to express a solution concisely, in clear language, and with an abstraction that doesn't compromise that correspondence to reality.I often have to steer an AI model a bit to use the correct terms and I will often "rephrase" their code to match my view of the world.