Taking over something somebody else built
Every inherited system looks worse than it is, for the same reason every unfamiliar city looks badly planned.
Sooner or later you inherit something: a codebase, an automation, a spreadsheet three departments depend on. The person who built it is gone or busy, and it works, and nobody can tell you why.
The urge to rewrite is almost always wrong
Unfamiliar work looks bad because you can see all its scars and none of its reasons. The odd condition in the middle of a function is not carelessness; it is the fix for a customer problem in 2023 that nobody wrote down.
Rewriting throws away those undocumented reasons and rediscovers them one incident at a time. Give yourself a rule: no rewrite until you have made three small changes successfully. By then you will either understand it well enough to rewrite properly, or you will have discovered it is fine.
Find out what is load-bearing
In any inherited system, a small part is doing most of the real work and a large part is decoration — old experiments, dead paths, features nobody uses. From the inside they look identical.
Two cheap ways to tell them apart. Look at what changes most often, because frequently edited code is where the business actually lives. And look at what runs most often. Anything neither edited nor executed in a year is a candidate for deletion, and deleting it is the fastest way to make everything else comprehensible.
Find the person who remembers, before you need them
There is almost always someone still around who was nearby when it was built — not necessarily the author. A support person who remembers the incident, a colleague who reviewed it, the client who asked for the odd requirement.
Talk to them in your first week, while your questions are still naive and cheap, rather than in month three when you are stuck and stressed. Thirty minutes then saves days later, and their memory gets worse every month you wait.
Make one small change and ship it
Reading unfamiliar code teaches you surprisingly little; changing it teaches you everything. Pick something trivially small and take it all the way to live.
You will learn what you actually needed to know: how it gets built, what breaks when you touch it, whether the tests mean anything, who notices. That is the real map, and it does not exist in any document. Write down what you learned on that first change — you are the only person who will ever see this system with fresh eyes, and that view is gone within a month.
Questions people actually ask
Should I rewrite an inherited system?
Not first. Unfamiliar work looks bad because you see its scars and none of its reasons — that odd condition is usually an undocumented fix. Make three small changes successfully before considering a rewrite.
How do I tell which parts matter?
Look at what changes most often and what runs most often. Frequently edited code is where the business lives; anything neither edited nor executed in a year is a deletion candidate, and deleting it makes the rest comprehensible.
What should I do in the first week?
Find whoever was nearby when it was built — not necessarily the author — while your questions are still naive, and make one trivially small change all the way to live. Then write down what you learned, before the fresh view disappears.
