"Code was never the hard part" is an insult to all programmers

switching keyboard layouts

I mean, if you don't know how to type (which you didn't at the time) then I can imagine that being the hard part of the job.

In your example of the LLM-assisted refactor, the hard part wasn't typing then either.

I'm not sure what you think my position is.

LOL I read this as "writing a manual clone(2) implementation isn't hard"

That argument still doesn't make sense; writing a manual clone() implementation or renaming a function call isn't hard, but nobody would say that automatically doing either of those things isn't worthwhile.

I think that misses the point. We've always automated or paid for the conduction of easy tasks. Nobody claims they aren't tasks. And tasks you want to automate.

Clicking a button once a day/week/month isn't hard, but a cronjob is still worthwhile.

I've also noticed that during parts of my life where I was typing much slower (switching keyboard layouts) I found myself a lot less inclined to experiment, and it negatively affected my development.

I have had the opposite in that if a thought lingered longer new better approaches came to mind (more performant, simpler, easier to read, more DRY code).

Your last paragraph I agree with, in the same sense that an editor/IDE with good regexp replace or refactoring related functionality can save you a lot of time. However, I think this isn't all that related to what "code was never was the hard part" means.

In the context of LLMs I think it means at times what people mean when they talking about "prompt engineering" (which I hate as a term, because it implies things that make no sense, but that's another topic). In that you first need to know what you actually want. A classic situation is when I as a programmer am ask to do X, when I know I will need to ask why they want to do X, because if I just implemented it I might make things worse rather than better. Eg. their goal might be achieved in a way that is less hassle for them, me and might even be a lot more reliable.

Also to be clear, I am not saying that LLMs are not or will never be capable of that. Just that I think coding as in "writing yet another endpoint that outputs something from the database" obviously was never something that a novice programmer couldn't do likely on the side. However because of that fact that also wasn't the thing that made people earn salaries or else there would only be junior programmers.

There's a lot of work happening in software development where this is exactly the main part of the job. It may not be everyone's job, but "here's a simple bug/feature, get it done" is a huge part of the system. There's also the "here's the new law/spec, update the systems" in a few industries. (Most of my clinic's software updates are data/rule updates related to billing) It's not a technically hard part either really - it just takes lots of time and resources which makes it overall a hard part of the process.

And the volume itself can become an issue as well - you can produce more test inputs, reviews, security checks, etc. just by volume. These are often things that are trivial to make but just need doing. If you can't type them fast enough, but want to achieve maximum reliability, that in itself is a hard problem too. We solved some of it with meta approaches like fuzzing and automated checks, but that's not nearly enough.

To be clear, that idea doesn't take anything away from actual software engineering being a hard task.

‘Code was never the hard part’ is the excuse some people are peddling to keep themselves employable.

One thing AI has revealed is how much of public software development, in blogs, at conferences, was, for some, a performative ritual to court the interest of potential employers and investors.

When expertise was rewarded, these people role played as experts. When Open Source was seen as a resume booster, these people loved Open Source. Now that these things have been devalued, these people will pretend that they were always the essential human element in software development.

Fine so far, I actually do think software development needs a human element. But these people also find it a convenient part of their story to minimize the importance of that other skill, software development, because it is no longer a career enhancing one.

This blog post feels like a strawman argument. What to build is also about programmers (personally I like the term software engineers better) making decisions. For example they need to decide on a fitting tech stack. You need expert software engineers to know or at least understand all the footguns of that decision. AI will provide a tech stack, but that may very well bite you someday in the future and this happens with every larger application. Not generating tons of tech debt while implementing features is really hard and needs experience, just implementing a solution you just need to be smart.

I do believe that talking to users, understanding their experience, empathizing with them, solving customers' problems and having all the stakeholders on the same page is critical to the success of a software project.

I also believe that creating good code is a craft that requires skill, patience, attention to detail, experience and wisdom, and that it will continue to be relevant in the times ahead.

I agree with this, which seems to be the heart of the article. But doesn't that just reinforce the argument that, "Code was never the hard part"? As the quote argues, It is good code that requires the non-AI craft of "skill, patience, attention to detail, experience and wisdom". Therefore, we can all slope code, even the machines. Is the article title just bait then?

If you're arguing that anti-AI sentiment is an "insult" to programmers, you really have to follow through with it.

If coding is easy, why are people angry at AI (or anyone else) copying their code? Why do they act like they've poured their sweat, soul, and copious amounts of time into something so trivial?

Now that is an insult. It is not about copying, it is about attribution. I want my work to be copied. I want to be useful in this life. What I don't want is to be exploited. We are better together. Which I would suggest is the actual sentiment behind, "Code was never the hard part". How do we work with other people? How do I write code that is easy for other people to understand? How do I conduct myself in such a way that I make it easy for people to approach me and feel comfortable about contributing to my code? AI is fundamentally opposed to this perspective, both industrially by its capitalist owners and technically by being trained as a mere token prediction machine.

I'm reminded of the house shares I lived in when I was younger. It wasn't the fact that I did more chores than everyone else that upset me, it was the fact that certain housemates were annoyed when washing up wasn't done or rubbish wasn't taken out. Perhaps they were the budding AI enthusiasts? Unaware of how the world actually works, they think they're above menial tasks and therefore delight in confidently arguing that everybody else is too.

I've heard that argument a number of times and I think the author is reading it in a fairly uncharitable way. I'm not saying my understanding is more "correct", but in the context of LLMs, I understood it as "producing lines of code was never the bottleneck" - i.e., you can't be a 100x+ engineer just because you have Claude, even though it does produce code at 100x+ your speed.

Another way of putting it is that some amount of friction is good because it prevents you from creating software that's utterly unnecessary, unmaintainable, or otherwise useless.

I don't know if this will hold true in the long haul, but again, that's how I read the argument.

for a bigcorp that have a lot of software developers, code was never the hard part, and in this angle the sentence has a strong point: for such companies llm's seem like a financial optimization

if we take the sentence at face value then yeah its an insult, like alsmo any other sentence can be seen as an insult, but it is not intended a such, and the target of this sentence is those doing the layoffs and driving the narrative that llms will crush us all, the ones that have developers to the thousands and yet take the common falacy stance that those that produce the value are the ones that accumulate it (not the workers)

Another cliché comment is “most work in software development is talking to stakeholders, understanding the customer's needs, and having clarity on the priorities”.

This bit really resonated with me. My current project at work is a multi-month rewrite to get better performance out of a system that wasn't designed for all the things that was asked of it as we built features on top of it. There is very little of the "human-y" bits that I sometimes see brought up as the "true" essence of software development; it would be absurd to suggest that the true work is in figuring out that, shockingly, customers prefer fast responses to slow ones.