Reading Other People’s Code Without Hating It

Reading someone else’s code can make your brain go, what is this and who approved it. In other words, your taste kicks in before your understanding does, and that reaction is normal abeg.

Most inherited systems are not written by crazy people, I hope. They're usually under deadlines, constraints, half-known requirements, etc. If you start with that assumption, the code reads differently. Maybe more explainable.

Step One: Stop Trying to Refactor in Your Head

The first mistake most of us make is mentally rewriting everything as we read. You see a long function and think, this should be split. You see nested conditionals and think, this should be polymorphism. Maybe. But you don't even know what problem this code is solving yet.

Instead, start with behavior. What does this module do. What inputs does it accept. What outputs does it produce. If any tests, read them before the implementation. Tests often describe intent more clearly than the code itself.

Reconstruct Intent, Not Style

Your job is to reverse engineer decisions. Why is this cached. Why is this retried three times. Why is this validation duplicated. Sometimes the answer is technical debt, to put it nicely, or maybe a production outage from two years ago that nobody documented.

Look at commit history if you can. A commit message like *hotfix for payment link* explains a strange guard clause very quickly. In other words, context turns weird code into defensive code.

Map the System Before Judging It

If the codebase is large, do not read it file by file in order. Trace one real user flow. For example, follow what happens when a user signs up. Start at the controller or handler, move into the service layer, then into the database call. You are building a mental map.

Draw it if you have to. A simple diagram of the control flow can show whether the structure is chaotic or just unfamiliar.

Separate Taste From Risk

Not using your favorite framework is not a risk. Long variable names are not a risk. Tabs versus spaces are definitely not a risk.

Real risks look more like missing input validation on external data. Hard-coded credentials. Database queries with no bounds. Those are operational problems, not stylistic differences.

When you feel irritation (which will happen), ask one question. Is this dangerous, or is it just not how I would do it. In other words, is this about correctness and safety, or about preference.

Use Small Experiments

If something is unclear, don't speculate yet. Write a tiny test. Log the value. Run the function with controlled input. Treat the code like a black box and observe it. I bet you'll learn faster than by staring at it.

This is very useful in legacy systems where comments can be outdated. The runtime behavior is the truth. Everything else is storytelling.

Document as You Go

Create a short internal note explaining how a subsystem works in plain language. Just enough so the next person doesn't have to decode it from scratch. If you can't explain it clearly, you probably don't understand it yet.

That next person might be you in six months.

When You Finally Refactor

Only touch structure after you understand behavior, constraints, and risks. Small, safe changes. Add tests around fragile areas first. Then simplify. Then rename. Large rewrites feel heroic but can create new bugs.

TL,DR: get the specifics first, then have opinions.