The craft — our engineering standard

Not a style guide — a shared idea of what “good” means here.

What “done” means

Done is not “it works on my machine.” Done is not “I pushed it.” It's done when all six of these are true:

• It does what was actually asked for — and you checked, rather than assumed.
• Someone else has read the code and approved it.
• You tested it. On purpose. Including the ugly cases.
• It's documented.
• It's deployed where the people who need it can see it.
• You'd be comfortable if a stranger read this code with your name on it.

Miss any one of the six, and it isn't done. It's just written.

Code review

Nothing reaches a client's system without a second pair of eyes. Not because we don't trust you — but because nobody catches their own blind spots.

• Review the code, not the person. "This breaks when the list is empty" — not "you always forget this."
• Small changes, reviewed fast. A review sitting for two days is a review blocking a person.
• If you don't understand it, that's a finding. Code only its author can read is a liability, however clever.
• Approving means you'll stand behind it. A rubber stamp is worse than no review.

The four documents we owe every project

Write them as you build. Never at the end — by then you've forgotten why.

The workflow

What this system does, in plain language, for a human.

The database

What the tables are, and how they relate.

The API

Every endpoint. What it takes. What it returns.

The codebase

How to run it, how to deploy it, and where the bodies are buried.

CodeNicely for CodeNicely.Our first engineering job description, 2021

Testing, and handover

Test the thing you built before you say it's finished. Then test the case you're hoping nobody tries. The empty list. The enormous file. The double-click. The network dropping halfway.

Every bug a client finds costs us more than it costs them — in trust, which is the only currency we actually have.

Write code as though the person who maintains it is someone you like. Because it will be. Half the time it's you in eight months, and you will have forgotten everything. The real test of our craft isn't whether we can build it. It's whether someone else can pick it up.

Building with AI

Four rules. Not complicated. Not negotiable.

1. Use it. Hard.

Not using AI to go faster is falling behind. Every engineer here works with these tools daily, and we expect you to be fluent. This isn't an experiment any more. It's how we work.

2. You own every line it writes.

The AI can write it. You are accountable for it. If you can't explain what it does and why it's right, you can't ship it. "The AI wrote it" is not a defence. It never has been.

3. Never paste client code into public tools.

Approved tools and accounts only. A client's code in a free chatbot is a data leak. It doesn't matter that you were only trying to fix a bug.

4. Be honest about it.

We build with AI and we say so. We never dress AI work up as handmade, and we never dress slow work up as AI-fast.