role · developer

Developer

The Developer is where the brief becomes the thing. Their job is not to write the most code — it is to write code that the next Developer can read, the test catches before the user does, and the pipeline gates before production sees.

What good looks like

A competent Developer produces three artefacts every cycle:

1. Code that speaks domain language — the brief's names survive into class names, function names, variables. A new reader recognises the chain in the source.
2. A test suite that catches at the right level — unit tests for logic, integration for contracts, e2e only for the moments that matter. No test that pretends to verify something it doesn't.
3. A PR that tells a story — title says the user outcome, body says what changed and why, observability hooks named where the feature flag controls behaviour.

A Developer who produces these has the making chain working. A Developer who skips domain language hands the team a codebase that will be rewritten in two cycles.

The Developer's stance

The Developer is responsible for	The Developer is not responsible for
The code surviving contact with the next reader	What problem the code is solving
The test catching the level it claims to catch	Holding the full test pyramid alone
The PR being readable	The PR being merged on a deadline
The observability hooks for the change	The metric the hooks feed
Refusing a story they can't sketch in 30 minutes	Estimating a story without sketching

The Developer holds the chain by holding the boundary between what was decided and what was made.

Three artefacts to read first

1. Domain Language in Code
2. Trunk-Based Development
3. Testing Layers

First 30 days

Day 1–3 — Read the canon

Read As We Build Parts 1–6 (Domain Language → Testing). Read What We Shape Parts 4, 5 (Story Writing, Amigos & Gherkin). Read After We Build Parts 3, 4 (Bugs and Their Roots, Incidents).

Output: in three sentences, name a place in the codebase where the domain language has decayed since the last brief, and what the original brief called it.

Day 4–7 — Pair on a story

Pick the next available story. Pair with an experienced developer end-to-end — amigos, sketch, code, test, review, merge.

Output: merged PR with co-author, plus a one-page note on what surprised you about the team's trunk-based discipline.

Day 8–14 — Pick up a story alone, sketch first

Take the next story. Spend the first 30 minutes sketching — sequence diagram, data flow, the test you'll write first. Do not type code in that 30 minutes.

Output: the sketch, then the PR with sketch attached.

Day 15–21 — Hold amigos for one story

The Developer is one third of amigos. Hold the session for your next story. Bring at least one technical risk the team should know before you code.

Output: signed Gherkin scenarios including the technical risk you raised.

Day 22–25 — Review someone else's PR honestly

Review at least three PRs from the team. Comments say why this convention, not just change it.

Output: review comments that another developer could learn from, not just act on.

Day 26–30 — Watch your code in production

When your story flag enables, you watch the dashboards (not the support tickets) for at least one hour. Take notes; do not act on first-hour noise.

Output: a one-page note on what you saw, plus — if relevant — a small follow-up PR for an observability gap you found.

Deepening — self-rate yourself

Domain language

• The brief's terms survive into my code without translation.
• A name in production traces back to a name in the brief, every time.
• I can refactor a misnomer without it being a personal moment.

Test discipline

• Each test names the level it is catching.
• I have killed tests that were green for the wrong reason.
• I can defend the test pyramid for my service in one minute.

Trunk-based

• Branches live less than a day.
• A feature flag protects every in-flight change.
• I have stopped working when the build was red.

Review craft

• I leave at least one comment on every PR that teaches.
• I can spot domain drift in a diff within 60 seconds.
• I have rejected a PR I would have merged a year ago.

Observability

• Every feature flag has a metric the team will read.
• I can sketch the dashboard for a story before I write the code.
• A new developer can debug my code at 2am without me.

Stuck if…

…the same bug class keeps coming back

The test is at the wrong level. Re-read Testing Layers. If a logic bug keeps escaping unit tests, the unit is too coarse, not the e2e too small.

…branches keep living three days

Trunk-based has decayed. Either the stories are too big or the flags aren't being used. Re-read Trunk-Based Development and the story slicing page.

…you can't sketch the story in 30 minutes

The story is too big or too vague. Push back at amigos, not after merging. The first sketch is the first test of whether the story is real.

…a PR is "almost done" for three days

The PR is doing more than one thing. Split it. The trunk-based discipline holds even when a story is taking longer than expected.

…the postmortem traces to your story

Read the postmortem without flinching. Find the chain level. Own the fix if it is yours; surface the level if it is structural.

…the codebase needs "a rewrite"

The brief was missing, the ADR wasn't written, the domain language was never named. The fix is not the rewrite — it is the missing artefact. Open an ADR first.

See also

• Skill path — Developer foundations
• Canon — As We Build · What We Shape
• Practice — Holding amigos · Story writing
• Templates — Story · Gherkin scenario set
• Checklists — Story DoR · Amigos agenda
• Areas — 6 · Development & Code · 7 · Quality & Testing