CodeCrafting Clean builds, thoughtful code, UK engineering culture.

CodeCrafting

Clean builds, thoughtful code, UK engineering culture.

Latest Articles

Week One as a Test Suite: Turning Onboarding Friction Into README Fixes
Engineering Culture

Week One as a Test Suite: Turning Onboarding Friction Into README Fixes

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.

From Background Hiss to Clear Signal: A Warning Budget for Small Teams
Build & Delivery

From Background Hiss to Clear Signal: A Warning Budget for Small Teams

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.

The Quiet Fortnight: Handover Notes That Work When the Office Is Empty
Engineering Culture

The Quiet Fortnight: Handover Notes That Work When the Office Is Empty

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.

Guardrails, Not Gatekeepers: Putting Accessibility Checks in the Build
Build & Delivery

Guardrails, Not Gatekeepers: Putting Accessibility Checks in the Build

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.

Make Dull Work Visible: The Case for a Maintenance Budget
Engineering Culture

Make Dull Work Visible: The Case for a Maintenance Budget

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.

Error Messages That Help: Writing Copy People Can Act On
Build & Delivery

Error Messages That Help: Writing Copy People Can Act On

An error message is not a stack trace with a nicer font. It is a tiny piece of product design that either helps someone recover or quietly tells them to give up. Here is how to write errors that distinguish user mistakes from system failures, avoid blame and survive code review.

Pull Requests Without the Mumbling: How to Review Code Honestly and Kindly
Engineering Culture

Pull Requests Without the Mumbling: How to Review Code Honestly and Kindly

British indirectness has a habit of leaking into code review, where it turns into comments too vague to act on or too apologetic to be useful. A practical taxonomy for blocking versus non-blocking feedback, plus the templates that keep pull requests honest, kind and moving.

Designing for the 2am Debugger: What Your Change Looks Like When You're Asleep
Build & Delivery

Designing for the 2am Debugger: What Your Change Looks Like When You're Asleep

Most production changes are judged by whether they work, not by whether they can be diagnosed by someone else at three in the morning. Here's a practical way to test your work against the person who'll inherit it — and the small-team release habits that make the difference.

Same Bytes, Every Time: Reproducible Builds as Risk Management, Not Ritual
Build & Delivery

Same Bytes, Every Time: Reproducible Builds as Risk Management, Not Ritual

Reproducible builds used to be a purist's hobby horse. In 2026 they turn up in procurement questionnaires, SBOM reviews and incident post-mortems — here is a pragmatic adoption path for small UK teams that does not stall the roadmap.

The Repair Café Mindset: Keeping Legacy Systems Alive Without the Grand Rewrite
Engineering Culture

The Repair Café Mindset: Keeping Legacy Systems Alive Without the Grand Rewrite

Repair cafés fix toasters instead of binning them. The same instincts — understand before replacing, mend in place, share the knowledge — work surprisingly well on a fifteen-year-old codebase, and cost a lot less than the rewrite nobody can scope.