Engineering

For most of my career I built the plumbing of finance from the engineering side — feed handlers, order books, low-latency messaging, the systems that carry trading decisions without ever making them. I knew the microstructure cold and the strategy not at all. That division of labour is normal and mostly correct: the quant researches the signal, the engineer builds the system that executes it at scale. I’m starting a series of side projects that deliberately cross that line. Not to become a quant — I have no illusions about competing with people who do this full-time with better data and better maths. The goal is narrower and more interesting to me: what does market-data analysis look like when a software engineer does it? What does the engineering discipline I’ve spent fourteen years accumulating buy you when you point it at financial time series in Python? This first post is about the part nobody writes about because it isn’t exciting: the research foundation. Get this wrong and everything built on top is sand. ...

log/slog shipped in Go 1.21 in August 2023. It’s now been in the standard library for two years, and most production Go services I encounter are still on zap or zerolog. That’s not inertia — it’s a reasonable position. The third-party loggers are battle-tested and fast, and “the standard library now has one too” is not by itself a reason to migrate a working system. We migrated one of our services anyway. This post is about why, what the migration actually involved, and the honest accounting of what we gained and what we gave up. ...

Sometime in early 2025, “prompt engineering” stopped being the term people used and “context engineering” took its place. Like most renamings in this field, it was half marketing and half a genuine shift in what the work actually is. The marketing half is noise. The genuine half is worth understanding, because it names a real engineering problem that I spend a meaningful fraction of my time on. This post is about the real part: what context engineering is when you treat it as engineering rather than as a LinkedIn phrase. ...

Go 1.23 stabilised range over function iterators, a feature that had been in the rangefunc experiment since 1.22. It’s the most significant addition to the range statement since channels were added. The reaction has been mixed: people who needed it find it elegant; people who didn’t need it find it confusing. Both reactions are reasonable. Here’s what it actually does and where it belongs. ...

I’ve been writing software since 2012. The introduction of capable AI coding assistants in 2022–2023 is the largest change in the texture of day-to-day development work I’ve experienced. Not because it writes code for me — it mostly doesn’t — but because it changes the cost structure of certain tasks in ways that compound. This post is about where I actually find leverage, and where the tool gets in the way. ...

I’ve been using AI coding assistants heavily since 2023 — first Copilot, then Claude, then a combination. At this point, not having them feels like losing a limb. But the way I use them now is different from how I started, and the difference is mostly about understanding what these tools are good at and building habits that work with their strengths. ...

At the large US technology company, no single team controls the entire system. A feature that touches payments, identity, and platform teams requires coordination across three codebases, three on-call rotations, and three sets of priorities. Getting technical alignment across teams without creating bureaucratic overhead is an active engineering problem. ...

At the large US technology company, RFCs circulate widely. A proposal touching platform infrastructure might be read by engineering leadership, a dozen affected teams, security review, and a product counterpart — none of whom share the same technical context. Writing for a narrow expert audience is one skill. Writing for a wide, mixed audience is a different one. ...

I started writing code professionally in 2012. This year marks eleven years. The milestone prompts a kind of stock-taking that I find useful to do in writing. This is not a career advice post. It’s a personal retrospective on what happened, what I learned, and what I’d change — useful mostly as a data point rather than a prescription. ...

In the years at the European financial technology firm, the engineering organisation went through three significant restructuring events: a change in engineering leadership, a shift from functional to product-aligned teams, and a consolidation of two separate engineering groups. Each one produced the same kind of disruption and the same kind of opportunities. Org change is uncomfortable. It’s also underanalysed. Most engineers treat it as something happening to them, not something to navigate actively. ...