Engineering

The standard startup narrative is that small teams move fast because they cut process. No PRD approval chains, no design committee sign-off, no six-week delivery timelines. Just engineers and a product idea, shipping. That narrative is true as far as it goes, and incomplete in important ways. The startup I joined from 2019 to 2021 was fast for reasons that went beyond “we skipped the bureaucracy.” Understanding those reasons changed how I think about engineering productivity in any context. ...

Go had resisted generics for years. The arguments against were practical: generics complicate the language, they interact badly with Go’s interface system, and most cases where you want generics can be handled with interface composition or code generation. The arguments weren’t wrong. But the proposal that eventually shipped in Go 1.18 (2022) addressed a real gap — a gap that was producing either duplicated code or interface{} with runtime type assertions everywhere. Here’s what the proposal was solving. ...

The fintech startup hit the platform question about eighteen months in. We had product-market fit, we were growing, and the engineering team was doubling every six months. The systems that had worked at ten engineers were showing strain at twenty-five. The question became: dedicate engineering time to platform work, or keep all capacity on product features? This is a hard question. The people who get it right aren’t smarter — they’re clearer about what they’re actually trading off. ...

I was promoted to tech lead at the startup in early 2020. The team was five engineers, including me. My previous experience managing people: none, unless you count mentoring a couple of interns. The first month was humbling. The second month was better. By the third month I had a clearer mental model of what the role actually required and how it differed from what I’d been doing before. ...

Go modules are one of the more carefully designed dependency management systems I’ve worked with. The core ideas — versioned module paths, minimum version selection, reproducible builds via go.sum — are sound. After running services on modules since 1.11, the rough edges are predictable enough to document. ...

When I started writing Go after years of Java, the error handling felt tedious. Every function returns an error. Every callsite checks if err != nil. There’s no try/catch, no exception hierarchy, no automatic stack traces. The verbosity was jarring. A year into building services at the fintech startup, I’d changed my view. The verbosity is real and the boilerplate is real, but the explicitness surfaces things that exception-based languages hide. The question is how to handle errors well rather than just correctly. ...

Three months into the startup, the prototype was working and investors were asking for a production timeline. We had a Postgres database, a Python script doing the core business logic, and no infrastructure to speak of. The decision: rewrite in Go, build proper infrastructure, or ship the Python and iterate? And if we rewrite, what does “proper infrastructure” mean when you have six engineers and four months of runway? ...

I had written maybe 500 lines of Go before the new role. Within two months it was my primary language. This is the honest transition account — not a “Go vs Java” opinion piece, but what the practical experience of switching felt like. ...

I joined the large financial institution expecting to find bureaucracy that slowed down engineering. I did find that. I also found something I didn’t expect: certain constraints imposed by regulation, scale, and risk aversion produced genuinely better engineering decisions than I’d been making at the smaller trading firm. This is about the non-obvious lessons. ...

Two years. Long enough that the novelty is gone and what’s left is the actual experience of living with the decision. Here’s the retrospective I’d want to have read before starting. ...