Why I’m Writing About Engineering in 2026

 Software engineering moves quickly, but the problems teams struggle with tend to repeat. Every few years we adopt new tools, frameworks, or processes that promise speed and simplicity. Some deliver real value. Others quietly replace hard engineering work with ceremony, abstraction, or optimism. As we head into 2026, it feels like a good moment to pause and reflect on which practices have endured—and which ones we may have let slip.

Over the coming weeks, I’ll be writing about a few recurring themes I’ve seen across teams and systems: how Agile practices interact with engineering discipline, why databases and infrastructure decisions shape products for years, and what it actually takes to run reliable systems in production. These posts won’t focus on tools or trends. They’ll focus on the unglamorous work—design, testing, operational awareness, and feedback loops—that quietly determine whether teams can move fast and safely.

The goal isn’t to prescribe a single “right way” to build software. It’s to surface tradeoffs, share lessons learned (often the hard way), and invite thoughtful discussion among people doing the work. Many of the ideas here build on perspectives from engineers and practitioners I respect, combined with my own experience seeing where theory meets reality.

If you’re interested in how engineering practices evolve over time—and why fundamentals matter more than ever—you’ll probably find something here worth engaging with. And if you disagree, even better. Thoughtful disagreement is how these practices improve.