Assume It's Load-Bearing
The previous post was about what a handoff loses: the reasons, the near-misses, the one oddly-shaped customer who made a conditional necessary. This one is about the other side of that transfer — you are now holding code whose justifications did not come with it, and you have to change it anyway.
Two Bad Defaults
The first bad default is to assume the weirdness is accidental. Someone was sloppy, someone copy-pasted, someone never cleaned up. Under that assumption every strange line is an invitation, and you tidy your way straight into an outage six weeks later.
The second bad default is the overcorrection: treat everything unexplained as sacred and refuse to touch it. This feels responsible. It isn’t. It converts every inherited system into a museum, and the cost compounds — each generation of owner adds a layer around the parts they were afraid to open, until the thing nobody understands is most of it.
Both defaults share the same flaw. They are ways of deciding without finding out.
Making Absence Legible
The useful move is to convert “I don’t know why this is here” from a vague feeling into a specific, answerable question. That is cheaper than it sounds.
Run git log -S on the strange line. You are not looking for the commit message — those are usually useless — you are looking for what else changed in the same commit, and what the branch or ticket was called. A timeout bumped in isolation, on a Saturday, is an incident artifact. The same timeout bumped alongside a new integration is a design choice.
Look at the tests. Not whether they pass — whether one of them was written specifically to pin this behavior. A test that asserts the weird thing is a message from the past saying yes, on purpose.
Look at who is calling it, and with what. Half of “why is this here” questions answer themselves once you see the one caller that passes the unusual argument.
Half an hour of this typically sorts inherited weirdness into three piles: this was deliberate, this was accidental, and this is genuinely unknown. Only the third pile needs a decision under uncertainty, and it’s usually small.
The Third Pile
For what’s left, the honest approach is to change it in a way that tells you if you were wrong, quickly and cheaply.
Don’t delete the suspicious retry — make it log when it fires. If it never fires in a week, you have evidence. If it fires forty times a night, you just learned what it was for without anyone paging you.
Don’t loosen the mysterious timeout to the value you think is right — move it partway and watch. Don’t remove the conditional — invert it into an assertion that alerts instead of failing silently.
Every one of these turns an assumption into an observation, at a fraction of the cost of finding out through an incident.
Leave the Answer Behind
When you do figure out why something was there, write it next to the thing before you move on. You are the only person who will ever have both the code and the reason in your head at the same time, and that state lasts about a day.
The handoff dropped context because nobody realized they were holding any. You now know exactly what it feels like to receive that. The person after you gets a better version or the same one, and the difference is a comment you write while you still remember.