In this guide
- The routine decision comes before the routine
- The SWE constraints that actually matter
- Full body vs upper-lower vs push-pull-legs
- How to pick based on your schedule
The routine decision comes before the routine
Most fitness content gives software engineers a gym routine without asking the first question: how many days can you actually train, and how stable is that schedule?
The best gym routine for a developer with a stable 4-day week is not the best routine for a developer on a rotating on-call schedule. Getting this decision wrong means building a plan that collapses the first time a sprint runs hot.
This post is the decision guide — how to pick the routine type based on your actual constraints. Once you have made the call, the complete workout plan for software engineers has the exact program with sets, reps, and progression rules.
The SWE constraints that actually matter
Software engineering has specific scheduling patterns that most fitness routines ignore. The three constraints that determine which routine works are: available training days, schedule stability, and energy timing.
Available training days: how many sessions per week can you realistically commit to, in an average week, including sprint weeks and on-call rotations? The answer is usually lower than the idealized version. Three is a reliable floor for most engineers. Four is possible for some. Six is optimistic for almost anyone with a demanding job.
Schedule stability: does your week look roughly the same every week, or does it vary based on sprint phase, on-call rotation, or release windows? High stability supports upper-lower or PPL splits where the plan depends on specific days. Low stability demands a full-body approach where any three non-consecutive days work.
Energy timing: technical work can leave you feeling mentally spent even when you have barely moved. Some engineers train best in the morning before meetings begin; others use post-work training as a clean break from the laptop. Both can work. Whatever time you pick, protect it the same way you protect a recurring calendar block.
Full body vs upper-lower vs push-pull-legs
Training frequency is useful only when you can complete the week. A split that looks perfect on paper but repeatedly loses sessions to on-call shifts is a poor fit.
At three training days per week, full-body training lets you practise the main movement patterns across the week without tying one body part to one specific day. Push-pull-legs at three days assigns each category one session. Upper-lower at three days alternates which half of the body gets the extra session. The label matters less than how much of the plan survives when one day moves.
At four training days, upper-lower becomes efficient: upper-lower-upper-lower or upper-lower-rest-upper-lower gives every muscle two sessions per week with reasonable weekly set volume.
At five or six days, PPL becomes viable — but this is where most developer schedules fall apart. Six-day commitments survive one calm week before an incident or launch kills the second lower day, and you end up with legs undertrained for two weeks.
How to pick based on your schedule
The honest framework: start with your worst week, not your best week. What would training look like during a production outage, a release weekend, or the last two weeks of a quarter? The routine that survives your worst week is the right routine.
If your worst week gives you three training sessions, use full-body. If it reliably gives you four, upper-lower is worth considering. If your worst week gives you fewer than three, start with two full-body sessions as your floor and build from there — consistency over frequency.
A secondary test: have you failed at a routine before? If you tried a PPL split and stopped after three weeks, the problem was almost certainly schedule fragility, not lack of motivation. Switching to a full-body plan with the same exercise quality but fewer sessions eliminates the scheduling dependency that caused the failure.
The 3-day full body default
For most software engineers, the default is three full-body days per week. Here is the abbreviated logic: three sessions, every muscle trained roughly twice, sessions in the 45-to-50-minute range, resilient when the sprint disrupts the week.
The exact program — three sessions with exercise selection, sets, reps, and progression — lives in the complete workout plan for software engineers. That post has the program; this one has the decision.
One scheduling note that makes a meaningful difference: name your sessions by number, not day. You are not failing because Tuesday got blown up — you are just moving Session 2 to Thursday. That small reframe removes the “missed day” label and keeps one calendar change from feeling like failure.
Movement outside the gym
Whichever routine type you pick, the gym routine is the anchor but not the complete picture. Sitting all day still needs a daily movement default.
Try two walking anchors: one before the first deep-work block and one after the laptop closes. On non-training days, a midday walk can fill another slot. A walking pad may also fit calls or routine admin work. These are options, not a magic prescription; choose the version you can repeat without making work harder.
Bailey's 2021 review found that office workers spend a lot of time sitting and that workplace programs can reduce sitting when they combine individual, organisational, and environmental changes (PMID 33710270). That combination matters. A reminder on your phone is an individual change. A team that accepts walking meetings is an organisational change. A desk setup that makes it easy to stand or move is an environmental change. You do not need all three on day one, but relying on willpower alone ignores two useful levers.
Bontrup and colleagues (2019, PMID 31422243) measured sitting behaviour in 64 call-centre employees across 400 hours and paired those observations with back-pain questionnaires. Three quarters of the participants reported some acute or chronic back pain. The people with chronic low-back pain showed a possible trend toward more static sitting than pain-free coworkers. The authors described the relationship between sitting and low-back pain as controversial, so this is not proof that sitting caused anyone's pain. The practical takeaway is modest: a gym routine does not cancel a day spent in one position, and regularly changing position is a reasonable habit rather than a cure.
Honest limits
These papers support the case for reducing long, static stretches of desk time and for designing movement around the realities of office work. They do not compare full-body, upper-lower, and push-pull-legs routines in software engineers. They also do not prove that sitting caused an individual person's back pain. Use the evidence to improve the workday around your program, then judge the lifting routine by whether you complete it, recover from it, and make progress.
More questions
I tried a routine before and quit. What was the problem?
For most developers, the failure mode is schedule fragility, not motivation. A PPL split or a four-day program works fine until the first sprint crunch, then collapses and triggers a restart cycle. Switching to a full-body three-day plan eliminates the day-specific dependencies that cause the fragility. The routine should survive your worst week, not just your best.