Atharva Pandey Gopherine

A team I worked with had seventeen microservices. Each service had its own implementation of retry logic, circuit breaking, timeout handling, and mutual TLS. Some used libraries, some rolled their own. When we needed to update the TLS certificate rotation policy, it touched eleven different code repositories, four different languages, and took two months. Then we introduced Linkerd and moved all of that to the infrastructure layer. The services still did their jobs. The networking became someone else’s problem — specifically, the platform team’s.

Three years ago, I debugged a payment processing system where an order could go from “refunded” back to “shipped.” Nobody intended for that to happen. The state machine was implemented with a status string and a bunch of if/else checks scattered across eight files. One developer added a shortcut. Review missed it. Customers got refund emails followed by shipping confirmations.

If the state machine had been in the type system, that shortcut wouldn’t have compiled.

There is a saying in machine learning that is so universally acknowledged it has become a cliché: 80% of the work in any ML project is feature engineering. I spent a long time thinking this referred to the cognitive labor — the domain expertise required to craft meaningful features. It does, in part. But the deeper meaning is operational. The 80% is not just about what features to build; it’s about how to compute them consistently, store them efficiently, retrieve them with sub-millisecond latency at serving time, and keep them synchronized between the training pipeline and the production system.

Dynamic programming has an intimidating reputation. The name sounds academic, the problems in textbooks often involve sequences and matrices, and the “aha moment” is notoriously hard to force. I spent a long time treating DP as an interview preparation topic rather than a tool I would actually use. That changed when I built a pricing engine and realized I had been reimplementing DP badly — without knowing it — by computing the same values over and over in nested function calls.

Unit tests feel productive. You write a function, you write a test, everything goes green, and you merge. But unit tests exist in a bubble — a bubble where every dependency returns exactly what you told it to return. The real world doesn’t do that. Your database serializes a time.Time differently than you expect. Your HTTP client follows a redirect your mock never mentioned. Your message queue drops a message under backpressure that your fake queue cheerfully delivered. I’ve had unit test suites where every test passed and the feature didn’t work in staging. Integration tests are what close that gap.

The worst bug I ever shipped came from a status field that was a string. It could be “active”, “Active”, “ACTIVE”, “active “, or — my personal favorite — “acitve”. Six months of data with a typo nobody caught because strings don’t have a compiler checking them.

Rust enums would have made that bug impossible.

The Problem With Primitive Obsession

In most languages, developers reach for strings, integers, and booleans to represent domain concepts. A user’s role is a string. An order status is an integer. A payment method is… also a string. This is called “primitive obsession” and it’s responsible for an entire category of bugs:

When Claude or another AI assistant needs to look up a database record, call an internal API, or read a file from your filesystem, it can’t do that on its own — it needs tools. The Model Context Protocol (MCP) is Anthropic’s open standard for giving AI agents exactly those tools. An MCP server is a small program you write that exposes tools via a JSON-RPC protocol; the AI client calls your server to invoke them. I find this genuinely exciting as a Go developer: Go’s concurrency model and fast startup time make it a natural fit for MCP servers.

I spent the first two years of my career using Docker without understanding what it was actually doing. I thought containers were a “lightweight VM” — some kind of virtualization. Then I read Liz Rice’s “Containers from Scratch” talk and wrote a 100-line container runtime in Go. Containers are not virtual machines. They are just Linux processes with restricted views of the system, implemented using two kernel features: namespaces and cgroups. Once you see how simple the underlying mechanism is, you understand exactly what Docker adds and why containers behave the way they do.

I shipped a Rust service to production once with great error types, proper Result propagation, context chains — the whole nine yards. And then I couldn’t debug anything because every error got logged as a single flat string with no request ID, no trace correlation, and no distinction between “user sent bad input” and “our database is on fire.” Having good error types is half the battle. The other half is what you do with those errors when they reach the top of your stack.

The first metrics dashboard I built for a Go service had forty-two graphs. CPU, memory, goroutine count, heap allocations, GC pause duration, request rate, error rate, and about thirty-five other things that felt important when I added them. Six months later I was on call at 3 AM and the service was degraded. I opened that dashboard, looked at forty-two graphs, and had no idea where to start.

Metrics are only useful when you know what to alert on, and you can only alert on things you understand. More metrics is not the same as better observability. The question is not “what can I measure?” but “what breaks, how do I know it’s broken, and how quickly can I narrow down why?”