Engineering Practice
Putting it together: code and config reading
Crux Read real artifacts from the delivery loop — a test, a feature flag, a CI gate config, and a postmortem action item — and pick the change a senior engineer makes first.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitThe loop is not an abstraction — it shows up as a test, a flag, a CI gate, and a postmortem action item. Read each artifact, find which link of the delivery loop it strengthens or breaks, and choose the fix a senior engineer would make first.
Goal
Practise reading the concrete artifacts each practice produces — a test, a feature flag, a pipeline gate, a postmortem item — and judging whether each one actually closes the loop or quietly leaves a seam open.
Snippet 1 — a flag check on the hot path
// shipped 14 months ago for the "new-checkout" rollout, never removed
export function priceCart(cart: Cart): Money {
if (flags.isEnabled("new-checkout-pricing")) {
return newPricing(cart); // the rollout "completed" months ago
}
return legacyPricing(cart); // still here, still reachable
} Quiz
Completed
The new-checkout rollout finished over a year ago. What is the senior action on this flag, and why does leaving it cost more than it looks?
Heads-up A completed flag is not a rollback tool; it is a live branch nobody tests. The lifecycle (initial → live → completed → archived) exists because skipping removal is how a release toggle becomes the next Knight-Capital-style incident.
Heads-up Silently re-purposing a release toggle as a permission toggle is the classic flag-debt trap: a 'temporary' switch becomes load-bearing forever, with no owner and no tests on the legacy branch.
Heads-up Testing a branch you intend to delete is wasted work that legitimizes keeping dead code. The fix is removal, which also removes the test burden — not adding coverage to debt.
Snippet 2 — a test written first
// written before any implementation exists
test("refund splits across original tender lines", () => {
const order = orderWith([cash(30), card(70)]);
const refund = refundService.refund(order, money(50));
expect(refund.allocations).toEqual([cash(15), card(35)]); // proportional
}); Quiz
Completed
The team writes this test before refundService exists. What is the primary value of writing it first, in the loop's terms?
Heads-up Coverage is a by-product. Test-first's payoff is design feedback — a bad interface shows up in seconds — plus a reliable gate; chasing coverage as the goal produces brittle tests that assert implementation, not behaviour.
Heads-up Tests catch regressions against a known spec; review catches design and intent the test author never thought to assert. They are different links — a passing test does not replace a reviewer reading the change.
Heads-up The design-pressure benefit is strongest at the unit/API level, where you are shaping the interface. The loop wants the fast unit/contract signal as the merge gate; e2e stays a thin smoke layer.
Snippet 3 — a CI pipeline gate
# .ci/merge-gate.yml — required for merge to trunk
on: pull_request
jobs:
gate:
steps:
- run: make unit # ~90s, deterministic
- run: make contract # consumer + provider verification
- run: make e2e-smoke # 1 critical path only
- run: make e2e-full || true # full suite, allowed to fail Quiz
Completed
This gate is required for merge. What is the highest-leverage fix to the config, and why?
Heads-up Piling slow flaky e2e onto the merge gate is what makes the signal slow and untrusted, so people mute it — the failure this gate already shows. The loop wants a fast deterministic gate; e2e-full belongs in a nightly or async lane.
Heads-up That deletes the gate entirely: broken work lands on trunk freely and you lose the precondition for safe frequent merging. The fix is fewer, deterministic, blocking checks — not making everything non-blocking.
Heads-up Keeping a step that can never fail in the required gate is theater: it looks like coverage but gates nothing, and engineers learn the suite's red is meaningless. Either it blocks or it leaves the gate.
Snippet 4 — a postmortem action item
## Action items
- [ ] Improve communication during incidents owner: ? due: ?
- [x] Add contract test asserting `cart.total` is non-negative owner: @ana due: 2026-06-02 ticket: PAY-1183
- [ ] Be more careful when changing pricing config owner: team due: ongoing Quiz
Completed
Reading these three action items from a blameless postmortem, which one actually closes the loop, and why do the other two fail?
Heads-up An action item must be specific, owned, and trackable, or it is theater. 'Be more careful' assigns no work and changes no system, so the outage recurs — the exact seam that breaks the loop.
Heads-up It may matter, but with no owner and no due date it ships nothing. An unowned item is indistinguishable from no item; the loop only closes when work is owned and tracked.
Heads-up The timeline is for understanding; the owned action items are what turn the incident into a system you fixed. Without them the postmortem is a doc nobody acts on and the same incident returns next quarter.
Recap
Each practice leaves a concrete artifact, and reading it tells you whether the loop is intact: a completed flag still on the hot path is debt to remove, not a rollback tool; a test written first is design pressure and the merge signal, with coverage as a by-product; a CI step that is ‘allowed to fail’ is not a gate and quietly trains the team to ignore red; and a postmortem item only closes the loop when it is owned, dated, tracked, and feeds a concrete assertion back into CI. Read the artifact, find the link it touches, fix the seam — do not admire the ceremony.