How software bugs made me a better person

Have you ever been in a conversation with a developer where you have to communicate to him that his software has bugs?

As a developer, one of the core functions is to interact with QA, managers and support staff but I swear, most developers think that the letters QA means querulous assurance and not quality assurance.

They all think that QA’s main function is to point out, complain and whine about how “buggy” their code is and to tell them how to code the software in a better way.

In this blog post I’m going to share how software bugs made me a better person and how it might influence you too.


“Failure is a much more faithful teacher than immediate success” ~ David Duchemin

As much as we love the idea of perfect “bug-free” software we all know that no piece of software is immune from bugs.

As a matter of fact, you may have the best scrum methodology and practice in place and the world’s smartest programmers, but all software developers know that bugs are inevitable. Especially with complex projects. However, most agile organisations utilize some sort of bug tracking tool to record and keep a track of defects.

There may be numerous causes for a defect that is, misunderstanding of requirements, miscommunication of user requirements and software requirements or just simple coding errors. Consequently, in order to improve coding defects, you first need to learn what the defects are and its effect on the users of the software.

In other words, finding a bug can be a positive feedback mechanism whether or not you (the developer), QA or the end user are the one that finds the bug, each reported bug can teach developers something new but in order for you to learn, you have to first, take the time to review each bug.

One of the great things in software development is that you are always learning and there is always room for growth. Your feedback tools if utilized correctly can provide useful information to improve defective codes, testing and debugging techniques, however, to accomplish this, feedback gathered should be taken in a positive and constructive manner.


Apart from coding, debugging and testing your software, as a developer one of your core skillsets should be that you are an effective communicator.

In a typical software organisation, the QA department works closely with the development department.

During my years in web development, I have found some developers are aren’t the best communicators.

I attribute this to the fact that most of our time is spent coding and learning about new technologies.

We’re problem solvers, and we like solving our problems ourselves. That usually means we simply stop communicating with other team mates.

This is unfortunate, because the software development process itself requires that there’s a regular flow of communication to keep all the aspects of a project running in line. These inter-team interactions require other people to review code and designs, write specification documentation, make weekly presentations and communicate with the QA.

Everyone has a part to play and that means that we can’t possibly be a successful team if we’re not communicating.

As you appreciate the QA process, tracking bugs requires you to become better at communicating.

That is, over time, you will notice that because of the constant dialogue meetings with the software development team (including QA team), you will find yourself better being able to understand the language of the users and answer their question effectively. And that’s just it, right?

You’re writing this software for others, so understanding how they think is crucial to your success and the application’s success anyway.


If we approach bug tracking in a more positive and constructive way, we will discover that although it may be annoying and frustrating to be fixing errors, in the end, it actually pushes us to learn.

It pulls us out of our comfort zone.

But how did tracking bugs push me out of my comfort zone? Let me introduce you to my three reasons:

  1. Tracking bugs has caused me to discover new skills that made me look at problems from another angle.
  2. Tracking bugs made me ask thought provoking questions such as: Why did the user do it? And what did they do to get it?
  3. Tracking bugs allowed me to recognize what is vital and what is incidental. It forced me to focus on core features and use cases, not just features and applications.


Let’s say the requirement specifications states that you should give the users the ability to print daily receipts from the system.

As a result, you developed an application to print the number of receipts created by a cashier per day. You created a “Print” icon for the user to print the receipts. However, one day you receive a bug report that states that whenever the user attempts to print the receipt, it crashes.

Vague as it is, you’ll need to do more investigating. Bugs are like criminal cases!

You try out the software, and see nothing wrong. Then, you look at what the user was doing before that.

Instantly, to do this investigation, you had to think and act as the user and understand how they use it.

You have to understand their process. If you don’t, you’ll see that your software works perfectly in a lot of cases, just not how the user expected it to work.

There’s a side effect too. You actually start to code with the users in mind.

As a result, you’ll begin to think like an accountant for accounting software, think like a doctor for medical software. Not only are you taken out of your comfort zone, but you’re also thinking as one of the specialists who will be using your software.

Martin Golding stated it perfectly:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

In other words, it is imperative for developers to view their software from a different point of view other than their point of view.


So I conclude my article in saying that, to make software bugs work for you is a matter of how you see the glass, “half full or half empty”.

For me; I began to allow bug tracking to work in my favor. I started to see bugs like criminal cases.

Be the new Sherlock Holmes in software development.

When I am faced with a bug, I put on my detective face, pull out my detective glasses, and start looking for clues. It becomes a game, one where I need to solve a puzzle and I love me some games!

Written by Thomas Peham from Usersnap. Usersnap is a visual bug tracking and feedback tool for every web project used by software companies like Facebook, Google & Microsoft.

Interested in more articles like this?

To better understand your colleagues and clients, check out this study on how developers and designers collaborate with clients.