No one writes perfect code, and bugs are an inevitable part of the software development process. Being able to locate and squash bugs is an important part of learning to code—it's also one of the hardest to teach. To be fair, teaching someone to step through their code in a debugger like PhpStorm isn't all terribly complicated if they're already tech-savvy, but that will only get you so far. Learning to use methodical logic, creative problem solving, and being able to decipher what you are seeing in your debugger is much more complicated.
Frankly, a lot of being good at debugging comes from having experience. The more you practice, the better you'll get. But, I believe there are also additional cognitive skills we can practice, and develop, in order to help us become better problem solvers. I'll be talking about the soft skills of debugging in May at php[tek], and wanted to write down some of my ideas whilst I formulate them into slides.
For this installment I want to talk about making assumptions.
Assumptions
Here's an example of an assumption; The sun will rise tomorrow. An assumption is something that is accepted as true or as certain to happen, without proof. This kind of thinking, while convenient, is prone to concealing facts, and troublesome when debugging code.
Just because the sun has risen every day since the beginning of the Earth does not mean that it will rise again tomorrow.
Assumptions aren't inherently bad. Without our ability to make assumptions we would be far less efficient at almost everything we do. While it can be entertaining to imagine what the world we would be like if we did question every single assumption, I dare say we probably wouldn't get much of anything done.
Each of us makes hundreds of assumptions every day. It's nice that we can slide out of bed in the morning and assume our feet will rest on a solid floor, without having to worry about whether it turned to molten lava overnight. I like being able to assume that when I ask the barista for a latté that the cup handed to me contains a latté, and not a Bloody Mary. Can you imagine how long the line would be if each person handed a latté had to pull out their chemistry set and prove that this was indeed going to wake them up not put them to sleep?
Assumptions Are Efficient As Long As They Are Correct
We literally would not be able to write software that stuck to any kind of schedule, budget, or even specification, if we didn't make assumptions.
When it comes to programming, making assumptions allows me to do things like use the Drupal format_date() function without having to understand how it works. Instead of having to devote considerable mental capacity to grokking the complexities of converting a UNIX timestamp into a localized representation of a date in human-readable format, I can simply read the documentation for the function and assume that if I pass in a timestamp as the first parameter, and a format as the second parameter that the function will return a translated date string in the requested format. I mean, it says so right on the cover.
Assumptions are marvelous. Mental shortcuts like these are what makes someone an expert in their field, but they are also sometimes just plain wrong. I can't tell you how many times I've spent hours starring at a dozen lines of code and saying, "But, this should just work!". Blinded by my assumptions, unable to see the flaw despite it being right under my nose. This makes the ability to recognize when you're making an assumption, and then validating that assumption, a decidedly important trait to develop if you want to improve at debugging.
So how do you stop making assumptions?
Make Assumptions
Actually, my advice. When it comes to debugging, start out by making as many assumptions as you can. Give yourself 10 minutes and allow your intuition to guide you. Often times our familiarity with a piece of software allows us to very quickly track down and eliminate bugs. I've had plenty of situations where even while someone was explaining the symptom to me, my mind was already racing to the line of code where I assumed that bug was hiding.
I call this dirty debugging. Get in, be quick and dirty, and see what you can find. But limit yourself to 10 minutes or you're opening yourself up to the possibility of chasing Alice down the rabbit hole. That way lies many hours of frustration and confusion.
Don't Assume Anything! Ever.
When dirty debugging doesn't work; stop. Start over, and this time be methodical and logical about unearthing the assumptions you're making. Here's some things I like to do in order to help reveal the conjecture:
- Get into the habit of asking yourself, "What assumptions am I making?" before winding yourself into a frenzy. Once you're frustrated it's harder to be methodical. If you're frustrated, step away and come back later.
- Summarize what you think is happening, and then write down any assumptions you're making. Sometimes taking the time to explain how a particular section of code works, or is supposed to work, to someone else will help reveal the flaws in your logic.
- Remember that high-school science class? Use the Scientific method.
- If you don't know for sure how something is working, you're making an assumption, so figure out how it's working. Read the code, ask someone–whatever it takes to know.
- When you're writing code, document your assumptions. I like to add inline documentation in my code wherever I know that this particular logical block is making an assumption. That way at least if future me ends up here again while chasing a bug down the rabbit hole I'll have an idea of what assumptions I should verify first.
This is a great article about recognizing assumptions, and I really like these two thoughts from it:
- Practice tempered humility. Familiarity allows us to quickly scan our knowledge base and perceive information in a meaningful way, but the Achilles heel of expertise is that expectations get set through repeated experience. Tread cautiously in the lines of code that you are most familiar with.
- Create diversity. Work to solve challenging problems with other people with different backgrounds. They are likely to see or perceive things differently and potentially thwart some of your unchallenged assumptions. But, be careful to diversify and not simply surround yourself with like-minded people.
Hopefully this proves helpful to you the next time you sit down to debug a Drupal issue. And helps you practice your software debugging skills. So that next time you fire up your debugger you know where to start looking.
And remember, just because the sun has risen every day since the beginning of the Earth does not mean that it will rise again tomorrow.
Add new comment