Bugs.. I’m not talking about natural bugs you find outside. No, I’m talking about something far more sinister.. bugs in your code.

No matter how good you are, or how hard you try, you’ll almost always encounter some bugs in one form or the other.
Some bugs are easy to find, and can be solved with a simple null-check. But what about those obscure, weird bugs that don’t have a clear-cut cause?

That is exactly what this article is about. You’ll get 5 great and timesaving tips on how to find bugs in your code!

#1 – Debugger Tool

Unless you’re writing bug-free code (a.k.a being a god),  one of the most valuable tools you can use is a debugger.

When using a debugger, you can step through the code at your own pace, and inspect the value of each and every variable – as well as manually inspect the stack trace.

There are many different debugging tools available, and most IDE’s ships with a built-in debugger.
Personally, I recommend IntelliJ, which is a great IDE all over – and it has one of the best Java debuggers available on the market.

However, assuming that you’ve chosen not to use the best IDE for Java development, I will demonstrate the use of a debugger through an online tool.

Head on over to onlinegdb, and paste in the following code:

public class Main {
    public static void main(String[] args) {
        int a = 2147;
        for (int i = 0; i < 5; i++) {
            a = a * 1000;

After you’ve pasted it in, simply hit the “run” button at the top of the page.

In the console at the bottom, you should now see -322732032 printed out.
(Spoiler alert: We’ve exceeded the max value for integers.. 😉 )

Clearly, something weird is going on here – how come we get a negative number?

Let’s use the debugger to find out!

When using a debugger, the first thing you have to do is to set a breakpoint.

A breakpoint is a point / location in your code where you want the execution flow to pause, so you can inspect the variables / stack trace.

To set a breakpoint, all you have to do is to click on the left hand side of the line number.
A natural place for us to place our breakpoint is inside the loop, where we increase the variable a by a factor of 1000.

You should now see a red dot to the left of the line number.

Java debugger tool

All you have to do now, is to hit the button that says debug. Simply wait for the program to compile, and press the start button inside the debugger console.

Java debugger console

Now, take a look the information listed out under local variables.

Java debugger variable inspection
The debugger has now paused the execution of our program, so the variable a currently holds a value of 2147.
To continue the execution, simply press continue in the debugger console.

Breakpoint in java debugger
The value of the variable a has now increased to 2147000 – this is expected, as we multiply it with 1000.

Hit continue again – the variable increases to 2147000000.
Aaand hit continue again – the value is now -483648000.

Allright, we now know that the error occurs in the 3rd run of our loop, when we try to multiply 2147000000 by 1000.
Since integers in Java has a maximum value of 2,147,483,647, we can’t multiply a number that large by a 1000 – and that’s the reason why we end up with a weird negative number.

This is why a debugger is a great tool – you can pause the execution of the program anywhere you like, and inspect every single at that exact point of execution!

Now, what if you didn’t know that integers in Java has a maximum value? How would you know that was the reason the program failed?
Well, that brings us to the next tip for finding bugs – knowing how to Google! 😉

#2 – Google is your friend

Knowing when and how to Google your problems is a key skill for any developer.
The software industry is huge, and if you’re pulling your hair out over a problem,  I can almost guarantee that someone else has had that exact problem before – and went to extreme measures, which led them to create a post on StackOverflow.

PS: If you’re a privacy guy, you can always choose DuckDuckGo over Google.. 😉

Let’s again assume that you’ve encountered a weird “bug”, where the a variable doesn’t get the value you expected.

public class Test {
    public static void main(String[] args) {
        int a = 0;

    private static void changeValue(int a) {
        a = 10;

Assuming you don’t know about Java reference and primitive types, you probably would expect that this code printed out 10.
But of course, it doesn’t. And when code don’t do as you expected, you simply google your problem!

Enter int not updated in method java into Google, or just let me google that for you.

And what do you know – at the time of writing, one of the threads on StackOverflow has the solution to this exact problem – you can’t assign values to a provided primitive data type inside a method, since primitive arguments are passed by value in Java!

 #3 – Take a break

Speaking from experience, taking a break can actually make a huge difference when it comes to tracking down bugs and figuring things out.

Sure, it may sound simple, but I highly recommend that you try to take a step back and focus on something entirely different for a few minutes whenever you feel stuck on a problem.
What you do in your break doesn’t matter – as long as it isn’t programming! Go for a short walk, do some stretching exercises, watch a teaser for the next Game of Thrones episode.. Just be sure to get your mind far away from programming!

This way, when you come back, you can look at the problem with a different mind set, and actually get started solving it. Instead of, you know, recompiling the program 5 times without changing any code, hoping that it will finally work this time. Sadly, we’ve all been there..

#4 – Refactor

If you’re having a really hard time tracking down a bug, it might be because of rather messy code – commonly referred to as spaghetti code.

Bugs are particularly hard to find, not to mention solve, in unstructured and poorly written code.
If you feel like there are a lot of variables in the same scope, or methods with way to many lines – try to split it up into multiple methods. This will make your code so much clearer and easier to maintain.

But how do you know when to stop pouring out new code, and do some good ol’ refactoring?

Whenever you feel like you can’t easily understand the code flow without using a debugger, there‘s probably a good time for you to refactor your code.

It’s actually pretty simple – how do you expect to understand and solve the weird edge cases, if you can’t even understand the normal behavior of the code?

#5 – Don’t be frustrated

I can’t stress this enough – nobody performs well when they’re stressed out and frustrated.
Sure, some healthy frustration is fine, and can actually help you stay sharp and focused.

The problem occurs when you start to become too frustrated, and too stressed.
Who hasn’t been there – Your code doesn’t work. You don’t know why. The compiler doesn’t give any errors. No exceptions thrown. Your neighbor starts working with his load DYI project again. Your code still doesn’t work. You still don’t know why.

And just like that, you go from sharp and productive, to frustrated and unproductive.
Whenever this happens, you should probably just do as I mentioned earlier – take a break!

Wrapping up

I hope this article gave you some valuable tips on how to both track down bugs, and avoid writing them in the first place.
And remember – everyone makes mistakes, just try to stay positive and you’ll be correcting the mistake in no-time!

Happy coding. 🙂