The Bug That Taught Me How to Debug Real-World Systems

When you’re starting your career as a developer, you arrive armed with tutorials. Hundreds of them. In everyone, a calm person types some code. It works first try, and they say, “and that’s it!” like a magician who’s never had a rabbit bite him.

I was a few steps into my career, feeling confident, when I met my first real bug.

Groundhog Day, But with Legal Paperwork

We run a web app where users sign up and tick a box saying they’ve read about the privacy policy. (They haven’t. Nobody has. Not even the lawyers who wrote it.)

Then a bug report came in: users who’d ticked the box were getting sent back to the privacy policy on their next login. Box unticked. Like it never happened.

Imagine signing a form at reception, coming back the next day, and the receptionist sliding the same form across the desk with a smile. Every day. Forever. That was our login page, and it had the energy of a very polite horror movie.

As the new person on the team, I thought, “I’ve got this.” Reader, I did not have this.

Suspect #1: The Capital Letter

I found a bug within an hour. When users signed up, we saved their email in the lowercase. When they logged in, we searched using whatever they typed. So “Bharathi@” and “bharathi@” were, as far as our system was concerned, two different humans, and one of them had never consented to anything.

Case closed! I fixed it, deployed it, and leaned back in my chair like Sherlock Holmes on his first day.

The bug was still there.

Turns out I’d arrested the wrong guy. He was guilty of something, just not this.

Lesson: finding a bug is not the same as finding THE bug.

The Empty Box

So, I stopped guessing and looked at what the server sent back when a logged-in user asked, “What do you know about me?”

It sent back {}. An empty box.

No error or crash. Just a confident, cheerful nothing. Like asking your bank for your balance and hearing the teller whisper ”…” before hanging up.

The user’s data was sitting right there in the database. It just never made it out.

Lesson: follow the data. Your gut has never read the codebase.

The Culprit: Five Letters

Our server has a security guard. It checks who you are, then shows you only your stuff. The guard also had a VIP shortcut: “If this is an internal system account, wave it through.”

Some time ago, someone upgraded that VIP check. Instead of knowing the list by heart, the guard now had to go look it up. In code, when you look something up, you have to write await, meaning “wait for the answer.”

One place forgot the await.

So, the guard would ask a colleague, “Is this person a VIP?” The colleague would say, “Hang on, let me check…”, and the guard, not waiting for the rest, would go “Sounds like a yes!” and wave them through the VIP door.

Everyone got the VIP door. Every single person.

The twist: the VIP door skipped the step where the guard writes your name on a badge. So, everyone walked in without a badge, and the rest of the system looked at them and said, “Who are YOU? You get nothing.”

We accidentally built the most secure system on earth. Nobody could see anyone’s data, including their own.

Days of my life. Five letters. No tutorial had ever warned me about this.

Lesson: small changes to ripple. Moving one chair can knock over a vase three rooms away.

Bonus Bug, Because Of Course

While I was in there, I found a “verified account” flag stuck on “no” for every user, even verified ones. The check behind it was failing, and instead of complaining, the code just shrugged, wrote “no,” and went on with its day. No error or log. Nothing.

A crash at least screams at you. A silent failure is the coworker who breaks the printer and quietly walks away.

We made it log a warning when it fails, and added a little self-heal that fixes the flag the next time a verified user logs in.

Lesson: make failures loud. Future you deserve a clue.

The Moment of Truth

We deployed. I logged in as a test user. No privacy policy. Straight to the dashboard, like a normal website made by functioning adults.

I made a noise. We don’t need to talk about the noise.

What Tutorials Don’t Teach

1. The first bug you find is often just an opening act.
2. Stop guessing. Look at what is actually happening.
3. When you change something, check everything that relied on the old version.
4. Silent failures are liars. Make them talk.
5. It’s not fixed until it’s fixed in the real world.

At the start of my career, I thought being a good developer meant writing code that works. This bug taught me it’s mostly about figuring out why code doesn’t work, calmly, while it smiles at you and hands you in an empty box.

Sometimes a week of chaos comes down to one missing word. I find that either very comforting or very terrifying, depending on how much coffee I’ve had.

To every user who agreed to our privacy policy four times in a row: thank you. You’ve officially read it more than anyone alive. And to the bug: thanks for the lesson. Please never come back.