Reading Charts After a Decade of Reading Code: How Engineering Discipline Shapes My Trading
"After enough years of debugging embedded firmware, you stop believing in things that 'usually work.' Trading has the same shape — the thing that usually works is exactly the thing that gets you wiped out on the day it does not."
The name of this blog is not accidental. I have spent fifteen years writing code for embedded systems in the automotive and defense industries, and about ten years trading Korean equities, US options, MNQ futures, and crypto. The two disciplines share more mental architecture than most trading writing gives them credit for — and, importantly, the places they diverge are where I have made most of my worst mistakes.
This post is not "engineering makes you a better trader." I have watched too many brilliant engineers lose accounts, and I have watched too many non-engineers trade beautifully, to make that claim. What is honest is narrower: certain specific engineering habits transfer directly into trading skill, and certain others actively hurt performance. This is my attempt to name both, based on what has actually shown up in my own P&L.
📋 What we will look at
- Debugging and post-mortem — the identical shape
- Testing and backtesting — the important difference
- Documentation and journaling — why a git-log style beats a diary
- Where engineering discipline actively hurts trading
- What actually transfers, cleanly
1. Debugging and Post-Mortem — The Identical Shape
🔼 The desk where a race-condition debug session and a chart post-mortem often happen on the same evening, sometimes on the same monitor.
When a device under test fails an integration run, the debugging protocol is not "did we do something wrong." It is: what did the system observably do, what was the expected state at that moment, and what specifically was the delta. The debugging is mechanical, and it does not care about how confident anyone on the team felt about the code an hour ago.
A trade post-mortem has the exact same shape. When a trade loses, the useful question is not "was that a bad trade" — the useful questions are: what were the observable signals at the moment of entry, what specifically did I expect to happen next, and where did the observation diverge from the expectation. I try to write that up within twenty-four hours of the close, before the memory softens into "well, it just didn't work."
The uncomfortable part of this transfer is what it forces you to admit. The engineering post-mortem does not let you say "the code was fine, the environment was hostile." Sometimes the code was fine. More often, if you dig with any rigour, you find a boundary condition you did not handle. Trade post-mortems tend to find the same shape — most trades I initially wrote off as "unlucky" turned out, on the second read, to be trades I should not have taken at that grade of setup. That is not a fun thing to notice about yourself, but it is what the discipline is for.
The rule from this one: the useful post-mortem is the one that finds something the trader would rather not find. If every review concludes "the market was random," the review is doing something other than its job. I wrote about the specific losses this rigour uncovered in Five Painful Lessons.
2. Testing and Backtesting — The Important Difference
Software testing has a beautiful property: if the unit test passes, the code will pass the same test every time you run it. The environment is deterministic. You can hold behaviour in a repeatable box and iterate on it until it behaves exactly as specified.
Backtesting looks like software testing at first — same shape, same tools, similar Python — and this superficial similarity is where the majority of engineer-turned-traders get quietly destroyed. Markets are not deterministic. A backtest that closes out a strategy at +18% CAGR over a five-year window is not a statement that the strategy generates 18% next year. It is a statement that this exact five-year path happened to reward this exact rule set. The map is not the territory, and the historical map is a specific single realisation of the territory that will never happen again in the same order.
I ran into this personally in 2020-2022, documented as Lesson 5 in the recent five-lessons post — a "system" that produced beautiful backtests over a friendly window and then behaved completely differently when the environment changed. The mistake was treating a backtest like a unit test. A backtest is closer to a fuzz test with adversarial inputs I do not control.
The engineering fix that transfers cleanly: forward test. Do not deploy a strategy to a real account based on backtest alone. Run it on live data with paper positions for at least one full market regime cycle (2-3 months minimum for intraday systems). This is exactly what integration testing on real hardware does that unit tests cannot: it exposes the assumptions the code did not know it was making.
3. Documentation and Journaling — Why a Git-Log Style Beats a Diary
🔼 Trades logged the same way commits are logged: timestamped, structured, one-line thesis, one-line outcome. Prose gets vague. Structured logs stay honest.
Most trading journals I have seen — including my early ones — are diaries. Long paragraphs about what the trader was feeling that day, what the market did, what they would do differently. This is the trading equivalent of writing a novel in the git commit message.
The git-log format works for source code precisely because it constrains you to state what changed, not how you felt about the change. A good commit is a one-line imperative summary plus, optionally, a body of the reasoning. Trading logs benefit from the same constraint. My current template is one line per trade, comma-separated, in a plain text file:
2026-07-16T15:07Z MNQ B long 15m CHoCH, no HTF context @ 33020, SL 32990, TP 33110 → FAIL -1.0R
2026-07-17T08:41Z ES B+ short LDN close sweep, weak follow @ 5480, SL 5495, TP 5450 → FAIL -0.8R (early exit)
Three trades, three lines. The reasoning had to fit in five words. If it did not, the trade was too complicated for the framework to size correctly, which is itself signal. Over months, the log stays scannable. Over a year, patterns emerge — most of Lesson 4 in the recent post was visible in the log a year before I noticed it, because I was reading it as a diary rather than as data.
The rule from this section: the log format decides what patterns you can see. Diaries hide patterns behind mood. Git-log formats surface them. I would not trust a codebase without commit history, and I no longer trust a trader without a structured log.
4. Where Engineering Discipline Actively Hurts Trading
The uncomfortable half of this post. The habits above transfer cleanly. The habits below have cost me money precisely because they worked so well in engineering that I trusted them past their domain.
① Over-optimisation on the historical window
In firmware, when a routine passes with 60% timing margin, you tighten it until you get 20% margin, because that is more efficient use of the silicon. In trading, the same instinct produces beautifully optimised strategies that fit the past exactly and generalise to zero future data. Optimisation feels productive because it is productive on the training set. It is quietly destructive on the test set that has not happened yet.
② False precision on inherently noisy variables
Engineering trains you to express things in numbers. Trading rewards knowing when the number is a false-precision performance. A CMF reading of +0.183 versus +0.194 is not a meaningfully different signal — the second decimal place is noise. Treating it as data-worthy is engineering habit misfiring. The useful move is often to express the signal in fewer bits, not more.
③ Waiting for the perfect signal
Good engineering habits include "do not ship if the spec is incomplete." Good trading habits include "take the setup that meets the pre-defined bar." The engineering brain wants to add one more filter, one more confirmation, one more test — and it is right up until the moment the setup exits the market entirely while you were adding the filter. This is a real cost. I have missed clean A-grade setups from my own Volume Framework because I was still verifying the fifth layer while the third layer that already confirmed was executing without me.
The pattern under all three: engineering optimises for correctness in a bounded, controllable system. Markets are neither bounded nor controllable. Techniques that were adaptive in the first domain become maladaptive in the second, and the trader who trusts engineering instinct blindly ends up smart-in-a-vacuum and wrong-in-real-time.
5. What Actually Transfers, Cleanly
Stripping out both the successful transfers and the misfires, the shortlist of engineering habits that have paid for themselves in trading:
- Version control everything — including your strategy rules. If you cannot show me the rule set as it existed six months ago, you cannot honestly evaluate whether it changed.
- Fail fast — take the small loss when the thesis invalidates. Do not hold a broken thesis to see if the market changes its mind.
- Structured logging over prose — as described above.
- Pre-mortems, not just post-mortems — before opening the trade, write one line: "the way this loses is ___." If you cannot fill it in, the risk assessment is incomplete.
- Assume adversarial inputs — the market is not trying to make your strategy work. Design for the case where every convenience assumption breaks. This is the engineering habit that has kept my sizing framework robust, as documented in The Position Sizing Framework.
What does not transfer, or transfers with heavy modification:
- Optimising every parameter until it is tight (destructive — as discussed above).
- Preferring precision over clarity (destructive — noise gets amplified).
- Treating specification as ground truth (destructive — the spec here is the trader's opinion of the market, not the market itself).
- Waiting for zero uncertainty (destructive — zero uncertainty means the move already happened).
The honest summary, after ten years of trading and fifteen years of coding side-by-side, is that engineering discipline is necessary but not sufficient. The habits that transfer make the trader more consistent. The habits that misfire, if left unexamined, make the trader confidently wrong. Knowing the difference is the actual skill the two decades taught me — not any specific technique from either domain.
A Note on Why I Am Publishing This
I have been asked variations of "does your engineering background give you an edge in markets" for years, mostly by other engineers considering whether to trade seriously. The honest answer has always been complicated, and I did not think it was worth writing until I could name the specific habits on both sides.
Nothing in this post generalises automatically. A different engineering background — mechanical, civil, biotech — probably transfers differently. A different trading style — buy-and-hold, options premium selling, market making — would emphasise different habits. What I have written is one specific mapping between one specific engineering discipline (embedded systems in automotive and defense) and one specific trading style (discretionary systematic on futures and equities). Your mapping will overlap in places and diverge in others. The point is not to adopt my list. The point is to write your own down, honestly, and to keep updating it when the P&L teaches you something new.
Coder Trader as a project exists exactly in this crossroads. If you want the full arc of how the two disciplines converged for me personally, A Decade in the Markets is the long-form piece. Thanks for reading — and see you at the next chart, or the next commit.
📚 Related Reading on This Blog
Where the engineering-trading intersection shows up elsewhere on the blog:
- A Decade in the Markets — the ten-year arc these habits shaped
- Five Painful Lessons — Lesson 5 is exactly the "backtest as unit test" mistake
- Why I Paused Live Trading — the work-exhaustion boundary between the two disciplines
- The Position Sizing Framework — where "assume adversarial inputs" pays off in dollars
- The Institutional Volume Framework — the systematic stack the discipline is applied to
⚠️ Educational Disclaimer
This post is a personal reflection on habits from an engineering career applied to trading. It is not investment advice, financial advice, trading advice, or a claim that engineering skill improves trading outcomes for anyone else.
Trading involves substantial risk of loss and is not suitable for every investor. Habits and mental frameworks that helped me may not help you; some of them, as discussed in Section 4, actively hurt performance if adopted uncritically.
Always do your own research, consult a qualified financial advisor licensed in your jurisdiction, and never risk capital you cannot afford to lose. See our full Disclaimer and Privacy Policy.
About the Author
Dongmin Park is a software engineer with over 15 years in embedded systems (automotive and defense industries) and 10+ years of active trading across Korean equities, US options, MNQ futures, and crypto. He started trading on a Kiwoom Securities account in Seoul in 2016 and now lives in Ingolstadt, Germany, after relocating in 2022.
Coder Trader is an ongoing project to document where systematic engineering discipline meets discretionary trading. Say hi on X, look at the code on GitHub, or email hello@codertrader.com.
Comments
Post a Comment