Debugging Tips for Hackathons

Erin McKean
IBM watsonx Assistant
3 min readSep 19, 2017


I spent this past weekend at the Mobile Monday Hackathon, talking to people about LoopBack and helping folks debug their applications. I had a great time and really enjoyed seeing so many interesting and useful projects!

I love helping people get unstuck with their projects, even if I’m just acting as a rubber duck. But as I’m just one person, and there are usually a LOT of hackathon participants, I can’t help everyone … so here are a few tips you can use to help yourself at your next hackathon!

Rubber Ducky Alone CC-BY David Michalczuk

Question your assumptions

If your code is not behaving the way it ought to, it always helps to step backwards and make sure everything you believe to be true actually IS true. For example, I was working with one person whose API wasn’t returning the expected results—they were getting an empty set, and were (understandably) very frustrated!

The code itself looked fine, so by “stepping backwards” we were able to figure out that the configuration file had the wrong connection string for the database. In another case, a coder was not getting the expected behavior from a command-line tool, and it turned out to be an issue with NodeJS itself—or rather, that the user’s PATH didn’t include Node.

A question you can ask yourself: What would have to be true for me to get the results I’m seeing now? (Note: the answer to that question is almost never “massive sunspot activity”.)


The very first thing you should do when you get an error message that you don’t understand is Google it (or Duck Duck Go it, or [insert your search engine of choice here] it). It is highly, highly unlikely that you are the only person in the history of software development to run into this particular problem or error—you should definitely learn from other people’s mistakes!

You’d be surprised how often the fix for any particular error message is in the very first StackOverflow link.

Trust, But Verify

It may seem dumb, but it never hurts to shove a few console.log or break statements into a long function to make sure that your variables are what you think they are. You’d be surprised how many ‘undefined’ variables can creep into your code … especially when you’ve been cheating on sleep and binging on sugar and/or caffeine …

Take a Break

It may seem that you don’t have time in a hackathon to take a rest, but if you’re stuck, that’s exactly the right time to take a deep breath, go for a walk around the block, do some stretches, grab a glass of water, or even find a quiet corner for a twenty-minute nap or a session with your favorite meditation app. (Sadly, most hackathon spaces don’t provide the ultimate in have-a-mental-breakthrough solutions, hot showers.) You will almost certainly come back to your show-stopping bug with fresh eyes, and find out that it wasn’t a showstopper, after all.

Don’t Apologize!

If none of the above tricks works and you find yourself asking me or another person on the hackathon support team for help, don’t apologize! We’re at the hackathon because we like helping people with their code and we enjoy solving problems. Even if I don’t know the answer to your particular question, I welcome the opportunity to help you find the answer and to learn something new myself!



Erin McKean
IBM watsonx Assistant

Founder, Recovering lexicographer. Full Stack-Overflow Developer. Developer Advocate, IBM.