About
Open to work — Open to senior engineering and technical leadership roles — full remote, international.
Software engineer with fifteen years of production experience. I write about clean code, clean architecture, refactoring, testing, and legacy systems — the disciplines that determine whether a system remains easy to change two years after it launched.
I've spent fifteen years building software in environments where the first version is never the last. Backend systems, distributed services, legacy codebases migrated to microservices — the common thread is that everything eventually needs to change, and whether it can depends almost entirely on decisions made much earlier.
Clean code and clean architecture are not about aesthetics or following rules. They're about reducing the cost of change. A well-structured system is one where the next engineer — or your future self — can understand what's happening, make a modification, and trust that nothing unexpected breaks. Refactoring is how you keep that property alive over time. Testing is how you do it safely. That's what I write about here.
I'm particularly interested in the distance between how these disciplines are taught and how they're applied in practice. Abstractions that increase indirection without reducing complexity. Test suites that pass but don't catch real regressions. Microservice migrations that distribute a monolith's problems rather than solve them. Clean code that stays clean only until the second sprint.
What this is
A place for engineering writing that takes real-world constraints seriously. The goal is not to preach clean code or sell a methodology — it's to examine what these disciplines actually mean under pressure: when to refactor and when to leave it, what to test and what not to, and what clean architecture looks like when the deadline is real.