pthm.dev

You're working too hard.

My partner and I had just spent a weekend cleaning and organising the apartment. We were on the final round, wiping things down.

She was scrubbing a stain off a countertop with a damp cloth. I offered her some cleaning paste. She declined and kept scrubbing. I was fairly sure the paste would help, so I offered again. She took it, probably to appease me.

It cleaned the stain in seconds.

This is not really a post about relationships, or cleaning, or living with someone. It is about a pattern I notice all the time, in other people and in myself: the reluctance to make a small change that would make the task easier.

There is a tiny sunk cost to it. You know the work is going slowly. You suspect a different approach might be faster. But you are already doing the thing, and stopping now feels like adding another task. So you keep scrubbing.

It doesn’t feel lazy

Larry Wall, who created Perl, said the three great virtues of a programmer are laziness, impatience, and hubris. It is a deliberate inversion. The traits we usually praise, like diligence and persistence, are often the ones that keep us scrubbing.

My partner was not being lazy. She was working hard. She was just doing it the slow way.

The lazy move, in Wall’s sense, was the paste. What I find interesting is that it does not feel lazy in the moment.

When you are heads-down on something, reaching for a different tool does not feel like the easy option. It feels like a detour. You have to stop, find the thing, use it, and then probably put it away afterwards. Meanwhile, the scrubbing feels like progress. Your hand is moving. The task is still happening.

So the slow approach feels simple, and the better tool feels like extra work.

The switching cost is real, and you pay it immediately. The saving is less visible. It is delayed, spread out, and slightly uncertain. While you are still moving, it is easy to discount.

So you choose the certain small cost over the possible larger saving.

The feeling that says “this would make a simple job complicated” is not always telling you the change is wrong. Sometimes it is just what a switching cost feels like. And a switching cost is not the same thing as a net loss.

Make the change easy

Wall gives you the motive. Kent Beck gives you the method:

For each desired change, make the change easy (warning: this may be hard), then make the easy change.

The warning in the middle is doing a lot of work. Making the change easy may itself be hard, and that cost comes before the payoff. That is the bit people avoid.

Beck is often read as talking about refactoring, and sometimes he is. But the smaller version is everywhere. Nobody restructured the countertop. She just picked up a better tool.

In programming, this version shows up all the time:

None of these are grand structural changes. They are just better tools, or slightly different motions. That is part of why they are easy to skip.

A big refactor announces itself as a real decision. Skipping the better tool usually does not. It just feels like continuing.

Brute force works in short bursts. Sometimes pushing through is the right call. Sometimes stepping back is just procrastination. But there is a point where brute force stops paying for itself, and that point is often easier to see afterwards than during.

It is easier to see from the outside

I pair program fairly often, usually with the same few people. With one of them in particular, we end up talking through these trade-offs as they happen. We push each other to make the small change: write the test, fix the log line, use the debugger, narrow the failing case, stop rerunning the whole thing.

It works because the pattern is easier to see from the outside.

When you are the one typing, you are inside the task. You are tracking the next command, the last error, the thing you were just about to try. The observer is not carrying quite the same local state. They can see that you have run the same broken thing four times. They are the one who says, “Just write the test.”

You usually know it too, somewhere. But the person with their hands off the keyboard is more likely to say it out loud.

That is a lot of the value of pairing. Not some grand collaborative magic. Just a second person who is not trapped in the same small loop.

With AI, you are always the observer

Hand a task to an agent and you become the observer by default. Your hands are off the keyboard. You should be in a good position to notice when the work is going sideways.

Often, though, it becomes a worse version of the same problem.

Watching an agent grind through the wrong approach feels like delegation, so it feels efficient. But sometimes it is just unattended scrubbing. The agent burns through attempts on a problem that needed reframing, and you let it continue because watching costs very little in the moment.

With a human pair, the feedback loop is tighter. You interrupt each other naturally. With an agent, the loop is slower, and it is easier to wait.

The feeling has flipped.

With the cleaning paste, the better move felt like effort. With an agent, the worse move feels easy. Just let it run. Let it keep trying. Stepping in to reframe the problem feels like the work.

The observer’s job is still the same as it is in pairing: notice the grind, and say the small thing out loud.

This is the wrong question. Add this constraint. Use the tool. Write the test. Stop trying to infer the file. Read it. Stop asking it to brute force the whole space. Narrow the space.

That small interruption can save a lot of wasted motion.

It is the same move as before. Stop pushing harder and change the shape of the work.

The hard part is not knowing this. The hard part is that effort now is a bad proxy for effort overall, and we trust it anyway. The better move rarely feels easier. Usually it feels like a hassle. One more thing to find, one more thing to set up, one more little detour before you can continue.

But maybe that is the point. Sometimes the thing that feels like working hard is just scrubbing.