The Gym Is Part of the Job
We profile everything except the machine doing the reasoning. The hard bugs are found in hour six of concentration — and hour six is a physical capacity, not a character trait.
Everything else in this job gets measured. We profile queries, budget the event loop, track p95 latency, argue about bundle size in kilobytes. Then we run the entire operation on one component that is never profiled, has no monitoring, and is assumed to perform identically at 9am on Tuesday and 6pm on Thursday of a release week.
This is not a post about discipline, and it is definitely not a post about looking a particular way. It is about the observation that a career in engineering is paid for one output — sustained, accurate thinking over decades — and that the inputs to that output are almost entirely physical. Treating training as a hobby you fit around work has the dependency graph backwards.
The unprofiled component
The way this degrades is slow enough to be invisible, which is precisely why it is worth naming. Nobody has a bad day and concludes their cardiovascular capacity is the problem. What happens instead is that the baseline moves:
- The afternoon becomes an administrative shift. You do not decide this; you simply stop attempting anything hard after 3pm and start calling that your natural rhythm.
- A low-grade ache in your neck, your lower back or your wrists becomes normal enough that you would not think to mention it. It is a constant tax on attention, and constant taxes are the ones you stop noticing you are paying.
- Your tolerance for frustration narrows. The design discussion that would have been interesting is now irritating, and you cannot tell whether the proposal is bad or whether you are tired.
- Recovery time from a hard week lengthens. What used to take a weekend takes a fortnight, and the deficit carries forward.
None of that looks like a fitness problem from the inside. It looks like getting older, or like a bad quarter, or like being over this industry. Sometimes it is those things. Often it is a load-bearing component running degraded with no alerting on it.
Debugging is a stamina sport
Here is the part I am most confident about, because it maps directly onto work I can point at.
Easy bugs are found immediately by anyone. The bugs that survive to production are the ones that require holding a large amount of state in your head at once — this service's retry behaviour, that queue's ordering guarantee, the timezone conversion three layers up, and the one code path where all three interact. Finding it is not an act of cleverness. It is the ability to keep a dozen facts live simultaneously, for ninety minutes, without the model collapsing and having to be rebuilt from the start.
That capacity is not fixed and it is not a personality trait. It varies enormously with sleep, with how recently you ate, with whether you have moved in four hours, and with the aerobic base that determines how much of your afternoon is actually usable. On a good day I can hold that model for over an hour. Underslept, I rebuild it four times and end up rewriting a retry policy that was never the problem, because I could not keep enough of the system in view to see where the real fault was.
The cost of that is not just the lost afternoon. It is the wrong fix, shipped, in code someone else will inherit. Reviewers do not catch that kind of mistake, because the diff looks reasonable — it is a correct change to the wrong component.
Sleep is the dependency everything else has
If only one thing changes, this is the one. Sleep is where the day's learning gets consolidated, which for us is not a metaphor: the unfamiliar codebase you fought with all Tuesday is genuinely easier on Wednesday, and it is easier because you slept, not because you thought about it more.
Two things make this a training question rather than a separate one. Regular physical activity is one of the more reliable ways to improve sleep quality for most people — it is one of the first recommendations in any evidence-based guidance on insomnia, ahead of anything you would buy. And the reverse coupling is brutal: badly slept, you will skip the session, which worsens the sleep. It runs downhill on its own.
The finding worth internalising is that self-assessment fails here. Sleep deprivation degrades performance and degrades your ability to perceive the degradation at the same time — people who are measurably impaired rate themselves as fine. This is why the late-night push feels productive. You are not a good judge of your own output at 1am, and the commit history the next morning is a more honest reviewer than your memory of the session.
Which reframes the heroic all-nighter accurately: it is not extra capacity, it is a loan against tomorrow's judgement at an interest rate you do not get to negotiate. Occasionally worth taking for a genuine incident. Never worth taking as a routine, and a team that requires it routinely has a staffing problem it is describing as a culture.
The problem is duration, not posture
Most desk-health advice is about equipment, and equipment is the smallest lever. A better chair, a monitor at the right height and a keyboard that suits your wrists are all worth having — they raise the ceiling on how long a position is tolerable. They do not change the fact that any position held for four hours is the problem.
A standing desk is not an exception, it is a second position. Standing still for six hours produces its own complaints. What actually helps is alternating and interrupting: getting up roughly every half hour to forty-five minutes, even briefly. This is easier than it sounds because the work already has natural boundaries — a test suite running, a deployment going out, a build, a code review you are waiting on. Those gaps exist whether or not you use them, and using them is free.
The strength component matters here for an unobvious reason. A body that can comfortably hold a position has to work less to hold it. Most of the neck and back complaints that engineers accumulate are not injuries, they are endurance failures in muscles that were never asked to do anything else. Training them is treating the cause; a cushion is treating the symptom.
The unglamorous minimum
This part is deliberately boring, because the interesting version is the one people quit in three weeks.
- Two or three strength sessions a week. Full-body, basic movements, forty-five minutes. Two is enough to make real progress and two is achievable in a bad week, which matters more than the ceiling.
- Some easy cardio. Two or three sessions at a pace where you can still hold a conversation. This is the boring intensity that builds the base, and the base is what your afternoons run on.
- A daily walk, ideally outside and ideally after lunch. The cheapest item on this list and the one with the most obvious same-day effect on whether 3pm is usable.
- Breaking up the sitting. Covered above. No equipment, no plan, no subscription.
Two concepts from training that transfer so directly that engineers usually recognise them instantly. Progressive overload: capacity grows in response to a load slightly beyond current comfort, applied repeatedly — not in response to one heroic effort. And deloading: planned lighter weeks exist because adaptation happens during recovery, not during the work. Both are things we already believe about systems and refuse to believe about ourselves.
The usual objection is time, and it is worth answering plainly rather than dismissing. Four hours a week is a real cost. It is also approximately the amount of the working week you currently lose to afternoons where you are present but not thinking clearly. I am not going to claim the trade is always favourable, but it is a trade, not an addition — and it is the only one of your inputs that compounds over a thirty-year career.
One caveat that belongs in writing: if you have an existing condition, a current injury, or you are starting from a long way back, the sensible first step is a professional who can look at you specifically. A blog post cannot do that, mine included.
How engineers get this wrong specifically
We have characteristic failure modes here, and they are recognisable enough to be funny.
Optimising the instrumentation instead of the system. The most common one. Three weeks of research into programmes, a spreadsheet, a wearable, a dashboard correlating heart rate variability with commit frequency — and eleven actual sessions completed. It is the same instinct that builds a beautiful admin panel for a product with no users. The boring programme you follow beats the optimal one you designed.
All-or-nothing scheduling. A plan requiring five sessions a week survives until the first on-call rotation and is then abandoned entirely, because the plan had no degraded mode. Design it like you would design anything else that has to run in production: what does this look like during a bad week? If the answer is “it stops,” the plan is wrong, not the week.
Treating recovery as laziness. Training every day without a rest day is the equivalent of running your servers at 100% utilisation and being surprised by the cascading failure. Rest is not the absence of the work; it is the part where the adaptation happens.
Turning it into another performance metric. This is the one I would most warn against, because it reproduces the exact problem it is supposed to solve. If training becomes another leaderboard, another streak you cannot break, another way to be behind, you have taken the thing that was supposed to buffer the pressure and made it a source of it.
What it does not fix
Every other post here has a section on when the advice does not apply, and it would be dishonest to skip it in the one place where the overclaiming is worst.
Training does not fix burnout. Burnout is largely a function of workload, autonomy and whether the work feels meaningful. Deadlifts do not restore autonomy. Being fitter may raise the level of chronic overload you can absorb before breaking, and if that is being used to absorb an understaffed team and a punishing pager rotation, then fitness has been recruited to hide an organisational failure. The gym is not a remedy for a bad job, and any advice that positions it that way is working for someone other than you.
It is not a moral hierarchy. A colleague who does not train is not less serious about their craft. Disability, chronic illness, pain conditions, caregiving, poverty, working two jobs, and simply having other priorities are all real and none of them are a failure of discipline. The claim here is narrow — that physical capacity is an input to cognitive work, and that most of us have more room to influence it than we act like we do. Anything beyond that is moralising dressed up as engineering.
None of this requires a gym. The word is in the title because it is the shorthand, but the useful floor is movement: bodyweight work in a small flat, a walk, stairs, anything progressive. If the barrier is money or access, the barrier is not to the thing that matters.
And the effect size is honest but modest. I cannot tell you this makes you a better engineer, and I am suspicious of anyone producing a number for it. What I will claim is narrower and I think defensible: it widens the window in which you are capable of your best work, and it extends how many years you get to do this. Both of those are worth more than a technique.
The short version
The work is sustained thinking, and sustained thinking runs on physical capacity we habitually leave unmonitored. The hard bugs get found in hour six of concentration, and hour six is a capacity rather than a virtue. Sleep is the dependency everything else has, training is one of the better ways to improve it, and you are not a reliable judge of your own output when you are short of it. Two strength sessions, some easy cardio, a daily walk and interrupting the sitting is the whole programme — and a plan with no degraded mode will not survive its first on-call week. Then be honest about the limit: none of it fixes an understaffed team, and none of it makes anyone a better colleague than the person next to you who does not do it.