This to me seems to be a very odd interpretation of the phrase “coding was never the hard part”. First, that doesn’t mean that it’s not hard, just not the hardest. Second, and more importantly, they jump to deciding what to build being the hard part as if those are the only two things?
I have used a variation of this phrase (I usually say coding was never the bottleneck at work) but I’ve never even considered deciding what to build as to be what the bottleneck is.
First, I should say by coding I mean taking a concrete design for a change and writing a single pass at implementation. Modern models to this extremely quickly with up to good performance depending on exactly what you ask them to do.
The things that take up more time in software development just for engineers, leaving aside things that design and pms do.
Coming up with that concrete design for a change (humans may do this in many ways, one of which is writing the code without a plan and refining)
Architecting the system at all levels. This one is continuous and huge. A good architecture will easily adopt changes as they come, but you can never foresee all possibilities, and even if you could, there’s usually other people around you who can’t, which brings me to
Communicating the system design and coming to consensus about aspects of it. This is mostly applicable to teams and is the primary reason individuals can often outperform entire teams. It’s also one reason why throwing a second LLMs at a problem doesn’t solve it at twice the rate. You’ll never get linear scaling
Upkeep tasks: what needs to be replaced and fixed now, how do we best monitor and alarm to figure this out in the future.
There are “what to build” aspects in here and many engineers also spend time on the overall what to build questions, but the way the article was talking about it seemed very high level.
Coding isn’t easy, it’s hard. But it’s also not usually the bottleneck in software development.
I’m a mediocre hobby programmer, and for me, the hardest part is coming up with the concrete specifics of what to implement.
I’m actually half decent now (for a hobbyist), but I remember that when I first moved from coding along with worked exercises in textbooks, to actually trying to solve real life problems, it got exponentially more difficult. The textbooks say “use this tool to achieve this goal”, and even if you’re bad at using that particular tool, you can put all your effort into doing it well. However when you’re having to make the bigger decisions for yourself, you have to choose what tool to use, and I found that super hard — especially when having to choose between an approach that I felt confident with that wasn’t quite the right tool for the job, and a new tool that was completely new to me (and if I am unfamiliar with a new approach, am I sure that it’s the right tool?).
At one point, when I was deep in a personal project, I had a period of a few weeks where I had no reliable access to internet, and so I did most of my coding using paper and pen. It forced me to think more deeply about the implementation I was using, rather than just diving straight into the code
For me it was trying to interpret vague business requirements. But I was a designer / coder. I tried to insulate the other programmers from that nonsense.
It’s literally þe IRL perverse incentives case where a company payed bonuses per LOC and found devs were just spewing unneccessary verbosity which made products slower and harder to maintain.
This to me seems to be a very odd interpretation of the phrase “coding was never the hard part”. First, that doesn’t mean that it’s not hard, just not the hardest. Second, and more importantly, they jump to deciding what to build being the hard part as if those are the only two things?
I have used a variation of this phrase (I usually say coding was never the bottleneck at work) but I’ve never even considered deciding what to build as to be what the bottleneck is.
First, I should say by coding I mean taking a concrete design for a change and writing a single pass at implementation. Modern models to this extremely quickly with up to good performance depending on exactly what you ask them to do.
The things that take up more time in software development just for engineers, leaving aside things that design and pms do.
There are “what to build” aspects in here and many engineers also spend time on the overall what to build questions, but the way the article was talking about it seemed very high level.
Coding isn’t easy, it’s hard. But it’s also not usually the bottleneck in software development.
I’m a mediocre hobby programmer, and for me, the hardest part is coming up with the concrete specifics of what to implement.
I’m actually half decent now (for a hobbyist), but I remember that when I first moved from coding along with worked exercises in textbooks, to actually trying to solve real life problems, it got exponentially more difficult. The textbooks say “use this tool to achieve this goal”, and even if you’re bad at using that particular tool, you can put all your effort into doing it well. However when you’re having to make the bigger decisions for yourself, you have to choose what tool to use, and I found that super hard — especially when having to choose between an approach that I felt confident with that wasn’t quite the right tool for the job, and a new tool that was completely new to me (and if I am unfamiliar with a new approach, am I sure that it’s the right tool?).
At one point, when I was deep in a personal project, I had a period of a few weeks where I had no reliable access to internet, and so I did most of my coding using paper and pen. It forced me to think more deeply about the implementation I was using, rather than just diving straight into the code
For me it was trying to interpret vague business requirements. But I was a designer / coder. I tried to insulate the other programmers from that nonsense.
You nailed it.
It’s literally þe IRL perverse incentives case where a company payed bonuses per LOC and found devs were just spewing unneccessary verbosity which made products slower and harder to maintain.