Six Months of Building in Public: What 30,000 Lines of C++ Taught Me About Engineering Judgment
Reflections from a year of shipping radar pipelines, lock-free queues, Kalman trackers and a hackathon-winning health app. The opinions I changed, the heuristics I now reach for, and what I would tell my year-one self.
A year ago I was writing my first non-trivial C++ program. This week I shipped the Kalman tracker on top of the radar pipeline, which puts the total at roughly thirty thousand lines across half a dozen projects. The code is the boring part of what I learned. The interesting part is how my taste changed.
Benchmarks beat opinions
Every strong claim I have made about code performance, since the SPSC ring buffer in May, has been wrong at least once. The cache-padding article had three drafts before I shipped it because my first numbers were measuring the wrong thing. The CFAR pipeline's 50,000 fps was not the figure I expected before I measured.
The reflex I have built: any time I am about to say 'this should be faster' or 'this will be a bottleneck', I write the benchmark first. Half the time the bottleneck is somewhere I would never have guessed.
Write the slow version first
Every project that worked started with the dumbest possible implementation. Mutex queue before lock-free queue. Canvas 2D before WebGL. nlohmann/json before hand-rolled serialisation. Once the slow version was correct end-to-end, the optimised version became a constrained problem: same outputs, faster path.
The two projects I tried to optimise from line one took longer to ship and have not yet been thrown away by me, which is the real test.
Tests are not the point; reproducibility is
I do not write tests for every function. I write tests for the things that broke once before, the things that have a clear pass/fail and that I would otherwise be re-running in my head, and the things that are sufficiently subtle (the CA-CFAR false alarm rate at Pfa = 1e-4) that I do not trust my intuition.
What I always have is a way to reproduce a result with one command. `make bench` runs the SPSC throughput numbers. `make run-server` boots the radar dashboard end to end. If I cannot reproduce a behaviour in one shell command, that is the bug to fix first, before any code change.
Choose your language standard like an adult
I picked C++17 over C++20 for every project this year. The reason was never that C++20 was bad. It was that the toolchains I might one day target (RHEL 8, MinGW 9, AUTOSAR-qualified compilers) have patchy C++20 support, and the C++20 features I actually wanted (concepts, std::format, ranges) had drop-in C++17 equivalents (SFINAE, fmtlib, range-v3) that cost an evening to set up.
The general principle: pick the oldest standard that lets you write the code well, not the newest one that compiles.
Reading code is the senior skill
I spent a week in October reading the FFTW source. Another week reading Eigen's Cholesky decomposition. Another reading the Linux io_uring code. None of these produced a line of code in my own projects directly, and all of them changed how I write code.
The pattern I noticed: every library I admire has a single small interface and an implementation that is allowed to be much larger and stranger. The discipline is at the boundary, not at the bottom. I now spend more time on the public header of a class than on its `.cpp`.
The unreasonable effectiveness of writing it down
The six articles I wrote this year forced me to understand my own code at a level I would not have reached by just shipping it. The CFAR write-up made me realise I had no test for the Pfa rate; I added it, and the test caught a bug in the alpha calculation a week later. The Kalman write-up forced me to articulate why I chose nearest-neighbour gating, which made the eventual upgrade to JPDA an obvious next step instead of a vague intention.
Writing is debugging applied to thoughts. Highly recommended.
What I would tell year-one me
Pick one language and get deep before you go wide. I am two years in and still finding C++ features that change how I write functions.
Build the boring thing. Lock-free queues, Kalman filters, JSON parsers — implementing a 'solved' problem teaches you what the solution actually is, in a way reading the abstract never will.
Measure before you opinionate. Almost every confident claim about software performance is a memory of a benchmark that was true on someone else's hardware in 2014.
Ship the dashboard. Half the engineering value of the radar pipeline is that you can see it work in a browser. Demos are not vanity; they are the test harness humans actually trust.
Read more code than you write. The ratio that worked for me this year was about 3:1.
What is next
Multi-hypothesis tracking on top of the Kalman work; a hardware port of the CFAR pipeline to an STM32H7 over the summer; and, if I am honest, more writing. The compounding I have seen from these six articles has been greater than from any single project.
Engineering judgment is just the accumulated memory of every time the obvious answer was wrong. The fastest way to accumulate it is to ship things, measure them, and write down what you found.