How to Debug Python Code You Didn't Write

You open the repository. Nobody who wrote it still works here. There are no tests. The one README file describes a feature that got deleted two years ago. And something is broken in production. Welcome to the job. Debugging code somebody else wrote is one of the least talked-about skills in software engineering, yet most of us spend more time doing it than writing anything fresh. The hard part is that you have no mental map of how the thing works. Python makes this trickier than most languages, because its dynamic typing, runtime metaprogramming, and loose scoping rules mean the code can behave in ways the source doesn't obviously reveal. So before you touch a single line, slow down. Here's a field-tested sequence for making sense of a Python codebase that feels like someone else's messy garage. First, Pin the Ground You're Standing On Legacy Python projects love to rot at the edges. You'll find an unpinned requirements.txt , a couple of setup scripts that contradict each other, and zero record of which Python version the thing actually ran on. Fire it up on the wrong interpreter and you get phantom defects: crashes caused by a minor version mismatch or a dependency that silently updated itself into incompatibility. Lock everything down first. A tool like uv resolves a reproducible dependency tree fast and writes a deterministic lockfile, so you're not fighting drift from upstream packages that moved on without you. If the project straddles a big historical gap, say a Python 2 to 3 jump, pin the exact interpreter with pyenv or run it inside a container. Get a stable environment before you try to reproduce anything. Everything downstream depends on it. Find the Front Door New codebases tempt you to read widely. Resist that. Opening thirty files and skimming each one gives you almost nothing except a headache. Pick one real transaction instead and follow it all the way through. A single incoming request, one task, one command. Trace it from the outside edge down throu