Getting stuck while coding is a fact of life. Whether you're experienced or a beginner, if you can't figure it out on your own, asking for help is the best way to get unstuck. How you ask for help, though, makes a big difference.

You want to stick to the facts by answering these questions:

• What are you trying to do?
• How did you do it, step by step?
• What did you expect to see?
• What happened instead?
• What have you tried to solve the problem?

The more details, the better. Include these pieces of evidence if applicable:

• Exact error messages
• Screenshots
• Log files
• Code samples, or better yet, a link to your repo if it's public

For Ruby projects, this extra information can be helpful:

• Output of gem env
• Contents of Gemfile and Gemfile.lock

Remember that when you ask for help, you are asking for someone's time, so giving them as much information as possible will make it easier for them to help you. Having said that, try to keep it focused on one problem at a time.

Here are examples of different ways people might describe a problem when asking for help:

Too vague

• "I deployed my Jekyll site to GitHub Pages but it's not working."
• "I can't deploy my Rails app to Heroku."

Speculative

• "Other Jekyll sites I deployed to Netlify worked fine, so it must be an issue with GitHub Pages."

Great!

• "I followed your Jekyll and GitHub Pages tutorial, and everything worked as expected. Then, I tried to install the moving theme, and when I pushed the changes to GitHub, the site didn't look like the moving theme. Here's a screenshot of what it looks like now, and here's the demo of the moving theme that I expect my site to look like. Here's a link to my repo that shows how I installed the theme. When I ran bundle exec jekyll serve locally, everything looked fine. I'm not sure what else to try."

Another advantage of taking the time to write down the answers to those 5 questions at the top is that it can sometimes lead you to find the solution on your own. This is known as rubber duck debugging.

Debugging Tips

When you haven't yet mastered the basics, debugging can be hard, and the list of things to try can be specific to what you're working on. However, there are some general techniques you can add to your toolkit. Below are three of them. More to come in future guides.

Small Changes

Git makes it easy to save your work in small increments, which is why you'll hear the adage "commit early, commit often". When you make small changes at a time, it makes it easier to pinpoint what went wrong.

If you update 10 gems at the same time in your Ruby project, and then it stops working, it might take a while to figure out which gem broke it. But if you update one gem at a time, and check that everything still works after each gem, you will know right away.

You might not know why, but you'll know what, and you can provide that information when asking for help.

Web Developer Tools

All the major browsers come with developer tools for debugging and testing.¹ On a Mac, you can open and close the developer tools with the same keyboard shortcut on all browsers: option-command-i. Take a look at the Console and Network tabs and look for any errors, usually shown in red. If you're not sure what the errors mean, look them up and see if that gives you any clues. If not, make a note of them or take a screenshot when asking for help.

Avoid Confirmation Bias

As humans, we are influenced by a wide range of cognitive biases. One of them that can affect how we test and debug is the confirmation bias. It describes how we tend to look for information that confirms our beliefs. If you have a theory for what is causing a coding problem, you might limit your research to things related to that theory, while dismissing anything that doesn't fit the theory.

I came across a perfect real-world example by chance. While taking a break from writing this guide, I noticed a new email from Julia Evans. You might know her from her programming zines. It was her blog post about debugging an issue with server-sent events.

She describes how she "went on a whole digression trying to understand how sleep in Ruby works", and that she "was really 100% committed to debugging both of those bugs from first principles." When a colleague pointed Julia to some Stack Overflow threads, she "was skeptical of the solutions those threads were suggesting."

In the end, she was able to get everything working, and those Stack Overflow threads did hold the clues. The key here is that someone else helped her shift her mindset and become less influenced by confirmation bias. Even if we know about cognitive biases, it's hard to avoid them on our own.

As Daniel Kahneman says, the most effective check against biases is from the outside because others can perceive our errors more readily than we can.

What if you're coding alone?

You can write down or print out a reminder and keep it visible while you code. Stay tuned for a cheatsheet that summarizes this guide.

What are your favorite debugging tips and ways to ask for help? Tweet me @monfresh, or reply to this email.

If you found this guide helpful, please share it with any beginners you might know.