Work that holds up after I leave
How I take a domain from the first conversation to the handover: questions early, decisions written down, and code the next person can run without me in the room.
Before I write code
I start by reading everything already on file: the spec, the tickets, the spreadsheet the business runs on. Then I write down what I think the system has to do and where those sources disagree.
The gaps go back as questions while the answers are still cheap. A spec that argues with itself is normal. Guessing quietly is how a system ships wrong and confident.
How a week looks
Three habits that keep remote work predictable.
- Written updates: A short written note at the end of each working day: what moved, what is blocked, what is needed. Nobody has to call a meeting to find out where things stand.
- Small releases: Work lands in small, reviewable pieces behind a passing test suite, not in one large drop at the end. Progress shows on the real system, not on a slide.
- One owner per decision: One person who can answer questions and decide is enough. The daily note keeps them informed, and the decisions from each conversation get written down the same day.
What ships with the code
Every change arrives with the things that keep it correct after I stop touching it.
- Tests around the money: Where correctness is auditable, it is tested, including cases computed by hand first, so the test proves the code rather than agreeing with it.
- Migrations with a way back: Schema changes ship with a rollback path and are rehearsed against a copy of real data before they touch production.
- Notes for the next person: Each non-obvious decision gets a short note beside the code saying why, not what. I write for whoever inherits the module, on the assumption that it will not be me.
- Bugs outside my scope get reported: When I find a problem outside the ticket, it gets written up and handed over rather than walked past. Fixing it is a decision for whoever owns the roadmap. Knowing about it is not optional.
How it ends
A domain changes hands with a handover, not a disappearance: a written map of the system, the environments and access listed in one place, the open questions I know about, and a walkthrough with whoever takes it on.
The measure I hold myself to is simple: six months after I stop touching it, the system still holds up and the team can run it without me in the room.
Straight answers
The questions about working together that come up first.
- Can you start on a codebase someone else wrote?: Yes, and most of my work has started that way. The first days go to reading, running the tests and writing down what I find before I change anything.
- What happens when the spec is wrong?: I say so, in writing, with the options as I see them. The decision stays with whoever owns the system. What I will not do is pick one quietly and ship it.
- How do you work with a lead engineer?: I take whole domains off their plate and ship them through reviewed pull requests with tests and documentation. On the insurer's platform the lead later extended my payroll design for a second country rather than replacing it, which is the best review a design gets.
- What does the handover contain?: A written map of the system, every environment and credential location listed in one place, the open questions, the run-books for the jobs that run on a schedule, and a walkthrough with whoever takes the domain on.
Contact
Questions about how any of this works in practice are welcome.