Trusted answers to developer questions

Strategies for solving bugs

Get Started With Machine Learning

Learn the fundamentals of Machine Learning with this free course. Future-proof your career by adding ML skills to your toolkit — or prepare to land a job in AI or Data Science.

As a developer, you probably have been frustrated at one point or another because of a particularly annoying bug. Some devs get frustrated daily. That’s extreme for sure. Frustration has its effects, usually short term. Here are a few of them:

  1. Loss of motivation to go further
  2. Many hours lost trying to track the given bug
  3. Going to bed with anger
  4. Impostor syndrome for not being able to fix a bug

I’ve experienced all of these and possibly more; some don’t apply once you’re a senior dev. One thing I certainly enjoy is the euphoria of fixing a bug or getting the implementation right.

Limiting the frustration

Different people have different strategies for limiting their frustration. These strategies are context-based, meaning that they don’t work for all types of bugs.

  1. Some people sleep on the bug and have it fixed when they wake. This is by far the most popular, although its effectiveness is something to consider.
  2. Most times, the easiest way is to google the problem. The wealth of dev knowledge on the internet ensures that your bugs get fixed within minutes, and your frustration level stays low.
  3. One thing I recently discovered is that at a point, most of your bugs won’t be a very big problem. Instead, they’ll be silent imps sent to ruin your day 😂. They are usually subtle things that you can’t catch for some reason.

An example of the third point is this; most times, when I follow tutorials, documentation, or blog posts, I do so to implement something in my own code. I rarely take the tutorial as it is. However, trying to play smart like this does have its gotchas.

Recently, I was picking up Flask and SQLite from this site. The tutorial gave a code snippet, which I blindly copied (to save time 😉). This was the snippet:

import sqlite3


def drop_table():
	with sqlite3.connect('songs.db') as connection: #made an error here
		c = connection.cursor()
		c.execute("""DROP TABLE IF EXISTS songs;""")
	return True


def create_db():
	with sqlite3.connect('songs.db') as connection:
...

The snippet was written with the assumption that the songs.db file was located at the root folder, but mine was located in a db folder. So, running the code above produced nothing. This was what I was meant to do:

import sqlite3


def drop_table():
	with sqlite3.connect('db/songs.db') as connection: # change occurred here
		c = connection.cursor()
		c.execute("""DROP TABLE IF EXISTS songs;""")
	return True


def create_db():
	with sqlite3.connect('db/songs.db') as connection:
...

The bugs that resulted weren’t thrown by the interpreter. They were subtle and silent. They occurred due to carelessness.

So, I learned, or relearned, a lesson on copying code and doing things on my own terms. If you are doing things on your own terms, be careful to prevent path errors or missing symbols.

Missing symbols

So, I just talked about path errors. Now, let’s review the problem of missing or extra symbols, which is another thing to think about when you’re writing code that will run on a different environment. Another personal experience here:

I was working on an Express project. My API endpoints were meant to be tested on a test runner called Gradr (feared by many, not sure if anyone likes it 😪). Everything was working on my own end, but the project failed on the server. It failed because of an extra forward slash “/”. So, my API was being misread as some-link.com//json instead of some-link.com/json and returning a 404 error. It just returned 404, no explanation.

So, what have I been saying so far?

To keep your frustration level low, you have to limit the number of bugs you create for yourself. To limit the number of bugs, you have to have an anti-bug checklist in your brain. Sometimes, writing about your bug helps you remember it in the long-term. This means that you won’t need to fall for it next time. This checklist grows with experience – to really increase the number of checks on the checklist, you have to stretch yourself.

Asking the deep questions

Another strategy for solving hidden bugs is asking the hidden questions. If I asked myself why I was getting a 404 error, I’d have figured out that the server was posting to the wrong endpoint. Then, I would have rechecked my endpoints, both the root and the extension.

TL;DR

  1. Google your bugs before going to bed. This ensures greater productivity.
  2. Take ‘going to bed’ as the last resort.
  3. Have a mental or physical anti-bug checklist.
  4. Write about the bug; it helps you remember and prevent them.
  5. Ask a deep question about the bug instead of freaking out.

Extra

Andela usually has a way of stretching developers yearly. I have been participating in Andela related challenges over the years (2 actually). I don’t know how they do it, but many people participating feel the need to complete the challenge by all means. It’s usually different from hackathons on Devpost, where you can bail if you’re tired of it all. I’m dedicating this post to Andela. For all the wonderful things they do for the developer ecosystem in Africa.

Please share this article if you found it helpful. What strategies do you undertake to keep your frustration level low? You can follow me on Twitter, and share them!

RELATED TAGS

productivity
bugs

CONTRIBUTOR

Osinachi Chukwujama
Did you find this helpful?