Why "Eat Less, Move More" Advice Fails Most People (An Engineer's Take on Systems That Actually Work)

Someone tells you to eat less and move more. You already knew that. You have known it for years, which is precisely why hearing it again does not help.

I spent years as a software engineer before this, building products and running a studio. The pattern is familiar: a requirement stated correctly, handed over with no design, and then blamed on the person who failed to deliver it.

"Eat less, move more" is a requirement. It is not a system. And requirements without systems fail, in software and in fitness, for the same reasons.

Why This Happens

The advice is true. Energy balance decides body weight, and eating less while moving more does produce fat loss. Nobody serious disputes this.

The trouble is that it describes an outcome, not a mechanism. It is the equivalent of telling a team "make the app fast." Accurate, agreed by everyone, and completely unactionable. Fast how? Which screen? Measured against what? Traded off against which other work?

Faced with an outcome and no mechanism, people improvise. They eat less in the way that feels most obvious — skipping meals, cutting hard, removing whole categories of food — and move more by adding punishing amounts of cardio to an already tired week.

That configuration fails predictably. Not because the person is weak, but because nobody designed for the constraints: their schedule, their household, their food environment, their recovery capacity. A design that ignores its constraints does not survive contact with reality, whatever domain it is in.

What Most People Get Wrong

Treating failure as a character verdict. When a plan collapses, almost everyone concludes they lack discipline. In engineering, a system that fails under normal load is not blamed on the users — it is a design fault. Most diet failures are the same: normal load, inadequate design.

Optimising motivation instead of structure. Motivation is not a system input you can rely on; it fluctuates with sleep, stress, and work. Anything that only functions while motivation is high will fail in the second month by definition.

Changing everything at once. New diet, new gym routine, 5am wake-up, no sugar — all from Monday. In software this is a big-bang rewrite, and it fails for the same reason: too many variables changed simultaneously, so when it breaks you cannot tell which part was wrong.

No measurement. "Eating better" is not measurable, so it cannot be debugged. When progress stalls you have no data, only impressions, and impressions are how people conclude their metabolism is broken.

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

The Fix: Design It Like a System

1. Define the requirement in numbers

Not "lose weight." "Lose 6 kg in 16 weeks, at roughly 0.4 kg per week."

Now it is testable. Sixteen weeks from now you either hit it or you did not, and you will know within a fortnight whether you are on track. Work out the calorie target that produces it — that is your specification.

2. Design for the worst week, not the best one

This is the single most useful principle to import.

Do not build a plan around a week where you are rested, free, and cooking every meal. Build it around your worst realistic week — travel, deadlines, guests, a sick child. If the plan survives that week, it survives everything.

In practice this means: three training sessions, not six. A protein target you can hit while eating out. A diet with no ingredient you cannot buy locally.

3. Change one variable at a time

Month one: hit your protein target. Nothing else. Month two: add three training sessions. Month three: address sleep or step count.

This feels slow, and it is dramatically more effective than nine simultaneous changes. When something stalls you know exactly which variable to inspect, because only one moved.

4. Instrument it

You cannot debug what you do not measure. The minimum:

• Weight, daily, judged on weekly averages
• Waist, fortnightly
• Training log — exercise, weight, sets, reps
• Steps, daily

Four numbers, under a minute a day. This is the difference between "it stopped working" and "my step count fell by 4,000 and my maintenance dropped after 8 kg."

5. Expect and design for failure

Systems fail. Good systems fail gracefully.

Decide now what happens when you miss a session or eat past your target — not in the moment, when you are tired and inclined to abandon everything. The rule that works: return at the very next meal or the next scheduled session. Not tomorrow, not Monday.

That one rule is worth more than any amount of willpower, because it converts a failure into a rounding error rather than the end of the attempt.

The Part Advice Cannot Give You

Everything above is a framework. What it does not tell you is which variable is actually wrong in your case — and that is usually one or two specific things, not the whole plan.

That is what a session is for. An hour spent identifying which constraint is binding is worth more than another six weeks of guessing, and most people are surprised by how narrow the actual problem is once someone looks at the whole picture.

This week, do one thing: write down your requirement as a number and a date. Not "get in shape." A weight, a waist measurement, and a deadline. Everything else is designed backwards from that.