I’m almost done with @VerbalInfusions, a project that generates parody herbal tea descriptions and posts them on Twitter. And today I’m one step closer to finishing the project than I was yesterday. Let me tell you a tale of how in ten minutes, one debugger turned discouragement into delight.

I built Verbal Infusions with a cool library called tweepy. Remember how we discussed server requests in the last post? You can think of an API as a set of commands that create server requests to communicate with a website. Websites like Twitter often have their own custom APIs. So when developers like me want to build projects like Verbal Infusions, we have to deal with Twitter’s API rather than our programming language of choice (e.g., Python). Unless, of course, a developer takes it upon themselves to write a library to translate the API into Python, which is exactly what tweepy does.

When I first built the project, it seemed to be working perfectly! Except for one problem: when I tried to publish a status to Twitter, there was an authentication error.

When an error like this arises, and I don’t immediately recognize what to do, my first thought is usually to Google the error to see if someone else has solved a similar problem. So I did. I found some solutions, but none of them seemed totally relevant to my situation.

At that point, I had a few things to consider:

1. There could be a problem with my code.
2. There could be a problem with the library I’m using.

Some of the posts online suggested that this error arose when Twitter changed their version of the API, so I decided to check to make sure that tweepy was up-to-date. It was.

The next step: check to see if I’d installed the most recent version. I had.

At that point, I needed to start delving into the source code to figure out exactly where the authentication went wrong. Usually when I’m trying to find a bug, I put a lot of print statements in my code to figure out what’s going on. This process is called logging. And it had worked fairly well for me up until that point. I spent some time looking over it, which was helpful for understanding how the wrapper worked, but still didn’t give me a great idea of where the problem might lie. Clearly logging was not going to help with this problem that might or might not be related to an outside library.

To be honest, Athena, by then it was getting late and I was frustrated with the whole thing. So I stopped working for the night and watched Gilmore Girls.

The next morning, the bug remained, and I still didn’t know where the authentication was going wrong, so I tried something I’d never done before – I installed a debugger. My debugger of choice was ipdb, which is described really nicely in this blog post. To use this debugger, you include a line in your code that sets a trace. When the code gets to the trace, it stops running and waits for you to give a command.

You can give commands to print all variables the code sees at that point in the execution (pp locals()). You can give a command to execute the code one line at a time (n). You can type any object name and see every attribute that object has. It’s amazing.

With just a little bit of digging, I found that my problem was really straightforward to fix! I’d just mixed up my API key and API secret (analogous to a username and a password) when I was reading in the file that contained them. One quick fix later, and I had a functional Twitter Bot!

Moral of the story: WHY HAVE I NEVER USED A DEBUGGER BEFORE. This was a life-changing experience. If all my bugs get solved at this rate, this one tool is going to make me a 20x more productive programmer, and a 100000000000x less frustrated one! My advice to you, Athena: use a debugger in your code. It makes everything better.