Posts

Before OpenTelemetry, distributed tracing was a vendor-specific integration. You chose Jaeger or Zipkin or Datadog, added their SDK, and traced against their API. Switching vendors meant rewriting instrumentation. Adding a library that used a different tracing SDK meant two tracing systems running in parallel. OpenTelemetry solved this with a vendor-neutral API and a pluggable exporter model. The API stays the same; you swap exporters. Most major observability vendors now accept OTel format natively. Here’s what a solid Go integration looks like. ...

The fintech startup adopted Kafka early — we were processing market events at rates that would have overwhelmed any request-response queue. Two years in, with a five-broker cluster handling 200k messages/sec at peak, the operational experience was significantly different from what I’d expected based on the documentation and conference talks. ...

The team I joined was called “platform engineering.” The mandate was loosely: make other engineering teams faster. The first three months were spent understanding what “faster” meant, which was more contentious than expected. ...

Every engineering team has a roadmap. Most engineering roadmaps are wrong. Not in a surprising way — in a predictable way that reflects structural problems in how they’re created. After doing roadmap planning at two companies at different scales, here’s what I think actually works and why most roadmaps fail. ...

Go’s lack of inheritance is deliberate. The Go designers observed that inheritance hierarchies tend to create tight coupling and fragile base classes — problems that composition avoids. Embedding is Go’s tool for composition: you can embed one type in another and promote its methods, without inheritance’s downsides. It’s more powerful and more subtle than it appears. ...

A service that calls a database, calls another service, or writes to a message queue will eventually encounter a failure. The question is not whether — it’s whether your service handles failures gracefully or cascades them into a larger outage. These patterns are well-documented in the resilience literature. What this post focuses on is the specific Go implementation and the traps that make naive implementations incorrect. ...

The term “technical debt” was coined by Ward Cunningham specifically as a financial metaphor. Debt isn’t inherently bad — it’s a tradeoff: you get something now in exchange for a future obligation. When the metaphor is understood, the management of technical debt becomes clearer. When the moral framing replaces the financial one, it becomes a guilt-driven cycle that helps nobody. ...

Over two years running engineering hiring at the firm, we made about twenty senior engineering hires. Some were transformative — engineers who raised the quality of everything they touched. Some were neutral — competent contributors who did what was asked and not much more. A few were net negatives. Looking back, the correlation between interview performance and outcome was weaker than I’d expected. The things that predicted good hires were visible in the interview, but we weren’t consistently measuring them. ...

Go 1.18 was still months away when the design was finalised, but the proposal was public and we were already prototyping. After building several services at the European fintech firm with the experimental toolchain, the pattern of when generics help versus when they don’t was becoming clear. The answer is not “always use generics” or “avoid them.” It’s more specific than that. ...

The startup had been good. We’d grown from twelve people to forty, shipped something real, and the technical foundations were solid. But the Series B had brought in a new leadership layer, the founding team’s velocity calculus had changed, and I found myself doing more coordination than building. I’d been at this inflection point before — at the institution, actually — and I recognised what came next. The new role was at a well-established European financial technology firm. Structured, profitable, engineering-first culture, around 400 people. Not a startup. Deliberately not a startup. ...