The Difference Between a Prototype and a System
Prototypes are allowed to be clever and disposable. Systems are not. The difference shows up when something grows, someone new has to own it, or you need to debug it under pressure.
Engineering notes from the sharp end
Practical writing about software, systems, delivery, and things that behave strangely under pressure.
wade womersley – york based software engineer I write the way I work: direct, useful, and more interested in what holds up in production than what sounds clever on a slide.
Latest post
Archive
Recent writing
Programming, Software Engineer
Defaults are useful until they become hidden policy. I usually prefer explicit configuration because it is easier to understand, easier to change, and much less surprising later.
Programming, Support
Good error messages do more than complain. They tell you what happened, what to try next, and what the system needs from you so failure is easier to recover from.
Programming, Software Engineer
Good logging is not just for engineers. It reduces support time, shortens incident diagnosis, and makes a system much easier to trust when something goes wrong.
Programming, Software Engineer
Smaller deployments are usually easier to trust, easier to roll back, and easier to debug. Once a release starts carrying too much change, the team spends more time managing risk than shipping value.
Programming, Software Engineer
API versioning is useful when the contract has really changed, not when a team wants a convenient place to hide messy changes. I usually want the compatibility story to be explicit before I reach for a new version.
Programming, Software Engineer
Fancy cloud abstractions often look like they remove complexity, but a lot of the time they just move it somewhere harder to see. That matters when something breaks and you need to debug it or hand it over to someone else.
Programming, Software Engineer
Kotlin coroutines are worth learning because they make async code easier to read and easier to reason about. They still need discipline, but they usually beat callback-shaped code by a long way.
Programming, Software Engineer
A mobile release can look fine in the app store and still be a bad idea. I usually trust it only after I have checked crash risk, permissions, API compatibility, startup behavior, rollout safety, and what happens after the update lands.
Programming, Software Engineer
The hard part of serverless is usually not writing the handler. It is understanding what failed, what the event looked like, and why the system changed underneath you.