FDEInterviews logoFDE/Interviews

You will be asked to judge a system nobody left documentation for

An FDE routinely has to make decisions about software they have never seen, whose authors have left, in a week. There is a repeatable order for doing that: follow the data, then the deploys, then the money, and read the tests last.

13 MIN

TL;DR: Orienting in an unfamiliar system is a procedure, not a talent. Follow one real record end to end, read the deployment path, find where the cost is, and treat the code as the last source of truth rather than the first.

Where you are. Module three. Discovery told you what the customer needs. Now you have to understand the system you will be building against, and nobody who wrote it is available.

The situation, precisely

You are given read access to a repository, a data warehouse, or both. The people who designed it left two reorganisations ago. The documentation describes an architecture that was replaced. Nobody currently employed can explain why the third service exists, and you are expected to have an opinion about feasibility by Friday.

This is not a pathological case. It is the normal condition of the work, and being good at it is one of the few genuinely transferable FDE skills.

The discipline it demands has a name older than software. Chesterton's fence, from a 1929 essay, says that if you find a fence across a road and cannot see the reason for it, the answer is not to clear it away but to go and find out why it is there. That third service nobody can explain is a fence. It is there because something happened, usually something expensive, and the person it happened to has left. New engineers who remove fences in week two are the reason experienced customer teams are wary of new engineers in week two.

The instinct is to read the code from the top. That is the slowest possible route, because a codebase tells you what is there without telling you what matters. Four passes, in this order, get you further in a day than a week of reading.

PASS 1 Follow one record in, through, out PASS 2 The deploy path what actually runs PASS 3 Where cost is volume and spend PASS 4 The tests what they feared THE SLOW ROUTE Reading the code from the top tells you what exists, not what matters. The code is the last source of truth, not the first: it says what happens, never why, and the why is what you were asked for.

Pass one: follow one record

Take a single real record and trace it from the moment it enters the system to the moment somebody sees it. One customer, one order, one ticket.

This is the highest-value hour you will spend. A single traced record answers five questions the diagram cannot:

  • Which services are actually involved, rather than the ones drawn on the wall
  • Where the data changes shape
  • Which hops are synchronous, and therefore which ones can time out
  • Where the same fact is stored more than once
  • Which system holds the version people believe

That last one is the prize. Every organisation has a number that several systems disagree about, and exactly one of those systems is the one people quote in meetings.

You will also discover the parts of the architecture diagram that no longer exist, which is information you cannot get any other way short of asking someone who has left.

Pass two: read the deployment path

Find out what actually runs in production and how it got there. The build configuration, the deployment scripts, the scheduled jobs, the environment variables.

Repositories accumulate code that runs nowhere. The deployment path is the filter: it tells you which parts of what you are reading are load-bearing. It also tells you how a change reaches production, which is the thing you will need on your first day of actually building, and which is frequently more constrained than anyone mentions during discovery. Better to learn about the fortnightly release train now than in the week you need a hotfix.

Pass three: find where the cost is

Cost concentrates, and concentration marks importance. Which tables are enormous, which jobs run hourly rather than nightly, which endpoint takes the most traffic, which process someone set an alert on.

This is a shortcut to what the organisation cares about. Nobody sets an alert on something that does not matter, and nobody optimises a query that runs twice a month. The expensive parts of a system are a map of what has hurt before.

Pass four: read the tests, last

Tests are the most honest documentation in most repositories, because they were written by someone trying to prevent a specific failure they had experienced.

Read them last, once you know the shape of things. Then look for the oddly specific ones. A test named for an edge case, with a comment naming a date or a ticket, is a scar. Each one is a thing that broke in production badly enough that somebody made sure it could not happen again, which is exactly the institutional knowledge nobody wrote down anywhere else.

Do this before moving on

Pick an open-source project you have never read, ideally one with a real deployment story. Spend forty minutes doing pass one only: trace one request or one record from entry to output, writing down each component it touches. Then read the project's own architecture documentation. The gap between what you traced and what the document claims is the thing this lesson is about, and it exists in almost every codebase.

Go deeper

Key takeaways

  • Orienting is a procedure: follow one record, read the deploy path, find the cost, read the tests last.
  • Tracing a single real record end to end is the highest-value hour, and it exposes the parts of the diagram that no longer exist.
  • The deployment path is the filter that separates load-bearing code from accumulated code.
  • Oddly specific tests are scars, and each one is institutional knowledge that exists nowhere else.

Check yourself

Answer before you look. Recalling it is what makes it stick; recognising it does not.

  1. 1You have five days to assess feasibility against an undocumented system. What do you do first?

  2. 2Why read the deployment path before most of the source?

  3. 3You find a test with a very specific name referencing a date and a ticket number. What is it telling you?

Sign in to track which lessons you have finished.