A Newbie’s Guide to Bug Bashing

This week has been hard. My code has been blocked literally since last Friday. And despite working with my mentor and other devs on the team, the problem lives on and every attempted build since has failed.

My relationship w/ my computer this week

And yeah… that has been pretty frustrating to say the least. It’s easy to get discouraged and feel defeated; to let imposter syndrome win and plagued by self-doubt.

But I’m not going to let it. Despite the frustration, this week has also offered me an opportunity to demonstrate a few things about myself.

It’s been a reaffirmation that I’ve got grit baby. I am NOT going to let this bug win. It will not define me as a developer or speak to my intelligence or about my ability to contribute meaningfully to my team. Facing such a confusing and complicated block in the code has not just exposed facets about myself as an engineer but who I am as a learner.

Upon reflection, I’ve realized that I systematically approached this block in a pretty methodical fashion- aka I wrote an algorithm to tackle my code block. And as I sit here reflecting on what can only be described as a bummer week, I thought I’d find the silver-lining by sharing that process with you all here.

👾 Your Friendly Step-by-Step Guide to NOT Allowing that Tricky Bug in your Code Win 👾

1. The first step is deciphering, decoding, and actually taking the time to READ and understand your error messages.
2. Next, begin researching other code bases and utilize any available resources (StakeoverFlow, Github, or perhaps a company’s internal wiki) to search for possible solutions. What have others done before you? There’s no need to reinvent the wheel here as your code is most likely not a unique and undiscovered snowflake of originality. Use your fellow engineers who have coded many solutions before you to your advantage!
3. Diligently record all generated possible solutions. Literally document every. single. idea. you. have. At this phase, there is no such thing as an idea too small or dumb.
4. Rank these solutions based on the likelihood of success and time it will take to implement (aka be smart with your time and don’t try the unlikely and burdensome solution first!).
5. Now, and only now do you get to coding! This is when you methodically attempt to implement the best possible solution that is at the top of your brainstormed list.
6. And if that solution fails (it’s okay if it does), return to steps 1–4:

• Repeat Step 1 and be sure to record whether or not you’ve received a new error message. There is information to be deciphered in both scenarios.
• Repeat Step 2 and continue researching other examples based on those potentially new error stack traces, as you most likely now have new search terms to be googling.
• Repeat Step 3 by reevaluating those possible solutions and adding new ones to the list if you can.
• Repeat Step 4 if necessary, by smartly reranking the solutions based on that research, before trying a new one in step 5.

Essentially, you must be willing to continuously and cyclically refine and develop a more informed and zoomed-in list of potential solutions and continue chipping away at the problem. Just don’t give up! Stay persistent. The bug WILL NOT WIN.

And it’s important to note that the problem will inevitably morph and change as you get iteratively closer to discovering the solution, and thus you must be open to that ebb and flow and resist the temptation to get discouraged. Remember, you can do this.

Seriously, why not switch the narrative? Debugging doesn’t have to suck. Maybe we could perceive each failure as a growth moment and an opportunity to deepen your understanding of the broader scope of the problem and codebase at large.

🎉Hooray new learning opportunities! 🎉

SIDENOTE:

Throughout the research process, you will inevitably discover other smart and clever ideas your code might benefit from that are perhaps separate from your current block. I would suggest recording those ideas and be willing to implement them periodically throughout the debugging process because it is no fun feeling stuck in the BLOCKED status all day every day. Plus it can be beneficial (and fun) to pull away from the problematic code, provide your brain some decompression time, and give yourself a win by implementing other (although potentially unrelated) positive changes every once in a while.

So, is your bug fixed yet?

Is your code flawless and ready for Code Review? Nope? Yeah, me neither. My stupid bug lives on. But at least I’ve found a way to spin what can be an incredibly negative and toxic experience into a relatively positive one! And for me, that feels like a win. 🤓

Remember, #YouAreNotYourCode | Follow my coding journey 👩🏼‍💻@LoLoCoding

This story is published in The Startup, Medium’s largest entrepreneurship publication followed by 307,492+ people.

Subscribe to receive our top stories here.