7 Fitness Questions Software Engineers Ask About Working Out, Losing Weight, and Staying Consistent (Answered Honestly)
- Alex

- 1 day ago
- 6 min read

These are not theoretical questions.
They come from real conversations - Reddit threads, DMs, discovery calls, and the kind of messages people send at 11pm after another day of sitting for 12 hours and feeling like they should be doing something about it.
I've answered versions of these questions hundreds of times.
Here they are, answered properly - without the generic advice you've already read everywhere else.
1. "I sit 10+ hours a day and keep gaining weight despite eating 'healthy' - what am I doing wrong?"
Probably nothing obviously wrong.
The problem is almost always one of these three things:
Your definition of 'healthy' doesn't account for total calories. Avocado, nuts, olive oil, protein bars, smoothies - all marketed as healthy, all very calorie-dense. You can eat entirely 'healthy' food and still be in a significant caloric surplus without realising it.
Your protein is too low. Most software engineers I work with are eating 60-80g of protein per day when they need 140-180g. Low protein means high hunger, high snacking, and poor muscle retention - which lowers your resting metabolism over time. You gain weight even when you're not eating that much.
The invisible calories are the problem. Evening beer or wine. The handful of nuts while debugging. The large dinner after skipping lunch. These don't feel like much individually. Over a week, they add up to the exact surplus that explains the 1-2kg per year accumulation.
Two weeks of photographing every meal - without changing anything yet - will show you exactly where the problem is.
Engineers respond to data.
Get the data first.
2. "How do you find motivation to work out after a mentally exhausting day?"
You don't.
And you shouldn't be trying to.
Motivation is a feeling.
Feelings are unreliable.
A software engineer who has spent 10 hours in deep focus has a depleted prefrontal cortex - the part of the brain responsible for willpower, decision-making, and motivation. Expecting motivation at 7pm after that is like expecting a battery to charge itself.
The answer is not more motivation. It's less decision.
When the workout is at a fixed time, on fixed days, with a fixed program - the brain doesn't need to decide whether to do it. It just happens. The decision was made once, in advance, when you were not exhausted.
The other thing that helps: make the barrier so low it's almost embarrassing. A 20-minute session after a brutal day counts. A 15-minute session counts. The goal is not the perfect workout - it's not breaking the chain.
Momentum is worth more than any individual session.
3. "Is 2-3 times a week actually enough to see results or do I need more?"
Two well-recovered sessions per week will produce more results than five under-recovered ones.
This is not a motivational statement - it's physiology.
Adaptation happens during recovery, not during training. If you're never fully recovering between sessions - because you're also managing a demanding job, imperfect sleep, and chronic low-level stress - more training creates more fatigue without more adaptation.
For most software engineers working full-time, two full-body resistance training sessions per week is the optimal starting point. Not a compromise. Not "better than nothing." The actual optimal dose for someone with your total stress load.
After 3-6 months of consistent two-session weeks, you'll have better data on whether your recovery capacity supports adding a third. Most people find two is enough for significant body composition change. The ones who add a third and see better results are usually the ones who also improved their sleep and managed their work stress better.
Start with two. Do them consistently. Measure the results at 12 weeks.
4. "I started a program but always quit after 3-4 weeks when work gets busy - how do I fix this?"
The program is the problem, not you.
Any fitness program that requires your life to be quiet and predictable in order to function is a program designed for someone with a different life. Software engineers don't have quiet, predictable lives. Sprint cycles, production incidents, deployment weeks, and unexpected scope changes are the actual working environment.
The fix is a program with a built-in disruption protocol.
Normal weeks: two full sessions, 35-40 minutes each, full progressive overload.
Busy weeks: two short sessions, 20-25 minutes each, reduced volume, maintenance focus.
The goal is to keep the habit alive - not to make progress, just not to stop.
The rule is: never miss twice. One missed session is a blip. Two missed sessions is the beginning of a pattern. Three missed sessions and the habit starts to dissolve.
When work gets brutal, the session gets shorter - not cancelled. This one reframe has saved more fitness routines than any program design I've ever seen.
5. "I've been doing cardio for months but not losing belly fat - why?"
Because cardio is not the primary lever for belly fat loss in software engineers.
Here's what's actually driving the belly fat: chronically elevated cortisol from sustained cognitive stress, combined with a caloric surplus that's usually invisible, combined with low protein that fails to protect muscle mass.
Cardio burns calories during the session. It does not address cortisol - in fact, high-intensity cardio adds additional stress to a system that is already chronically stressed, which can make the cortisol problem worse.
Resistance training is a better primary tool for two reasons. First, it builds muscle - and muscle raises your resting metabolic rate, meaning you burn more calories at rest, including during the 10 hours you're sitting at your desk. Second, moderate resistance training has been shown to reduce cortisol over time when combined with adequate recovery. The opposite effect of high-intensity cardio on an already-stressed system.
Keep the cardio if you enjoy it or if it helps with stress. But don't expect it to be the primary driver of belly fat loss. Fix the protein, create a modest caloric deficit through better food defaults, and add two resistance training sessions per week. That combination works. Cardio alone doesn't.
6. "Should I work out in the morning or before work?"
The honest answer: whenever you will actually do it consistently.
The slightly longer answer: mornings have one significant advantage for software engineers. Nothing can cancel them. No meeting runs over. No production incident appears. No cognitive depletion from a full day of work makes the decision harder.
The cognitive depletion point matters more than most people realise. Decision fatigue is real and well-documented. By 7pm, after 10 hours of complex problem-solving, your capacity to override resistance and do something hard has been significantly reduced. Morning training sidesteps this entirely.
But morning training only works if you can actually get up. If you're chronically sleep-deprived and a 6am alarm makes your sleep worse, the morning advantage disappears. Bad sleep undermines every other element of fitness more than workout timing could ever compensate for.
The practical recommendation: try mornings for four weeks. If your sleep isn't significantly disrupted and you can actually do it consistently - mornings. If it's making your sleep worse or it's simply not happening - lunchtime or early evening, with the session kept short enough that cognitive depletion doesn't kill it.
Consistency over timing. Every time.
7. "I know exactly what to do but just don't do it - what's wrong with me?"
Nothing is wrong with you.
This is the most common thing I hear from software engineers, and the framing is almost always wrong. They assume the gap between knowing and doing is a character flaw - a lack of discipline, willpower, or commitment. So they try harder, feel guilty when it doesn't work, and repeat the cycle.
The gap between knowing and doing is not a willpower problem. It's a design problem.
You know how to architect a system so it doesn't rely on a single point of failure. You know how to build checks and automation so quality happens by default. You do not apply this thinking to your fitness.
Instead, you rely on motivation - which is finite, unreliable, and consistently loses to exhaustion and a full calendar.
The fix is environmental design. Training clothes laid out the night before. Workout time blocked in the calendar like a client meeting. A program simple enough to execute under real-life conditions, not just ideal ones. Healthy food defaults that don't require decisions when your decision-making capacity is depleted.
The intelligent person's trap is believing that knowing is enough. It isn't. The system has to make the right behavior the path of least resistance - independent of how you feel that day.
You're not lacking discipline. You're relying on the wrong mechanism.
One More Thing
If any of these questions felt uncomfortably specific - that's because they are.
These aren't hypothetical scenarios. They're the patterns I see in almost every conversation I have with software engineers, tech leads, and founders who are performing at a high level professionally and running a slow, invisible deficit physically.
The good news: every one of these problems has a practical solution. None of them require more time than you have, more willpower than you can generate, or a lifestyle that doesn't match your actual life.
They just require a system that was designed for the life you actually live.
I work 1:1 online with software engineers, developers, tech leads, and founders who are ready to build fitness around their actual life - not a theoretical one. If one of these questions is yours - book a free 30-minute call. No pitch. Just a conversation about what's actually going on and what would fix it.







Comments