The Best Engineering Decisions Usually Remove Work
The best engineering decisions usually do not add more process or more code. They remove work, shorten paths, and make the remaining system easier to understand.
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
Software Engineer, Work
Software delivery usually slows down because of decisions, handoffs, fear, and bad environments, not because developers are typing too slowly.
Programming, Software Engineer
Offline support looks like a simple feature request until you have to deal with stale data, sync conflicts, retry rules, and user expectations. The hard part is not storing data locally. It is keeping the whole system honest.
Software Engineer
Build pipelines stop being “just internal tooling” the moment they start deciding how fast you can ship, how often you break things, and how painful releases feel.
Programming, Software Engineer
Kotlin feels good when it removes friction instead of adding ceremony. After enough Java, that difference becomes obvious very quickly.
Programming, Software Engineer
The hard part of a mobile app is usually not the screen layout. It is sync, auth, state, permissions, offline behavior, and the release problems that show up after the UI already looks finished.
Programming, Software Engineer
A good API is not just functional. It is predictable, consistent, and easy to use without a lot of guesswork.
Programming, Software Engineer
Clever infrastructure looks impressive in diagrams. Boring infrastructure is usually easier to operate, easier to debug, and much easier to keep alive once real users depend on it.
Programming
Environment management usually looks simple at first. Then defaults drift, secrets spread out, local setups stop matching production, and the whole thing becomes a source of avoidable mistakes.
Programming, Software Engineer
AWS diagrams love to look simple. The problem is that the operational reality behind them is usually doing a lot more work than the picture admits.