Whenever your code breaks, what do you do? Do you get angry or frustrated? Or does it pique your curiosity to find out why it’s not working?

During my first two years of software development, I wrote a lot of code to get into the habit, practice my muscle memory, and build as much as I could. I wanted to become good enough so that a company would hire me as a fulltime developer. 

I remember that every time code broke, I got super upset. It felt like an insult to my skills that I couldn’t produce well-working code (yet!). 

Asking the right questions

The first time, I was just upset. How could I have not been smart enough to write this well in the first place? I stared at the code until it started to make sense. Sometimes, I did find out what went wrong. But often, I had no clue. I ran into a brick wall over and over. 

It only stopped until I started to ask different questions. 

• Why did this error occur?
• What did the user do that I didn’t take into account?
• Did they click somewhere unanticipated? 

I put myself into their shoes, looking at the problem from their perspective. Often, it turned out that I either completely missed an essential aspect of a requirement, or users used the application in a completely different way. To get into that mindset, whenever possible, I sat next to the user and had them show me what they’ve done to produce the error. If that weren’t possible, I’d ask them to list all steps they’ve taken to reproduce the issue. 

Now, handling errors became much more manageable. Also, it taught me to pay a lot of attention to user requirements and ask questions to find out edge cases and usage patterns.

Only failures lead to progress

Additionally, all of these mistakes were good for something. Over time, they influenced my programming style. Whenever I wrote code that handled user input, I wrote code that’d handle eventual empty fields or invalid data directly so that the following code could work with guaranteed valid values. So, only over time and after a lot of mistakes, I started to produce more high-quality code. It wouldn’t fail in the same way as before, that was a big win. But now, it’d fail in different ways I hadn’t anticipated. And that’s always part of the journey!

What are your experiences? What is your approach when dealing with software errors? Comment below!