Reading Legacy Code

You're dropped into a codebase with no comments, no docs, and the person who wrote it left two years ago. This is normal work, not a crisis — and there's a method to it.

Most of a developer's career is spent reading code someone else wrote, not writing new code on a blank page. "Legacy" doesn't mean bad. It means: written by someone who isn't you, for reasons that aren't written down, that you now have to change without breaking.

This guide covers three things:

Where to start when the whole codebase feels like an undifferentiated wall of files — pick one thread and pull it.
Techniques for building understanding — using git history as archaeology, writing a safety-net test before you touch anything, and using small refactors to learn by doing.
When a rewrite is actually justified versus when it's the sunk-cost fallacy wearing an engineering hat, using Chesterton's Fence as the test.

None of this requires the original author, a design doc, or weeks of read-only ramp-up. It requires picking a starting point and being disciplined about how you poke at the unknown.