dreadwail

@dreadwail.bsky.social

A dev team saying they're "done" because they shipped a feature is like a doctor saying they're "done" because they gave the patient the medicine. We're not done until we've solved the problem (or given up trying). This, I regret to inform you, requires you know what problem you're trying to solve.

Allen Holub@allenholub.bsky.social · 3mo ago

My measure of productivity is the time it takes to get the solution to a user's problem (their story) into their hands. I couldn't care less about vanity metrics like output volume or token counts. What matters is delivering value sooner. 1/2

There is something brutally psychically injurious to being constantly told "just do good work and you'll be successful" while watching people who do the most dogshit work possible do all the succeeding.

I find the acceptance and defense of mediocrity to be deeply depressing. This is true not just in the context of large language models, but particularly in the case of certain scholars and politicians.

"Once men turned their thinking over to machines in the hope that this would set them free." "But that only permitted other men with machines to enslave them." --Frank Herbert, Dune

I don't really post things on the internet much anymore because my industry and the world at large have both gone mad. I'm just a bit shocked/stunned and don't really know if the world needs me to add my word noise into the LLM-ridden husk that remains of what was formerly the internet.

I see posts on LinkedIn from people who believe dev teams should be pushed to adopt "agentic" coding so they can reap the "10x" productivity gains. Putting aside the lack of evidence for even 1.5x gains on teams, if it really were possible, why would they need to be pushed towards it?

Seeing more and more posts from engineering leaders along the lines of "Tried Claude Code over the Xmas holiday and generated 10 squillion lines of code (that almost worked) in 10 minutes. Now mandating all our engineers use it as much as possible. Because I don't understand bottlenecks."

Very often when trying to think about a problem I start wondering: "How does software X deal with that?" And 98.5% the answer is: they don't, they just let it fail. Often silently. Every time I keep relearning how low the standards usually are in this industry.

I really do love the spec style syntax for tests (describe, before each, it). When used correctly it's the best at representing test setups and expressing test intent. I also recognize it has many downsides that have to be accounted for. Let me tell you, it really sucks resolving merge conflicts.

You call it "over-engineering" when devs make software more complicated than it needs to be. But simpler solutions often require *more* thought. Complexity's easy. You just keep typing. That's why I call over-complicating "under-engineering".