<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
  <title>CodeCrafting</title>
  <link>https://codecrafting.co.uk/</link>
  <description>Clean builds, thoughtful code, UK engineering culture.</description>
  <language>en</language>
  <lastBuildDate>Sun, 08 Nov 2026 14:49:11 GMT</lastBuildDate>
  <atom:link href="https://codecrafting.co.uk/feed.xml" rel="self" type="application/rss+xml"/>
  <item>
    <title>Week One as a Test Suite: Turning Onboarding Friction Into README Fixes</title>
    <link>https://codecrafting.co.uk/week-one-test-suite-onboarding-readme-fixes/</link>
    <guid isPermaLink="true">https://codecrafting.co.uk/week-one-test-suite-onboarding-readme-fixes/</guid>
    <description>A new starter&#039;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.</description>
    <author>CodeCrafting</author>
    <category>Engineering Culture</category>
    <pubDate>Sun, 08 Nov 2026 13:17:08 GMT</pubDate>
  </item>
  <item>
    <title>From Background Hiss to Clear Signal: A Warning Budget for Small Teams</title>
    <link>https://codecrafting.co.uk/from-background-hiss-to-clear-signal-warning-budget/</link>
    <guid isPermaLink="true">https://codecrafting.co.uk/from-background-hiss-to-clear-signal-warning-budget/</guid>
    <description>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.</description>
    <author>CodeCrafting</author>
    <category>Build &amp; Delivery</category>
    <pubDate>Sun, 08 Nov 2026 13:17:08 GMT</pubDate>
  </item>
  <item>
    <title>The Quiet Fortnight: Handover Notes That Work When the Office Is Empty</title>
    <link>https://codecrafting.co.uk/quiet-fortnight-handover-notes-holiday-runbooks/</link>
    <guid isPermaLink="true">https://codecrafting.co.uk/quiet-fortnight-handover-notes-holiday-runbooks/</guid>
    <description>Every December, a team somewhere deploys one last &#039;small change&#039; and then disappears until January. A short, honest runbook is the cheapest insurance you can buy — and it takes an afternoon, not a quarter.</description>
    <author>CodeCrafting</author>
    <category>Engineering Culture</category>
    <pubDate>Sun, 08 Nov 2026 09:17:02 GMT</pubDate>
  </item>
  <item>
    <title>Guardrails, Not Gatekeepers: Putting Accessibility Checks in the Build</title>
    <link>https://codecrafting.co.uk/guardrails-not-gatekeepers-accessibility-ci/</link>
    <guid isPermaLink="true">https://codecrafting.co.uk/guardrails-not-gatekeepers-accessibility-ci/</guid>
    <description>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.</description>
    <author>CodeCrafting</author>
    <category>Build &amp; Delivery</category>
    <pubDate>Sun, 08 Nov 2026 09:17:02 GMT</pubDate>
  </item>
  <item>
    <title>Make Dull Work Visible: The Case for a Maintenance Budget</title>
    <link>https://codecrafting.co.uk/make-dull-work-visible-maintenance-budget/</link>
    <guid isPermaLink="true">https://codecrafting.co.uk/make-dull-work-visible-maintenance-budget/</guid>
    <description>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.</description>
    <author>CodeCrafting</author>
    <category>Engineering Culture</category>
    <pubDate>Sun, 08 Nov 2026 05:20:56 GMT</pubDate>
  </item>
  <item>
    <title>Error Messages That Help: Writing Copy People Can Act On</title>
    <link>https://codecrafting.co.uk/error-messages-that-help-writing-copy-people-can-act-on/</link>
    <guid isPermaLink="true">https://codecrafting.co.uk/error-messages-that-help-writing-copy-people-can-act-on/</guid>
    <description>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.</description>
    <author>CodeCrafting</author>
    <category>Build &amp; Delivery</category>
    <pubDate>Sun, 08 Nov 2026 05:20:56 GMT</pubDate>
  </item>
  <item>
    <title>Pull Requests Without the Mumbling: How to Review Code Honestly and Kindly</title>
    <link>https://codecrafting.co.uk/pull-requests-without-the-mumbling/</link>
    <guid isPermaLink="true">https://codecrafting.co.uk/pull-requests-without-the-mumbling/</guid>
    <description>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.</description>
    <author>CodeCrafting</author>
    <category>Engineering Culture</category>
    <pubDate>Sun, 08 Nov 2026 01:19:57 GMT</pubDate>
  </item>
  <item>
    <title>Designing for the 2am Debugger: What Your Change Looks Like When You&#039;re Asleep</title>
    <link>https://codecrafting.co.uk/designing-for-the-2am-debugger/</link>
    <guid isPermaLink="true">https://codecrafting.co.uk/designing-for-the-2am-debugger/</guid>
    <description>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&#039;s a practical way to test your work against the person who&#039;ll inherit it — and the small-team release habits that make the difference.</description>
    <author>CodeCrafting</author>
    <category>Build &amp; Delivery</category>
    <pubDate>Sun, 08 Nov 2026 01:19:57 GMT</pubDate>
  </item>
  <item>
    <title>Same Bytes, Every Time: Reproducible Builds as Risk Management, Not Ritual</title>
    <link>https://codecrafting.co.uk/reproducible-builds-risk-management-2026/</link>
    <guid isPermaLink="true">https://codecrafting.co.uk/reproducible-builds-risk-management-2026/</guid>
    <description>Reproducible builds used to be a purist&#039;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.</description>
    <author>CodeCrafting</author>
    <category>Build &amp; Delivery</category>
    <pubDate>Sat, 07 Nov 2026 21:23:58 GMT</pubDate>
  </item>
  <item>
    <title>The Repair Café Mindset: Keeping Legacy Systems Alive Without the Grand Rewrite</title>
    <link>https://codecrafting.co.uk/repair-cafe-mindset-legacy-refactoring/</link>
    <guid isPermaLink="true">https://codecrafting.co.uk/repair-cafe-mindset-legacy-refactoring/</guid>
    <description>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.</description>
    <author>CodeCrafting</author>
    <category>Engineering Culture</category>
    <pubDate>Sat, 07 Nov 2026 21:23:58 GMT</pubDate>
  </item>
</channel>
</rss>