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:
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.
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.
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.
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.
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.
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!