upvote
there is certainly code that sucks; but the article strikes me as someone conflating "code that sucks" with "code that is complex and big and takes a while to get used to".

I have found that a lot of the "massive amounts of bad code" left behind by "rockstar developers" is actually just a long slow drip of added complexity in the face of changing requirements. and I find that people think they're "refactoring the code for readability" when a lot of times, they are actually just "rewriting the code and therefore understanding it in that process".

reply
tl;dr: "Slow down and think about what you're doing when using an LLM." Saved you five minutes.

I was expecting a lot more, or a worked example, or _something_ to that effect. 90% of the text is the author complaining and defining the problem, then a hand-wavy vague solution is presented in the penultimate paragraph. Barely relevant or useful, really.

reply
Almost all opinion pieces are like that. They lack information density, but some readers (like me) like them that way. Otherwise, I'd only read one-line summaries.
reply
I guess some people don't like articles that don't deliver a skill.md to solve a problem.

For me the article is about programmer culture and work ethics, it's hard to discuss with hard facts. Yet sharing this personal experience is valuable.

reply
I mean, go look at the author's linkedin and github. They're a "dev" with 20 years of 1 year of experience. Not a software "engineer"

There's a big difference between the two and LLMs are increasing the chasm. The Software devs are crying out because the LLMs can already do their full job. Software engineers are happy because the LLMs are removing a large chunk of the job that's low value.

Software dev using an LLM is gonna produce "slop"

Software engineer using an LLM is going to have an increase in productivity depending on how they're using the LLM tools.

reply
There is no universally accepted distinction between developer and engineer.

Even if so, dev or engineer, both can be low or high skill. Their job title doesn't tell how sloppy or good their LLM usage will be.

reply
This isn't about distinction between literal titles. But continue missing the point.
reply
You make up an false dichotomy. The differentiation between the title and the supposed skill level based on title, is neither true nor helpful to make your point.
reply
There's no false dichotomy. You're just choosing to miss the point to argue semantics.
reply
Well you could make your point clear, instead you keep acting like I am hostile.
reply
Yeah it is. The meat of your post is textbook gatekeeping. "This is a dev, not an engineer."
reply