Solve for Failure

Sun, 10 May 2026 11:17:41 +1000

There’s a pattern I keep seeing when mentoring engineers, and it comes down to a single question: what are you solving for?

An enthusiastic engineer picks up a complex problem and dives straight into a solution. They’re energised, they’re building, they’re making progress. Or at least it looks like progress. But the solution has gaps they can’t see yet. It won’t handle failure gracefully. It hasn’t accounted for what production will actually do to it. They can’t smell what’s off because they haven’t been burned by those smells before. Then there’s the engineer who pauses. They ask uncomfortable questions. They poke at edges. They’ve seen enough things break in production to know that the interesting part of engineering isn’t making something work. It’s understanding how it will fail. The difference between these two engineers isn’t talent or enthusiasm. It’s their default assumption.

When Flexibility Becomes a Platform Problem

Sat, 14 Mar 2026 11:43:26 +1100

Recently I reviewed a piece of infrastructure code written by another engineer on our platform team. The implementation itself was good. It was clean, structured, and clearly thought through. The engineer had designed the system in a way that allowed a high degree of flexibility so that different configurations could be defined through variables. From a software engineering perspective, this was a solid approach. Flexible systems are often considered good design because they can adapt to many situations and avoid making assumptions too early. However, as I looked at the design more closely, something about it felt wrong. The issue was not with the code itself, but with the interface it created for the platform. That moment highlighted an important distinction that is easy to miss: the difference between building libraries and building platforms.

Systems-Thinking on Panditha

Solve for Failure

When Flexibility Becomes a Platform Problem