Rubber Duck Debugging and 10 Debugging Tips

Debugging, as the web refers to, is the process of identifying and removing errors from computer hardware or software. It lets you track down that error.

When I started software development, I became familiar with the term of “rubber duck debugging” which is the process of walking a rubber duck through your code step-by-step which can often lead you to find bugs you were overlooking before.

Stuck while writing the code > Grab rubber duck > Explain code to Duck > Problem Solved!

In my career life as a software enthusiast, I had some series of debugging scenarios. Sometimes we miss placing semicolon or an open bracket. Often we get common error messages like

IndexError: list index out of range, object not set to an instance of an object and others.

We all face bugs in our careers as developers. Throughout mine, I’ve learned a couple of tricks I thought I would share for people just entering the industry. It’s easy to get overwhelmed when facing a bug, but keep calm, remember these tricks, and know that we all have to face these.

1. If you have an error message, read the error message. 

Indeed, it’s obvious, but this has been a struggle with me when I was starting to code. I get prodigious whenever a bug or error comes. But I found the key not to be overwhelmed but to take a deep breath, calm my mind, and read the error message. Take time to understand that heap trace, and you might find a clue or hint about where to start debugging.

2. Invest in setting up your environment to run in debug mode early on. 

I was working with Infor EAM with SQL as backend. I started installing the application in my local machine to easily debug by using breakpoints so you can walk through the code and find out where the bug is. I’m sure you’ve used this, but it’s still one of the tips.

3. Make sure you can control input data. 

Whether it’s setting up your database in a particular way or mocking an endpoint, I could insert mock data into my database and front end state to control the user state. I always put in the effort when first working in an application to understand how I can manipulate my data so I can easily control it. You might know how to seed data in the database. In this case, you can reproduce many different states of your application quickly when you need to understand what is causing the bug

4. Understand what changes between different environments.

Most applications use environment variables to control particular variables in your application, depending on whether it is running in places like development versus production. It is useful to understand what is different within your application between those environments as you are debugging since it is possible that a separate environmental setting is causing a bug to be hidden/come out.

5. Reproduce the bug. 

To figure out what went wrong, it almost always will help first to reproduce what went wrong in a test environment. From there, you can start walking through the code and understand what part is causing the issue. If you cannot reproduce it on the test, follow the workflow, and understand which stage or a part it went wrong. Your goal here is to reproduce the bug in your test environment or on your local machine. 

6. Go back to previous versions and see if the code works there.

Sometimes if I’m trying to track down a bug, I’ll check out the earlier version of the code until I find a commit where it is working as intended, then I work my way back up to the bug. This is particularly helpful if you’re trying to track a new bug in the code you’re not familiar with. I like to pick a reasonable starting point, and then binary search in days back up until I get the one commit where things broke.

7. Make small changes and rerun your code each time. 

Sometimes you think you’ve found the bug, so you change something small to see if it fixes it. I recommend going a small change by small change so you can quickly understand what fixed it. Or else, you can get to a state where so much has changed, and you don’t know what fixed the bug or not!

8. Check logs. 

If the bug is in production only, you might need to rely on some helpful logging to get more information. There are server logs that are save in the environment folder that you can check. 

9. Get help from someone.

Sometimes just having an outside perspective can help you realize obvious things to look into that you missed.

10. Take a break.

Taking a break is another solution for that obvious bug. There are times when I just closed my eyes and rest for a while and after that, the solution is right there. This is helpful with smaller bugs to get the solution quickly.

By explaining your program to a duck, you often magically find the flaw in your code. Because of the psychology of how we humans relate, you’re forced to think fresh when you invoke your little rubber ducky, and your problem may be quite simply solved. I hope it works for you!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.