Introduction

Debugging is one of the harder skills to learn as a developer and learning how to do it efficiently is tricky. There are a number of factors which can lead to this such as size and complexity of codebase, experience of technologies used as well as historical experience. One of the hardest aspects of being a developer I have found over the years is actually teaching someone how to debug efficiently. The ability to mentally think through the code and add break points at the appropriate lines of code to help is something to learn. The ability to read and understand log files and exception stack traces is also something that takes time to learn. The number of times that I have helped developers in the past, you look at their screen and they have a break point on nearly every line in a method is a bit of a warning sign. They are either unsure what they are looking at, where the code flow goes or even what they are trying to do.

So why this post? And why does it relate to debugging?

What is Soduku?

Let’s take a step back briefly and answer the question “what is Soduku?”. Soduku is a logic based game which is around determining where the numbers 1 to 9 go in a 9x9 grid made up of smaller 3x3 grids. Each line can only have the numbers 1 to 9, each column can only have the numbers 1 to 9 and each sub 3x3 grid the same. You start off with a partially completed grid which allows for a single solution to be filled out.

How does Soduku relate to debugging?

Soduku is all about logical reasoning and deduction. The easier grid puzzles are relatively straight forward and there is minimal deduction required to fill them in. There maybe the odd “it can’t be 2 here because there can only be a 2 there in that grid” type scenario but usually the easy ones are straight forward.

But again, back to debugging. Debugging is around deducing when something will go wrong or has gone wrong to see why it’s not working the way you expect it to. Soduku is the same. As the levels of complexity increase there is more logical reasoning required to determine what a value could be without any specific proof. There maybe a few squares which could be 1,4,7,8 for example but as you fill out more of the puzzle you can start to rule out those values before you can say it must be 8 (for example).

This is another similarity to debugging; breaking down the problem. And it’s not just related to debugging. When writing software breaking down the functionality into smaller parts makes it easier to build. The same goes for debugging. If you break it down into separate parts and logically determine where you believe the issue is to start with you can work through the code, look at the data being moved around and processed to see if you were correct. Sometimes it’s spot on, sometimes you’re way off and others it may not be the right place but it will direct you to where to look next. This is the same as Soduku in harder levels when you have to imply what the values are to drive 2, 3 or more square values a few “moves” down the line.

Conclusion

Do I have any scientific proof that Soduku helps with debugging software? No. I used to do the daily Soduku’s on my commute when I caught the train and like anything with practice you get better at them. You learn to use logical reasoning more as you practice. You start to pick on different patterns and your brain, or at least mine, starts to think clearer around what certain values could and couldn’t be. Much like Soduku debugging can get hard. And sometimes it only gets easier with practice and being able to logically break constructs and processing the code flows in small targetted chunks so you don’t get overwhelmed.

What are you thoughts on this? Is there anything else you’ve done in the past to improve you debugging skills? Let me know on Twitter @WestDiscGolf.