Ten years of backend Java: what actually mattered

Ten years ago I started my first job writing Java for internal business tools. I didn't think much about architecture, testing, or on-call rotations — I just wanted my code to compile and my manager to be happy. A decade later, having shipped everything from enterprise integration systems to payment infrastructure, a short list of things has mattered far more than I expected.

Boring technology wins more often than it should

Almost every serious production incident I've been part of traced back to something clever — a custom caching layer, a hand-rolled retry mechanism, a "temporary" workaround that stayed for three years. The systems that gave me the fewest 3am pages were the ones built from well-understood, boring pieces: Spring Boot, PostgreSQL, Kafka, and code that did the obvious thing.

Reading code is a bigger skill than writing it

Most of my job, especially in the last five years, has been reading code someone else wrote — sometimes six months ago, sometimes six years ago. Getting fast at understanding unfamiliar codebases, tracing a bug through five services, and figuring out why a system behaves the way it does has been worth more than knowing the latest framework.

The database schema outlives the code

I've rewritten services from scratch more than once. I have never gotten to rewrite a database schema without a very long, very careful migration plan. If I could give my younger self one piece of advice, it would be to spend twice as much time thinking about data models as feels necessary.

Singapore changed how I think about scale

Working here, in a hub that serves traffic across multiple time zones and currencies, forced me to take "what happens during a regional outage" seriously in a way I hadn't before. It's one thing to design for scale in theory. It's another to be paged during a real one.

Ten years in, I still enjoy this work as much as I did in year one — maybe more, now that I understand what I'm actually optimizing for.