What My Internship Taught Me About Understanding and Debugging a Codebase Before Touching It

My first week at the internship, I opened the codebase and immediately found a function that looked... wrong. There was this huge nested conditional that seemed like it could be flattened to three lines. I was excited. I thought: *this is how I'll show I'm useful.*

I refactored it. Clean, readable, elegant. Pushed it to a branch and shared it with my mentor.

He looked at it, was quiet for a moment, then said — *"That conditional was handling a timezone edge case that only shows up in certain regions. We spent two days tracking that bug down six months ago."*

I had no idea. The code looked ugly, but it was carrying a scar.

That was the moment I understood something I hadn't been taught in any course: **a real codebase isn't just code. It's accumulated decisions, past failures, and constraints you weren't there to witness.**

---

Reading Code Like an Archaeologist

After that, I completely changed how I approached the codebase. I stopped trying to fix things and started trying to *understand* things first.

I'd open a file and instead of asking "can this be improved?" I'd ask "why does this exist?" I started tracing where data came from, where it ended up, what triggered what. The folder structure, the entry points, how services talked to each other — I treated all of it like a map I was trying to learn before going anywhere.

It sounds slow. But it actually made everything faster. Because once you understand the territory, you stop making wrong turns.

---

Debugging Changed How I Think

The real shift came when I stopped seeing bugs as interruptions and started seeing them as *invitations*.

Every bug I was given was basically the codebase saying: here's something you don't understand yet. And debugging it properly — actually reproducing it, watching values change, following the network calls, tracing state step by step — taught me more about the system than reading docs ever could.

There's a huge difference between reading code and watching code run. I used to think I understood a function because I could read it. Then I'd set a breakpoint and realize the values flowing through it were nothing like what I expected.

Debugging killed my assumptions. And that was exactly what I needed.

---

The Rule I Now Live By

Somewhere around week four, my mentor told me something I've repeated to myself ever since:

"If you can't debug it, you're not ready to refactor it."

It sounds simple. But it's a high bar. It means you need to be able to explain the flow, predict how changes will ripple through the system, and know what failure looks like. Until you can do that — you're just guessing.

Once I hit that threshold on a part of the codebase, my changes got smaller and safer. I stopped rewriting things and started making one careful change at a time, watching what happened, then moving on.

---

Asking Instead of Assuming

The other thing the internship taught me: ask more questions.

Not "I think this is wrong" — but "is there a reason this works this way?" Most of the time the answer was yes, and the reason taught me something. Even when the answer was "no, that's actually a bug" — asking first meant I went in with context.

Junior developers tend to assume they see the full picture. The internship cured me of that fast.

---

I came in thinking I'd prove myself by writing impressive new code. I ended up learning that the most valuable thing I could do was deeply understand what already existed — read it carefully, debug it patiently, change it only when I was confident.

That's the thing nobody tells you about working in a real codebase: understanding it *is* the work.