A null check I forgot, a user who found it, and a senior engineer who taught me more in ten minutes than I'd learned in a week.

#Debugging #Production #Junior

The Bug

My first production bug was a null reference error in a form submission handler that I had written two weeks earlier. The form worked perfectly in testing because every test submission included all the fields the handler expected. A real user, however, submitted the form with an optional field left blank, and the handler tried to access a property of null, throwing an error that crashed the submission and left the user staring at a broken page. The bug was trivially simple — a missing null check that would have taken thirty seconds to write — but the experience of having code I wrote break for a real user was one of the most instructive things that happened to me in my first year.

The senior engineer who helped me fix it didn't lecture me about null checks. Instead, he walked me through the process of reproducing the bug locally, identifying the root cause, writing a test that would have caught it, and then making the fix. The entire process took about twenty minutes, and the actual code change was three lines. What stayed with me was the methodology: reproduce, diagnose, test, fix — in that order. I had been trying to fix the bug before I fully understood it, which is a mistake I still catch myself making and still have to consciously resist.

The deeper lesson was about assumptions. I had assumed that the form data would always include every field, because that's how I tested it. Real users don't care about your assumptions; they interact with the software in ways you didn't anticipate, and the software has to handle those interactions gracefully or it fails. That lesson — "your tests are only as good as the cases you thought to test" — is one that every developer learns eventually, and the ones who learn it from a benign null check rather than from a data-loss incident are the lucky ones.