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.

Remember that story about the chalk mark engineer with Ford? Chalk mark 1$, knowing where to mark 1000$ ? Same with code. “Code” is easy. Knowing what to write, why and where, that’s the hard part. LLMs have somehow managed to automate the code part, without the abstraction, at least in an error proof way. I don’t think “coding isn’t that hard” is insulting, and I don’t use C++ because I think it’s hard. But it’s not because writing something is hard, it’s because writing precisely what is needed is hard.

Anyway, this debate doesn’t matter, negotiate better, be active politically to ban stuff or not, complaining on the internet won’t do anyone any good. I know you’re emotionally invested in this, just… breathe and do something else? Idk. Also I’m not your enemy on this, so no need to attack me.

I won’t miss writing code. In part because I still do when I feel like it, but also because most of the time it is extremely boring. A mere mean to a goal for which you probably have the path mapped out in your brain already. It is basically just busywork at that point.

There are these moments where you need to squeeze out performance, where you change something about the UI or generally visuals and get a pleasing result, or where you discover a small tweak that collapses a lot of complexity you originally planned for - but that is, in my humble experience, not the norm in programming. The vast majority of code is boilerplate or stuff you have already written a thousand times in some variation. The more experience you have the worse it gets.

I was ecstatic when I realized how good agents have gotten, realized how I could focus on design and architecture and with small corrections, get more than adequate software. Because for me personally, programming is the least fun part of software development. Most of the time that is. And you can hate it all you want, but programming is a skill worth nothing on its own now, and it will never be again. You can take solice in the fact that you can still do it for fun if you want to.