Three Tricks to Solving a Problem
Part of my work as a web developer is being able to fix things. And many times I find myself in a situation where I need to fix a problem without knowing how things work. Here are a few tips I used to help navigate these tricky situations.
Figuring out what is still working:
When someone raises an issue, I prefer to focus on what is working before I go into figuring out what broke. I say this because when dealing with a system that you have no idea how it works, figuring out the latter will only take up more time. This is to help save time so you can better isolate what in the system is broken.
In an example with an e-commerce website that crashes when a user goes to checkout, you don’t need to know how an account is created, just what happens after a user clicks checkout.
Replicate and Identify a pattern:
When it comes to debugging and problem solving, patterns are your friend. They are repeatable, predictable and make things easier to understand. The reason finding a pattern is important is that it will help you filter out what is expected behavior and what are anomalies.
Using our e-commerce example, say the site crashes when a user adds any item to the shopping cart, you can assume the problem has something to do with how items are added. But let’s say you add an item and everything works? Well then, we know it’s not the process of adding an item, but due to a specific item. This goes hand in hand with retracing steps.
Now, when looking at the specific type of item, we can test if it’s a specific group or if it’s a one off-case where the item simply has bad data, i.e., an anomaly. Once we can identify a pattern and recreate the issue, we can now work on a fix. But how can we fix something if we don’t fully understand how it works?
Purposely Break something:
If you are lucky and have a project with good documentation and proper error reporting, you may be able to find where the code you need to fix. Realistically, you most likely will deal with outdated documentation and cryptic errors messages, so you will need to figure this out on your own. I find that purposely breaking an application helps me do that. Because, when you break something you know how to fix it, for me I like to remove random bits of code from files I think relate to the functionality and see what happens. In doing so, you slowly get to the root of the problem and learn how things are supposed to work.
I should add that this is all very hypothetical, and much of debugging and problem solving is situational. However, over time, I’ve found that regardless of the tools and resources available, these guidelines are a helpful starting point when dealing with a situation like this.
Have a problem solving tip you would like to share? Send me an email and I will be more than happy to discuss!