Posted by senko 1 day ago
Second of all, most of us haven't worked on the software that send people to space or similar. We unfortunately only move data from one place to another.
People wrote production code after 6-months of boot camp. Writing code is easy. (Quality, scalability etc. are the harder parts).
Part of this is captured with this famous quote:
"The best minds of my generation are thinking about how to make people click ads." - Jeff Hammerbacher
So the insult is probably to a negligible fraction of programmers.
Because they're not the ones deciding it, they just provide input for the Heads/VPs/managers who make the strategic decisions. And they are paid pretty well for this.
I wanted to make this distinction because it changes the approach to managing communications. And it isn't just coders. Sometimes a manager isn't going to tell a developer "stop trying to hard and just slop it out" because the manager also has a self image that doesn't involve shipping swill to their customers.
And I do think sometimes it really is difficult to know exactly where to draw the line. What parts of the product need gold plating? Where is stress going to appear, what is going to cause unexpectedly annoying debugging? In hindsight you should have spent more time there, not here.
Maybe I've been privileged to work with people who care about real things- I've spent my whole career in relatively small orgs. I've self selected for that.
Actually, now I think about it, I do believe I've met (not worked with) someone who was very into the code for its own sake. This was at a research institution, using Haskell, where "experimenting with edgy functional programming" was, if not part of every project, certainly an accepted and deliberate part of the culture.
And that if you make a bot that produces syntax you haven’t produced a programmer.
Some workers are more 1:1 with syntax, like a developer from a gig platform or overseas contractor, the deliverable being code files.
But the staff software engineer deliverable should be software, novel outputs, a face in meetings, someone to blame if it all goes wrong, a member to fill out the ranks, a person to get coffee with and talk about adjacent things that open new doors, in a sales capacity it might mean travel and interpersonal stuff like drinks and talks to convince people to integrate, it’s thoughtful often emotional back-and-forth from frustrated contributors on GitHub that lead to changes and innovations, and other things of value that language models can never do.
I would say further that even if you model emotional intelligence, or the whole world even, unless AI has a face I can punch if it crosses some line and it knows it has a face, what its own face is and why that matters to itself, it will always fall short in terms of empathy. Our sense of empathy and emotion originated in the wilds among fear and terror and the thrill of catching and eating food, discovering others, and understanding the consequences of everything before me in this moment.
Well, this is also an insult.
Cleanest way I read this is seeing how basically none of it makes any sense for someone coding as a hobby, or in any non-business context.
This is not an article about coding, it’s a promotional piece for business stakeholders.
No matter how long you spend on architecture, no matter how carefully you plan your features, if you are an actually good developer there are choices that emerge only from the first draft of the code — things that you could do better, broader ideas that suddenly emerge and change your view of your own work, abstractions that become possible once you internalise the project through writing it, realisations that a requirement is unscalable, unworkable or unsafe, etc.
Nobody ever finds all those things only in the planning stage in any piece of code of consequential size or functionality: if it was easy, we'd all be doing waterfall development like 1970s consultants or using StP like 90s consultants, and none of those other ideas about coding would ever have emerged.
LLMs will just write the code. They will never have the rest of that experience. And I think any coder who doesn't have a visceral feel for what I said above is just bad at it.
"The code was never the hard part" is just edgelord AI evangelists masking denial with a pithy mantra. The code, its capabilities, the tooling choices, it's all indivisible from all the other hard parts.
But then these are often also the people who think they can use AI song or image generators to do the bulk of the work and "add the finishing touches". They also think "taste is all that is left" when the thing that gets us paid is not just our taste, it's our responsibility for and to our work.
But I enthusiastically agree with your point about engaging with your output and having that deep understanding of all the intricacies and, well, you already said it better.
I also can’t shake the feeling that many hardcore LLM proponents are actually, genuinely worse at this than I am, and that’s simply it. In my vicinity, the loudest and most extreme LLM jockeys are all people who I personally don’t think are great engineers, or even that smart. They might be right in the end and I might be wrong, but these people definitely won’t become my role models anytime soon.
It was a very useful contraction in the right senior circles where there was a pretty good understanding of the meaning and decently reliable assumed consensus.
I eventually stoped using the phrase because it had started leaking deeper into the team and the impact on earlier career or less confident programmers was often no longer positive, it could be misinterpreted in lots of different ways but the most harmful was when it would further decimate confidence and discourage requests for help when something wasn’t obvious to the ultimate author.
As with almost every attempt to generalize in software engineering the repetition or extrapolation beyond the context in which it was intended can have negative side effects, it doesn’t matter if it’s a simple notion like “dry”, or a comment like “code was never the hard part”. None of these phrases survive context loss and still retain efficacy at general receivers.