What Are We Investigating

When we encounter issues in our code base, we need to "investigate" to try and figure out how we might resolve them. Great, that makes sense...but where on earth do we start with "investigating"?! What does it mean to "investigate" an issue?! Sometimes it can feel overwhelming to have such a large scope.

Here are a few general steps that I take, that might help you out when trying to investigate any bugs in your code.

Ask - what is the problem?

Before you start getting stuck into nitty gritty issues, it's best to have the big picture question confirmed in your mind so you know what you're working towards. It would be good to be as specific as possible, but how specific you can be depends on context. For example, you might pose the question as "Why is the output giving me X results when we are expecting Y?"

How do I know there is an issue?

Have you got unit or other types of test which are showing you there is an unexpected output? If yes, how can you be sure that the issue is with your code and not the test? Firstly I'd check that, but also I can then use those test manually to see where the issue might be arising. Is it a TypeError? Hopefully, your tests will be able to point out where the issues are picked up, even if that's not where the issue is directly.

How about if you can observe the issue - the human "sense check". Sometimes you can just see the output is not in the right form or showing the right details. This can be a tricky one, because you might not know where the issue is coming from, just that there is one.

So now you know there's an issue, what can you do about it?

Check your data

Before I get my head too far into the code, I like to check my data. Am I feeding in the data I should be? Does it look like I want it to? Just some preliminary checks to make sure that I'm not wasting a whole load of time trying to "fix" code that isn't broken. This could save you hours!!

Finding the Issue

This is where I like print statements to help me debug. Yes, there will be many people out there who will cringe at this, and whilst it isn't a slick way of debugging your code it is a practical one. You can explore debugging functionality in your IDE, each one will have their own intricacies usually around setting break points in your code that you can manually "step" over to go through your code piece by piece. But, I'll focus on what I find is my go to method.

I can run my code as is, but with some added print statements at key parts, just to check that what I think is happening is happening. This is particularly useful when you are using different flow control elements e.g. if/else statements and loops. I like to number my print statements as it helps me to check if anything has been skipped more quickly. Handy usage of string formatting too ! e.g. print(f"1 - {type(var1)}" or print("2 - enter for loop")

These print statements can be as verbose as is helpful for you. I like to keep them short and focus on where inputs are interpreted or something has been created, as these are key areas where errors can be found. Checking variable types, data sizes and that things aren't coming up as None are really good places to start.

Just because you know where your symptom is showing, it doesn't mean that's the line of code that's causing the issue. Here I would say break down the code in the run up to the print statement showing the issue even more granularly. Make sure you know what each line is doing, is every input to any function what you expect it to be, are any functions returning what you expect.

Fix the issue

Once you know what your issue is, then it's a case of fixing it. I know, I say it like it's so simple when sometimes it really isn't. Hopefully though, by this point you know what the issue is and what is causing it.

Here is just a high level overview of the steps I take when I need to "investigate" an issue. There are plenty more specifics, and everyone will have their own system that helps them, but I find this is a good place to start.