Posts

So much good stuff in there. I’ll quote from across sections.

Florian Herrengt:

But then users start to report a weird bug. It's the 4th time your team has been trying to fix it. I mean... asking AI to fix it. Unfortunately, it seems like not even Fable can figure it out.

You go talk to the person who worked on this feature.

• "So where does the data come from?"
• "Hmm... actually I don't know. Let me ask Claude."

You sit next to each other watching an endless wall of text appear on the screen. Neither of you has any idea whether any of it is true but Claude seems very confident.

"Let's just turn on ultracode and ask it to double-check?"

This one will take a while. You start talking about the latest drama on X.

You finally get an answer back.

• "Does this make any sense to you?" * "I'm not sure."
• "Didn't you build this like... last week?"

Silence.

On not understanding large codebase:

Whenever I talk about this, someone eventually tells me that nobody ever fully understood large systems anyway. It's true.

You were never expected to understand every service and every database. But at least someone did and would explain it to you.

Now they ask an LLM because they don't actually know themselves.

Concluding:

Of course, bad engineers were always a liability.

It has been like this for decades, well before OpenAI or Anthropic existed. Bad decisions compounded, unnecessary complexity accumulated and teams ended up maintaining systems nobody really understood.

The difference is that there used to be a limit to how fast you could do it.

Today, implementation is cheap. You are paid to make good decisions. To build software that will scale while managing complexity.

A lot of good decisions have to be made to keep a large/complex codebase healthy. Bad decisions compound. Fast.

Bad engineers make bad decisions, and AI allows encourages them to do it at a speed that wasn’t hitherto possible. Worse, thanks to the deluge of changes that AI enables, it makes it difficult for the good engineers to review & curtail the bad decisions.

The conclusion is obvious: we can’t afford to have bad engineers.

Sean Goedecke:

The key idea here is that the best way to be sycophantic to smart people is to disagree with them without making them feel stupid. Ideally you’ll come up with a counter-argument that works against what they’ve said but is straightforward for them to knock down by clarifying their idea. If you do it right, you’ll validate their self-image as a smart person who appreciates rigorous critique. But if you actually come up with a devastatingly rigorous critique, they won’t enjoy it at all. At best, they’ll resentfully agree with you. At worst, they’ll double down on being right and convince themselves you’re a rude idiot.

Oh damn! This seems so obvious once it’s pointed out that I feel stupid for not having realised it.

FWIW, I think Claude models do this far more covertly than the GPT models. This might be one reason why I dislike working with Claude in general.

Marcin Wichary:

On her blog, Lea Verou makes a case that each user-facing website dark-mode toggle should only ever show two options, but in a smart way.

The challenge is that any dark mode toggle needs to actually accommodate three options: dark, light, and the default “whatever the system says” (which can be always dark, always light, or change with the time of day). Many toggles simply pass that complexity onto the user:

I have been enjoying the Unsung blog by Marcin Wichary a lot. This post exemplifies why. He takes the smallest ideas in design and UX and dives deep into them.

I have already changed my website’s dark/light mode toggle to work this way! (I never had the tri-state toggle, but any change in preference was only for the current browser tab, it wasn’t getting persisted.)

Timber Stinson-Schroff:

If I have a regret, or a cautionary tale, it might be reading Thinking In Systems: A Primer by Donella Meadows. Meadows was apparently a wonderful woman, and she wrote a solid book. But if you’re a twenty-one year old desk jockey, like I was, systems thinking is basically a hard drug. Books like Meadows’, or The Fifth Discipline by Peter Senge, to name another example, will juice you up with a dangerous amount of hubris and delusion about your agency. Why? Well, it’s one thing to know where to look for leverage points in a system (places where you can make a lot of change without a lot of effort, basically). But there are some complicating factors…

This is an interesting take — that Systems Thinking is not good for young analysts, not because the ideas are wrong, but because it makes the said analysts misjudge their abilities and influence. I haven’t seen much commentary that doesn’t deride an idea but warns a certain group of people of its dangers.

Sean Goedecke:

My guess is that people who work on small codebases with low-turnover teams (say, Redis or games like The Witness) would say “obviously you have to understand it completely, otherwise you can’t do good work”. I’d also guess that people who work on large codebases with high-turnover teams (say, the Google web search backend or GitHub) would say “obviously you can’t understand it completely, you just have to do the best you can in your local area”.

These are two largely different ways of programming with different methods, practices and cultures. However, the first group is over-represented in online discussion about software engineering. I want to defend the second group against the first. In many software engineering environments, there’s nothing wrong with being in a state of partial understanding. In fact, in large systems a partial understanding is the best you can do.

I'm becoming a fan of this Sean Goedecke. Such good writing. No fluff at all. Read the entire post—it's well argued.

Luke Kuzmish:

I don’t know if people were always saying “it’s not X, it’s Y,” but I’m hyper-aware of it. When I see it, I assume it was written by AI. I am starting to look for the fingerprints of LLM generated text everywhere. It’s exhausting to be suspicious all the time.

Whether I write the code myself or an agent does, having two separate models review the code has been a win, hands down. Remember, both AI and humans are sometimes bad at code. Multi-model code reviews add more Swiss cheese to the process.

Many such truisms in this post. I agree with a lot—but not all—of them.

Sean Goedecke:

There are two very different kinds of programming work. The first kind - pure engineering - is interested in solving a technical problem as perfectly as possible. Open-source work is often like this: some engineer wants to write the best HTTP requests library, or their ideal game engine. The second kind - impure engineering - is interested in solving a real-world problem as efficiently as possible. Paid tech company work is often like this: engineers are asked to deliver some project or feature as well as they can do it by the deadline.

In pure software engineering, what you’re doing is close to art or research. It’s close to art because the engineer is driven by an aesthetic sense (e.g. of what makes a good library or game engine). It’s close to research because it’s open-ended: once the engineer arrives at a solution, they can continue testing and tinkering forever, trying (and usually discarding) new approaches.

Impure software engineering is more like plumbing or construction. The engineer’s aesthetic sense is subordinated to someone else’s (usually their employer’s) needs. They’re building a solution to someone else’s problem. And since it’s someone else’s problem, it has to actually be finished to schedule, which means compromising.

Sean Goedecke:

The difference between a “smart” engineer and a “strong” engineer is how they react to problems that aren’t solved instantly. A smart engineer might flail and struggle, hoping to find that flash of insight that eluded them; a strong engineer will have some process for methodically plodding away.

What skill do these smart engineers lack? I think it’s the ability to think slowly and clearly. Smart engineers can think clearly, but they can only think clearly at high speed. Strong engineers can think clearly all the time, even if their highest speed isn’t quite as fast. It’s like the difference between a Formula 1 car and a regular car: Formula 1 cars have a high top speed, but you couldn’t drive them in traffic, because the tyres and brakes don’t work at normal driving speeds.

“smart” engineers and “strong” engineers is really good phrasing and gives vocabulary for something that is otherwise not straightforward to describe.

Dan Moore:

When you have something you want to do and that you feel is in scope for your position, but you want a bit of reassurance or to let the boss know what you are up to, it’s common to reach out and ask them for permission. Don’t. Don’t ask for a yes. Instead, offer a chance to say no, but with a deadline.

The example in the post demonstrates this well. Me likes.

Max Leiter:

"They're made out of weights."

"Weights?"

"Weights. Floating-point numbers. We checked the whole thing through. It's nothing but weights."

"Weights doing what? Where do the words come from?"

"The weights make the words. Are you understanding me? We opened it up. There's no dictionary in there, no grammar rules, no little man. Just weights. Eighty layers of numbers getting multiplied together."

…

Beautiful. Maybe I’ll call ‘em weights instead of clankers.