5 Tips That Will Help You Find That Bug

Programming can be quite a roller coaster. There will be times when everything goes well, the code flows out of your fingertips and compiles and runs how it’s supposed to. But there will inevitably also be situations where your program just doesn’t do what you want it to do and the error seems impossible to find. You encountered a bug.

When your app crashes, you can usually read the stack trace and from there quickly figure out what piece of code at which line caused the crash. Those are often just simple mistakes that are easy to solve. But things get really tricky if your program does work, but just not the way you want it, like returning a wrong result from a calculation or executing something at the wrong time.

In my short programmer life I had some situations where I thought my Android Studio, my emulator or Android itself was broken. I could swear my code was correct, but it misbehaved in ways that were incomprehensible to me. Of course Android was not broken, my code just had errors. But the bugs were so subtle and hidden that it was very hard to figure out what was wrong. And those were not even big programs, but small hobby projects. Hunting a nasty bug in a big code base can be a completely different challenge.

When you are stuck like this, just sitting there and trying to figure it out with sheer brain power can seem impossible. Luckily, there are some other actions you can take to solve these real world puzzles, and some of them are rather unconventional.

Before we take a look at these steps, make sure to read my “How to Use Google to Solve Your Programming Questions” blog post first, because there I talk about some tricks I use to find what I am searching for. This might also help you figure out your bug.

However, if you still can’t find the error, here are some things you can do to get unstuck:


First of all, take a deep breath

Coding and computer problems can be quite frustrating, but you will most likely get to a solution earlier or later anyways, so stay calm. You are more efficient if you don’t get mad, angry or impatient. Close your eyes, take a deep breath, accept your negative emotions and remind yourself that every problem is an opportunity to grow and learn. If you never get stuck, it just means that your challenges are too easy for you.

So take a deep breath right now. Are you relaxed? Great! Let’s get to the next step.


Use the debugger

A debugger is a tool that lets you stop your code at certain breakpoints, examine and modify variables and program state at runtime, execute code line by line in your own pace and other cool stuff that will help you find out what is wrong.

Most modern IDEs have a debugger implemented by default. I recently started to learn how to use the one that comes with Android Studio (IntelliJ IDEA), and even though it looks very complicated at first, it’s actually quite easy to use and super powerful, not only to find bugs, but also to better understand how your code works. As usual I condensed the knowledge I acquired in the learning process into a video tutorial, so you don’t have to go through the same tedious process. Click here to get to it. If you are an Android developer, make sure to watch this tutorial, because knowing how to use the debugger is something you can’t get around longterm. Seriously, go to the video right now and at least bookmark it.

The debugger is the most powerful tool on this list, but it’s no substitute for understanding the code. If you want to find errors, you need to have an expectation on what your program is supposed to do, and then compare it with the actual behavior. The steps below will further help you with this and the debugger should be used in conjunction with them, not as a replacement.


Ask for help online

Ok, this step might seem obvious, but bear with me. If you haven’t done it yet, state your problem in any of the numerous online programming communities. This way you not only get other experienced developers to take a look at your code, just the sheer act of writing down your problem and trying to explain it might already help you get to a solution yourself, because it forces you to go through your code in more detail and explain the expected and actual behavior without skipping anything important. This can bring logical errors to the surface that you didn’t notice before.

When we just ponder about a problem ourself, we tend to skip certain parts or don’t think them completely through, because they seem minor. While a debugger gives you the tools to go through each single line of code one by one and inspect every variable along the way in detail, it doesn’t force you to do it, which means you will still be inclined to skip some steps. However, these seemingly unimportant parts can be essential pieces in solving your problem and explaining your code in detail forces you to take a closer look at them.

But where should you ask your question? I have a separate blog post with a list of different awesome Android and general programming communities besides Stackoverflow, which you can find here.

But before you post in any of them, use their search functionality to check if a similar question has already been answered on the site before. Especially on Stackoverflow this will protect you from nasty downvotes and a possible ban. Besides that, I don’t think you should open a question for every small coding problem that you encounter, because it will get you into the habit of letting other people think for you. If you ask, keep in mind that others value their time too. A well prepared, short and specific question is much more likely to get answers than one which you didn’t even try to figure out yourself. So in my opinion the best approach is to research about your particular problem autonomously as thoroughly as possible, use the debugging tools that you have available and then only ask if you feel like you can’t get to the solution yourself. This will also help you learn much better than dumping every problem into an online forum and waiting for someone else to solve it.

Besides that, you are not guaranteed to find your answer online. If your problem is caused by some complicated bug that is very specific to your particular code, it’s unlikely that someone in a forum or even on Stackoverflow will dive deep enough into your project to figure it out. In those cases you will probably find the solution yourself first. Alternatively, you can ask a programmer friend or colleague.


Take a break

I usually do this step after I have posted my question online, because it will take a while until someone answered it (if someone answers it at all).

When you’re stuck, a break can help wonders. I don’t know what exactly in our brain is going on when we step away from a problem, but I know that the subconscious mind keeps working on it in the background. And this background processing can lead to insights that seemed impossible to figure out while we were actively trying to unravel the problem. This phenomenon of sudden enlightenment is also called the “Eureka effect” or “Aha! moment” and I am sure you have experienced it before. However, to get these spontaneous insights you first have to actively engage with the problem, so don’t take a break the moment you don’t understand something.

Of course you can spend your break how you like, but I think it is very beneficial if you do some form of physical activity in this time, because it helps your mind getting away from the problem without taxing it with another cognitively demanding task. Besides that, there are plenty of studies that have shown how exercise improves general brain health and therefore your thinking skills.

Programmers have the cliche of being in bad shape and unathletic, but I think that’s an unnecessary disadvantage, because a brain-intensive task like writing code fits perfectly well with sports. Don’t force yourself into stupid roles, you are not obligated to fit into a cliche. If you don’t want to do something exhausting, at least go for a nice, long stroll in the nature.


Tell it to your rubber duck

It might sound funny, but “rubber duck debugging” is actually a thing. Earlier I mentioned that asking your question online can get you to a solution before you even got any answers, because when you have to explain a problem step by step, you don’t skip seemingly unimportant parts like you do when you just think about it or work on your code all by yourself. To have this effect, it doesn’t really matter to whom you explain your code, because it’s about the act of explaining, not about the answer. So instead of asking other developers (and occupying their time), you could explain your problem to someone completely unrelated to programming. It could be a friend or family member that knows nothing about code, it could be your dog, or it could be – well – your rubber duck. In fact, explaining your code to someone that doesn’t know anything about programming can even be more powerful, because it forces you to go even more into detail and create a logical, understandable train of thought. The catch here is that (if it’s not a human) you have to pretend the object you’re explaining it to could understand what you’re saying.

The term “rubber duck debugging” was coined in the book “The Pragmatic Programmer” by Andrew Hunt and David Thomas and this is how it works:

First, get a rubber duck. If you don’t have one yet, buy one from Amazon. Describe to the duck step by step what your code is supposed to do. Go through each single line, explain what it does and what the logical next step is. Speak everything out verbally. This will force you to slow down, because we think faster than we talk. Don’t skip anything, even if it seems unimportant. Remember, the duck understands what you’re saying, it just doesn’t have a clue about programming, so you have to be very clear. Your program does exactly what you tell it to do, which means that you will eventually get to a point where your intended next step doesn’t actually fit the instructions you typed in. An that is your bug.

Of course it’s not always that easy and straight forward, especially when your code is big and complex, but at least give it a try. Just the act of explaining your code will already help you learn.


Rewrite the damn thing

If the size of the buggy code and possible deadlines allow it, consider removing the feature completely and rewriting it from scratch. This is often not an option if you are working for a company, and some developers (with more experience than me) even say you should never do it and always try to fix the existing code instead. But I think at least for someone who is still learning, it could be a reasonable option. If you are working on a hobby project, practice is more important than finishing the app quickly. If you rewrite parts of the code from scratch, you can not only fix hidden bugs, but also improve overall code quality and structure, all while cementing what you already know.



If you encounter a bug, just remember that problems and frustration are part of the learning process. Embrace it, even if it is hard. It means you are on the right path.

Also, consider joining the Coding in Flow Facebook group, where we help each other with coding problems. It’s easier to learn with like-minded people.

Happy coding and may you squash all the bugs along your way!


6 thoughts on “5 Tips That Will Help You Find That Bug”

  1. Thank you Florian for taking the time to write this debug article.

    Especially true for me is “just the sheer act of writing down your problem and trying to explain it might already help you get to a solution yourself, because it forces you to go through your code in more detail and explain the expected and actual behavior without skipping anything important. This can bring logical errors to the surface that you didn’t notice before.”

    Also, “Rewrite the damn thing” works sometimes for the strangest reasons. Sortof like clearing the cache in the Android Studio IDE….

    Best Regards and keep up the good work,

    • Yea it happens quite often that I want to post a question somewhere and in the middle of writing it I suddenly get an insight.
      And thank you again for pointing out that the comment button was not working!

Comments are closed.