Technology

I read "Code was never the hard part" as "Writing the Code down is easier than the stuff you do before it (like Architecture, Design Patterns, Requirements) and after it (Testing, Troubleshooting, Refactoring, etc)".

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.

Whoever you are, don't outsource your understanding, judgement, empathy and taste to AI. Don't abdicate your responsibility. Don't be a meat proxy.

By expanding the ability to program to people without the knowledge of how that code works in the first place, it's naive to expect that most uses of AI in programming will be informed uses by senior developers able to recognize errors and security flaws.

Such a pro-AI position also ignores the enormous amount of theft that these tools are built on.

Typing the code isn't hard.

Figuring out what code to type is.

Coding is problem solving, and solving problems can be very hard depending on the problem you're trying to solve.

I appreciate the intent behind that sentence, and the problem is that is written (or said) by people who don't understand coding.

Syntax was never the hard part. Code syntax is a set of rules that you can teach a machine and it's "easy" enough for an LLM to grasp it. The problem here is that this phrase does a "code = syntax" but ignoring all the difficult things that actually are in the code. Architecture, design, tradeoffs, translation of vague requirements into concrete software components...

All of those things are terribly hard, and the reason why many LLM-first coding projects get abandoned at 70% and then companies need to hire a Software Development consultancy to mop up their mess.

"Code was never the hard part" is probably made up by someone who never had to program anything serious.

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.

Code is integral. Everything they add to it, and build around it, is to support the code. Code is the God in the machine.

How do we thrive?

Accept that change happens. Be equal parts curious and critical about the new stuff.

That is not the solution. One cannot thrive if one cannot be seen or has been discarded as a relic no matter how up to date that person is. They will never be granted the opportunity to thrive as they have before as an employee. Their only hope to thrive is if they (magically) gain all the skills and networks necessary to be an entrepreneur that can do it all themselves. Nearly a unicorn.

Meantime while trying, they burn through what savings they have on the hope and dream of "being relevant again" and have about a 5% chance of success.

Maybe the author is misunderstanding the gist of the original article. Regardless, he raises an obviously accurate assessment of those who hold the hiring power. When I was recently out of college learning my craft, it was a common sarcastic refrain of either, "What could be so hard about it, it's all 1's and 0's" or "What's taking so long - you're just typing on a keyboard".

This has been a problem since long before I graduated from college (when classifieds called for 10 years experience on an IBM system that was released two years ago) (see, things don't change so much - names and places, sure, but not much else). People who are in leadership positions, who think they're better and smarter than most everybody else, frequently belittle those who do the grunt work, both physical and mental. It's gotta be a corollary to dunning-kruger theory (or maybe an example of it).

Cooking is easy. That's not an insult to a chef.

That try, the hard part is algorithmic and avoiding archictuctural traps and experience. Pissing code which didn't work or look like it work but don't is easy.