Forward deployed work means landing in a codebase you have never seen and being useful within days, repeatedly. The instinct — read the structure, skim the modules, build a mental map before touching anything — is the slowest approach available, because it produces a shallow picture of everything and a working knowledge of nothing.
What works is depth-first: pick one real behaviour and follow it all the way through, end to end, ignoring everything you pass. One complete trace teaches you the conventions, the layering, the error handling and the naming, because you have seen them all in service of something that actually happens.
Trace one request, completely
Choose a meaningful operation — the one the business cares about — and follow it from entry point to database write and back. Read the routing, the controller, the validation, the service, the query, the events emitted, the jobs queued. Take notes on the mechanism rather than the specifics. By the end you will know how this codebase does things, which generalises far better than knowing where the files are.
Running it in a debugger beats reading it, and running it while the application serves a real request beats both. Static reading tells you what could happen; a breakpoint tells you what does, including the middleware and the conditional nobody mentioned.
# Where the work actually is: churn tells you what this team touches daily.
git log --since='6 months ago' --name-only --pretty=format: \
| sort | uniq -c | sort -rn | head -30
# Who to ask about which area, without asking anyone.
git shortlog -sn --since='1 year ago' -- src/billing/
# The commit that introduced a puzzling line, with the reasoning attached.
git log -S 'skip_validation' --oneline --reverse
# The tests for a module are its specification, written by someone who
# knew what it was supposed to do:
find . -path '*test*' -name '*billing*'Change frequency is the most useful map of an unfamiliar repository. A directory with four hundred commits in six months is where the product lives; one untouched for three years is either stable infrastructure or abandoned, and the commit log usually tells you which within a minute.
Ship something small on day one
- Fix a trivial bug or add a small test in the first day. It forces you through the entire build, test, review and deploy pipeline, which is where the undocumented steps are.
- Read the tests before the implementation when a module is confusing; they state intent without the accidental complexity.
- Ask questions in writing, in a shared channel. The answers become documentation and other people benefit from the same gap.
- Write down what confused you, and fix the worst of it before you acclimatise. Your confusion has a short shelf life and is genuinely valuable while it lasts.
- Resist proposing restructuring in the first fortnight. Most things that look wrong are load-bearing, and the ones that are genuinely wrong will still be wrong in a month.
You do not need to understand the codebase. You need to understand the path through it that your change touches, and to know when you have left that path.
Coding agents have changed the first day materially, and it is worth being precise about how. They are extremely good at 'where is X handled' and 'trace what happens when Y' across an unfamiliar repository — the search-and-summarise work that used to consume an afternoon. They are not a substitute for the debugger trace, because they will describe what the code appears to do, and the gap between that and what it actually does at runtime is exactly where the interesting problems live.