Clean builds, thoughtful code, UK engineering culture.
Deprecated code often vanishes with no record of why it existed or what replaced it. This is a practical case for small, discoverable retirement markers, backed by a lightweight register and a lint rule that points people towards the exit.
Every office kettle in Britain wears a little label saying when it was last looked at and when it's due again. Your package.json deserves the same courtesy. Here's a lightweight, risk-tiered review cadence for third-party code that doesn't collapse into a January panic.
A decent roundabout doesn't need a marshal standing in the middle waving you on — the paint, the signs and the layout do the work. Good APIs behave the same way. Here's how junction design translates into endpoints, errors, versioning and docs, plus a checklist to run before your next release.
An export button is not a feature you can leave until a compliance deadline. It is a promise that your data model, support process and storage choices can survive contact with the outside world. Here is how to rehearse that exit before anyone actually needs it.
Blue plaques do not record every resident; they mark the ones worth remembering. Your repository can do the same for the choices that keep it standing. Here is a lightweight way to write decision records that help the next engineer, not just the historian.
Billing bugs almost never start with bad arithmetic — they start with bad modelling. A practical look at integer pence, VAT rounding, discounts and refunds, plus a set of tests you can lift straight into your own suite.
Most incident drills happen on a calm Wednesday when everyone is at their desk. This one happens when the trains are cancelled, the phone signal is patchy, and the on-call engineer is on a rail replacement bus. Here is how to run a quarterly disruption drill that produces runbook fixes rather than a box-ticking performance.
Every codebase has a few clever bits that felt brilliant to write and feel expensive to change. Here is a lightweight quarterly audit to find them, score them and replace the showiest ones with code your team can actually maintain.
Your cron job runs at 06:00 every weekday, right up until the morning it fires into a bank holiday and nobody is there to catch the fallout. This is a practical look at modelling UK holidays properly — including Scotland's separate dates, substitute days and the awkward weekend rules — and why calendar logic belongs in product code, not a single line in a crontab.
Small product teams keep borrowing enterprise architecture like a corner shop borrowing a warehouse forklift. This is a practical look at what your scale actually justifies — and how to tell the difference between useful structure and expensive decoration.
Most bank-holiday deploy freezes are habit dressed as policy. Here is how to turn the Christmas and bank-holiday calendar into an explicit risk budget — mapping release windows to real support capacity, separating deploy from launch with flags, and writing down what the pause is actually protecting.
Local build times are usually treated as a personal irritation, but they are really a shared team cost. This is a practical way to measure the developer feedback loop, agree a kettle-test target, fix the worst offenders and stop the gains from quietly slipping away.
Most of us build on office fibre and then ship to a country of wet hills, packed trains and festival crowds. Here's a practical approach to optimistic updates, durable queues and offline states that don't eat the user's work.
Every October your scheduled jobs get a second chance to fire, and every March one of them silently doesn't. A practical look at making the UK's twice-yearly clock change a tested behaviour rather than an annual surprise.
Postcode lookup gets you eighty per cent of the way and then quietly gives up on the flat above the shop, the farm with a name and no number, and anything bound for a BFPO. A field guide to address capture that expects the mess.
Compiler warnings are easy to ignore until they become the weather in your team. A warning budget gives you a way to baseline the noise, ratchet the build and triage what matters without turning code review into a blame session.
A new starter's first week is the closest thing most teams have to a clean-room test of their documentation. Treat the README as the first pull request: run the setup, capture the friction and merge the fixes while the memory is fresh.
Accessibility work usually arrives as a late audit and a spreadsheet of shame. Wire the mechanical checks into CI, keep the human judgement for humans, and the whole thing starts to feel like ordinary engineering.
Every December, a team somewhere deploys one last 'small change' and then disappears until January. A short, honest runbook is the cheapest insurance you can buy — and it takes an afternoon, not a quarter.
Most teams have a roadmap for new things and a shrug for the work that keeps existing things alive. This is a pitch for a formal maintenance budget: a protected slice of sprint capacity for upgrades, patching and proven tooling, framed as delivery insurance rather than nostalgia.