Taking over another developer's code without breaking what's live

A good part of my work doesn't start in an empty folder. It starts in a system that's already live, with customers using it, sometimes with money flowing through it, and with the previous developer out of the picture.

It's a different job from writing from scratch, and the biggest trap is treating it as if it were the same. Whoever arrives and rewrites everything doesn't deliver faster: they deliver a second broken system next to the first one.

Day one is for reading. I get the project running locally and try to reproduce the main path end to end: sign-up, login, the operation that makes money and whatever happens after it.

Meanwhile I keep two lists. The first is what I didn't understand. The second is what scared me. The second one is what matters: it sets the order of the work.

The pattern I find most in inherited systems isn't ugly code. It's swallowed errors: the route does its job, some step fails halfway through, and the response comes back as if everything went fine.

It happens for an easy-to-understand reason. Someone, at some point, got tired of seeing errors on screen and wrapped that stretch in a block that catches everything and moves on. The system stops complaining and everyone thinks it got better.

Except now the problem has moved: instead of showing up right away, it shows up at the end of the month, during reconciliation, when the numbers don't add up. In a payment gateway, that's the difference between a bug and a loss.

I look for three things, in this order. First, every place that catches an exception and does nothing with it: that's where the error is buried. Second, every success response that doesn't check whether the previous step really happened. Third, logs: if there are none, the system is a black box and any fix is guesswork.

Before fixing anything, I make the error visible. Structured logs with the operation's ID, and failures bubbling up instead of disappearing. It's usually uncomfortable, because suddenly the system starts shouting about things that had been happening silently for months.

The urge to reorganize everything is strong, and it's the wrong moment. First I close what's leaking: the routes that lie, the data that comes in without validation, the money that changes state without a record.

Refactoring comes later, and in pieces, always behind something that already works and is tested. The client doesn't pay for pretty code, they pay for a system that stops causing problems.

Every developer who takes over someone else's code feels the urge to propose a rewrite. I've felt it, and a few times I proposed it badly.

The ugly system that's live carries years of business rules nobody documented, and a good part of them hides in an odd condition in the middle of a function. Rewriting means rediscovering all of that at the cost of losses, one upset customer at a time.

A rewrite pays off when the technology blocks the next step, not when the code is ugly. Ugly gets fixed piece by piece, without switching off the lights.

I come in with my own access and an environment separate from the existing one, so my work never mixes with the other developer's. I map the risks, close what's leaking, and only then move on to what you want to build.

If you have a live system and the developer disappeared, that's exactly the service. Message me and I'll tell you what can be saved.