Why Engineers Lose Money

There is a specific way that software engineers fail at trading, and it is different from how everyone else fails.

Most retail traders fail from lack of discipline. They have no system, they trade on feeling, they average down into losses, they take profits early and losses late. The literature on this is voluminous and depressing, and it does not describe you. You are going to build a system. You are going to backtest it. You are going to follow it.

You will still probably lose money, and the reasons are the subject of this book.

The competence transfer illusion

Being good at engineering feels like it should transfer to trading. Both involve building systems, reasoning about data, and being rigorous where other people are sloppy. And it does transfer - partially. That partial transfer is the trap, because it produces exactly enough competence to build something that looks right and fails anyway.

Here is the honest accounting.

What transfers well:

• Systematic thinking. You will define rules precisely rather than gesturing at "when it looks strong."
• Version control and reproducibility. You will not lose track of which configuration produced which result. Most traders do.
• Testing instincts. You already believe that untested code is broken code.
• Automation. You can run a thousand experiments while someone else runs three.
• Statistical literacy, or at least the ability to acquire it quickly.
• No ego about being wrong. You've had code review. You've been wrong in public.

That is a genuinely strong hand.

What does not transfer, and this is the entire problem:

Determinism. Your systems have defined behaviour. Given the same inputs, you get the same outputs, and when you don't, that's a bug with a root cause you can find. Markets have no such property. The same setup produces a profit today and a loss tomorrow, and there is no bug. There is only distribution. You will spend your first year looking for the root cause of losing trades, and there isn't one, and looking for it will make you worse.

A specification. Every system you've built had a definition of correct. Trading has no spec. There is no oracle that tells you whether your strategy is right - only a noisy, delayed, low-sample-size signal that is also consistent with your strategy being worthless.

A non-adversarial environment. Your database does not attempt to defeat your query planner. Your compiler is not trying to take your money. In markets, every participant is actively working to identify and neutralise patterns like the one you found. If your edge is easy to find, it has been found, and the people who found it are removing it.

Stationarity. You can profile a system and optimise against the profile because the workload has stable characteristics. Markets do not. The behaviour you measured in 2019 may not exist in 2026, and - critically - your own trading changes the thing you're measuring if you get large enough. Imagine writing a cache eviction policy where the request pattern adapts specifically to defeat whatever policy you choose. That's the job.

The four engineer-specific failure modes

1. Treating the backtest like a test suite.

This is the big one. Your tests pass, therefore your code is correct - that's a reasonable inference in software, because your tests are a specification you wrote and the system is deterministic.

A backtest is not that. A backtest is an integration test against a mock that systematically lies in your favour. It assumes you got filled at prices you might not have got. It assumes the historical data is what you'd have seen live, when in fact it's been revised, adjusted, and survivorship-filtered. It assumes your orders had no market impact. Worst of all, it lets you run the test, look at the result, change the code, and run it again - which in software is called iterating and in statistics is called fitting your model to your test set.

Green does not mean correct. Green means "I have not yet found the way this is wrong."

2. Over-engineering.

Your instinct when a system underperforms is to add capability. A filter for choppy markets. A volatility regime detector. A machine learning layer for entry timing. Each addition improves your backtest - of course it does, you're adding parameters and selecting the ones that fit the history you already looked at.

In trading, every feature you add is a degree of freedom, and every degree of freedom is a withdrawal from a limited account of credibility. The correct instinct is the opposite of the engineering one: your goal is the smallest system that still shows an edge. Simplicity is not aesthetic preference here. It's statistical necessity.

3. Assuming a found pattern is an exploitable edge.

You will find patterns. There are thousands of them in any price series, and most are noise. The question that separates a strategy from a curve-fit is not "does this pattern exist in the data" but "why does this pattern exist, who is on the other side of it, and why haven't they stopped?"

If you cannot answer that in a sentence, you have found a coincidence. Real edges have mechanisms: someone is structurally forced to trade at a bad price (index rebalancing, margin liquidation, fund redemptions), or someone is being paid to absorb a risk nobody wants (volatility selling, carry), or a behavioural bias is being systematically exploited (disposition effect, anchoring). Mechanism first, backtest second.

4. Believing that more sophistication implies more edge.

You can build things most retail traders cannot. This produces the intuition that you should. But sophistication competes with the wrong people: the moment your strategy depends on technical sophistication, you're competing against firms with better data, lower latency, cheaper capital, and full-time PhDs. You will lose that fight.

The retail advantage is never sophistication. It's the constraints you don't have.

The base rates

Before you commit time to this, know what the population statistics look like. These are well-established findings, and worth reading in full rather than taking from me:

• Barber and Odean's work on retail brokerage accounts found that the most active traders substantially underperformed the market after costs - the trading itself was the source of the underperformance.
• A study of Taiwanese day traders (Barber, Lee, Liu, Odean) found that a very small fraction - on the order of 1% - were consistently profitable net of fees.
• A study of Brazilian equity-futures day traders (Chague, De-Losso, Giovannetti) found roughly 3% made money at all, and around 1% earned more than the Brazilian minimum wage for their effort.
• CFD brokers in the EU and UK are required to disclose the percentage of retail accounts that lose money. The published figures generally sit somewhere in the 70-85% range depending on the broker.

Check current numbers yourself; the point is the order of magnitude, and it has been stable for decades. This is a domain where the median participant loses, and where being smart is table stakes rather than an advantage - the person on the other side of your trade may well have a doctorate and a colocated server.

None of this is a reason not to proceed. It is a reason to proceed with an accurate model of what you're doing, which is attempting to be an outlier in a field where the base rate is failure. Size your expectations, and your capital, accordingly.

Where the retail engineer genuinely has an edge

It isn't your code. It's your constraints - specifically, the ones you don't have:

Capacity. A fund managing $500m cannot trade a strategy with $2m of capacity; the position wouldn't move their returns and would move the market. You can. Small capacity is the single largest structural advantage available to retail, and it is the reason any edge survives at all - the profitable niches are the ones too small for professionals to bother with.

No mandate. You are not required to be invested. You can sit in cash for eight months. A fund manager who does that gets redeemed.

No benchmark. You don't have to track an index or explain a quarter of underperformance to anyone.

No career risk. The professional's worst outcome is not losing money, it's losing money differently from everyone else. This distorts their behaviour in ways you can exploit.

No redemption risk. Nobody can pull your capital at the worst moment. You get to survive drawdowns that would end a fund.

Time. You have a salary. You do not need this to work this year.

Every one of these is a real advantage, and none of them requires you to write better code than a quant fund. Your strategy should be built to exploit these, not to out-engineer people who engineer for a living.

What this book assumes

You can write code. You are comfortable with the idea that you might be wrong. You have money you can afford to lose entirely, and you understand that phrase literally. And you are willing to spend considerably more time validating a strategy than building one - probably a ratio of five to one.

I should say plainly: I'm not a financial adviser, nothing here is advice about what you should do with your money, and the entire field has excellent reasons for its reputation. What this book offers is a methodology for thinking rigorously about systematic trading. Whether you should trade at all is a question only you can answer, and the base rates above should weigh heavily in it.