On coordinating intrapersonal skill levels

A while ago I wrote that software is different from poker in that it's more often correct to get some mileage out of worse-performing versions of yourself (it's often best to quit a poker game when you're not playing well, but there's productive work you can do as a fuzzy programmer).

Judging from my correspondence, many people disagree with this. A few thoughts:

  1. There's a distinctive skill to making progress when you're on your B- or C-game, programming-wise. This is a great time to write tests, clean up some of the easy / annoying TODOs, write scripts to do checks on data, and so on. And if some code is impenetrable when I'm tired, that's a good sign it's not clear enough simpliciter. It's probably the wrong time to design an interface or do really hard architectural work, but there's a lot that can get done.
  2. Small commits are a good idea generally. I rely on them even more when I know I'm not at peak performance.
  3. Recently Dan Luu has offered some similar thoughts. They're characteristically excellent. (And I hope he feels well soon.)
  4. The value of learning tooling is often described in terms of raising peak performancer. Its benefits in raising mediocre performance might be understated. Writing tests confidently, rolling back changes, and so on--if you do these competently enough to do them when you're on your B-game--help a ton.

Subscribe to Nate Meyvis

You'll get email when I post new essays and notes.
jamie@example.com
Subscribe