How to Avoid Falling Down the Rabbit Hole When Solving Problems

Ask Questions Before You Are Not Sure You Should Go Deep Into a Solution

Photo by Joshua Fuller on Unsplash

Developers suck at estimation.

When someone asks them, “How long does it take to investigate the bug or to solve X?” We often give them an optimistic estimation, “It will be a T-shirt size Medium.” However, we dive into the problem and realize that the problem is bigger than we initially estimated — we will need to touch on multiple files/folders and libraries to change a single function. Then, they will make the classic time-wasting mistake.

They will go silent and solve the problem with their solutions for DAYS. Essentially, they are in the rabbit hole.

It is a different world down there. Simple problems and bugs with well-defined solutions can become complex ones with interconnected code. By the time they submitted their PR, everyone was shocked.

“ How did it turn out to be so crazy? This problem can be solved in X, Y, Z.” The team requested a change request on the PR.

The developer submitting the PR is unhappy because they have worked on it for days. The team wasn’t happy either because they had spent days not hearing anything from the developer.

Through experience, a pro developer knows never to get into the rabbit hole. They know when the problem gets gnarly, they stop spinning their wheels and ask for help.

Let’s face it; we’ve all been pulled down the dreaded rabbit hole at some point in our careers. The experience has taught us invaluable lessons.

This week, I want to share how you can escape and not get into the rabbit hole when solving problems. I will talk about three bugs I mostly encounter in my software engineer career and dive deep into strategy and tips to help you solve your problems faster and escape the rabbit hole.

Let’s get right into it!

Solving problems and debugging is often a process of making and testing hypotheses. Since you think the system should be doing one thing but doing another, it must mean that one of your assumptions about how the system works is wrong.