My Principles
I've arrived at these principles after nearly two decades of being a professional software engineer.
1. Boring Technology Wins
Proven, stable tech beats shiny every time. I've seen fashionable rewrites corrupt six months of billing data. GraphQL layers added to paper over organisational problems. Serverless costs hidden by AWS credits until they weren't. New tech promises elegance but delivers complexity most teams can't sustain. Pick boring.
2. Legacy Systems Aren't the Enemy
Neglect is. Every "big rewrite" I've done could have been avoided with consistent maintenance. Rescue beats replace.
3. The Monolith Is Not Your Biggest Problem
Microservices solve organisational problems, not technical ones. I've seen them deployed most often when teams don't want to talk to each other - so instead of fixing communication, they add network boundaries. Monolith is not a dirty word.
4. Sustainable Software Means Sustainable Teams
Code that can't be maintained by humans at a reasonable pace will eventually fail. Burnout kills more projects than bad architecture.
5. Build for Today, Design for Tomorrow
Most failed systems I've rescued weren't too rigid - they were too "flexible." Abstract frameworks for use cases that never materialised. Solve the problem in front of you. Avoid irreversible decisions. But don't build abstractions you don't need yet.
6. Process Theatre Kills Teams
Teams spend hours debating sprint length and story points while the actual work waits. Endless estimation and planning rituals create disengaged engineers who'd rather be solving problems. Trust the team. Get out of their way.
7. Write It Down or Watch History Repeat
Engineers hate writing documentation. Without it, teams make the same mistakes repeatedly. Knowledge expires when people move on - and those who come after figure things out from scratch, repeating avoidable errors. Writing, teaching, and documenting are how we stop wasting time.