REST APIs and rest days: balancing tech and fitness

I lift four mornings a week. I have for about three years. I'm going to argue, briefly and without much defensiveness, that it has made me a meaningfully better software engineer.

This is not a grindset post. I don't lift heavy. I'm not optimising for anything specific. I just go in, do the work, leave. The argument is about what the habit does, not what the gym does.

What you cannot debug

The first thing the gym teaches you is that some problems aren't debuggable. You can't think your way into a stronger squat. You can analyse film, fix form, plan progressive overload, but at the end of the day you have to put the bar on your back and push it up. There's no shortcut where you read more about it.

Most of programming feels debuggable to me. I can read more, think more, refactor more. The gym is one of the few activities I do where I am fully out of my head — there's a heavy bar on me and I have either to move it or to fail under it. There's no fourth option.

That contrast is doing real work in my brain. It makes the rest of the day's problems feel more tractable.

The compound interest of showing up

Lifting four times a week for three years is sixteen sessions a month, ~190 a year, ~570 over the period. Each session is one small adaptation. None of them feel transformative. Together they're transformative.

Software is the same. One small refactor. One slightly better test. One commit that makes the diff easier to read. None of them are transformative. Five hundred and seventy of them are. The hardest part is not believing in the bigger payoff and showing up anyway.

What an actual rest day does

The week I switched from five sessions to four-with-an-active-rest-day was the week my lifts started moving again. Stagnation broke not because I did more, but because I did enough less.

Programmers know this version of the lesson too, in theory. The bug you can't fix on Friday is the one your subconscious solves on a Saturday morning walk. We just don't structure for it. We work until we're tired and then we work some more.

I structure for it now. The non-gym days are not "off" — they're recovery. I do mobility. I walk. I read. I cook. I deliberately work shorter sessions, with explicit breaks.

The fix wasn't to fight the recovery. It was to schedule it.

Heart-rate variability as a deploy gate

This is the most "from a developer to a developer" thing I'll say in this post: I watch my HRV (heart-rate variability) the way I watch my CI pipeline.

• Green for two days in a row: lift heavy.
• Yellow: lift, but lighter, and shorter.
• Red two days in a row: don't lift. Walk. Sleep. Drink water.

The point isn't the metric. The point is having an external signal about your own state that doesn't depend on you feeling rested. I am the worst judge of whether I am rested. My wearable is a fine judge.

A version of this in software: trust the dashboards more than the vibes. The vibes lie. The dashboards do not.

The one thing the gym does for code

If I had to point at one specific thing the lifting habit has done for me as a developer, it would be this: it has made me extremely comfortable with the gap between effort and result.

In the gym you push hard for weeks and the bar doesn't move. Then one day, without ceremony, it does.

In code you debug for hours and the test doesn't pass. Then you change one character and it does.

If you've never trained the relationship between sustained effort and eventual breakthrough, debugging is psychologically miserable. If you have, it's just Tuesday.