From Software Engineer to Fitness Coach: The System Behind My Coaching Approach

People are usually surprised when the engineering background comes up. It sounds like an unrelated previous life.

It is the opposite. The way I coach — the questions I ask first, the refusal to change nine things at once, the insistence on measuring — comes directly from years of building software. The problems turned out to be far more similar than I expected.

Why This Happens

Before this I was a software engineer, and then I founded and ran a gaming studio and software company, building games and mobile apps.

That work teaches a specific discipline: you cannot fix what you have not measured, and you cannot measure what you have not defined. A bug report saying "the app feels slow" is useless. Slow where, under what conditions, compared to what? The first job is always converting a vague complaint into something specific enough to act on.

When I moved into fitness, I kept hearing the same shape of problem. "I'm eating healthy and nothing is happening." "I train hard but I don't look different." These are the fitness version of the app feels slow — real frustrations, stated in a form nobody can act on.

The instinct I brought was not to prescribe. It was to ask what "eating healthy" actually meant this week, in numbers.

What Most People Get Wrong

Treating fitness as a knowledge problem. Most people who are stuck do not lack information — they have consumed a great deal of it. What they lack is a system that survives a bad week. More reading does not fix that, and it feels productive enough to delay the thing that would.

Blaming the person when the design failed. In engineering, a system that fails under normal load is a design fault, not a user fault. In fitness, the same failure gets attributed to weak willpower. Almost every plan I have seen collapse was a plan that never accounted for the person's actual schedule, household, or budget.

Changing everything simultaneously. New diet, new programme, new sleep schedule, all from Monday. In software that is a big-bang rewrite, and it fails the same way: too many variables moved at once, so when it breaks you cannot tell which change was wrong.

Optimising the interesting parts. People will debate rep ranges and supplement timing while sleeping five hours and not tracking protein. The unglamorous fundamentals carry the result.

A plan that only works when you are motivated is not a plan. It is a hope with a schedule attached.

The Fix: What This Looks Like in Practice

I ask what broke last time, first

The most useful question in any intake is not what you want to weigh. It is what made your last attempt stop.

If three previous plans died because breakfast was unrealistic before a 7am commute, then a plan requiring breakfast will die too. That constraint is more important than any nutritional detail, and it is the sort of thing that only surfaces if you ask.

I design for the worst week

Not the week where you are rested and cooking from scratch. The week with travel, a deadline, a wedding, and a sick child.

If a plan survives that week, it survives everything. In practice this means three training sessions rather than six, and a protein target you can hit while eating out.

I change one variable at a time

Month one: protein. Month two: training. Month three: sleep or steps.

It feels slow, and it is substantially more effective — because when something stalls, only one thing moved, so you know exactly what to inspect.

I insist on measurement

Weight, waist, steps, and a training log. Four numbers, under a minute a day.

This is the difference between "it stopped working" and "your step count fell by 4,000 and your maintenance dropped after 8 kg." One of those is a mystery. The other is a fix. The five checks I run on any stall come straight from this.

I plan for failure explicitly

Systems fail; good ones fail gracefully. So every plan I write specifies what happens when you miss a session or eat past your target: return at the very next meal or the next scheduled session.

Deciding that in advance, while calm, is worth more than any amount of willpower at 10pm.

What This Does Not Mean

It would be easy to read all this as treating people like software. It is not that, and the difference matters.

Software does what you tell it. People have families, tastes, jobs, and bad days, and a plan that ignores those is worse than no plan. The engineering discipline is useful for structure — measure, isolate variables, design for constraints. It says nothing about which foods someone enjoys or why they stopped training in March.

That part is coaching, and it is learned by working with people rather than by building products.

The honest version is this: my background gave me a way of breaking problems apart. The certification and the years of coaching gave me the domain. Neither alone would be enough.

One more thing the engineering years gave me, which I did not expect to matter: comfort with being wrong in public.

In software you ship something, watch it fail in a way you did not predict, and correct it. There is no version where the first estimate is perfect. Coaching works identically — the plan I write on day one is my best guess given what I know, and the following weeks are how we discover where I was off.

I say that to clients explicitly, because the alternative is worse. A coach who cannot revise their own plan will quietly blame the client instead.

If you are stuck and cannot tell whether your problem is the plan or the execution, these five questions usually settle it — and a fair number of people find their answer there without needing me at all.