Let’s face it, getting stuck on a programming problem stinks, doesn’t it?

When it comes to asking for help, especially when starting out in our careers or when onboarding onto a new codebase/project, I’ve found that we tend to fall into two categories:

• We ask for help the moment/shortly after we get stuck.
• We wait a while wait ages never ask for help, no matter how long we’ve been stuck for.

I’ll be the first to admit that I very strongly fall into the latter category, even going as far as to say that to this day, having over 12 years of experience as a software developer, I struggle to accept when it’s time to reach out for help.

Is one better than the other, however? I’d argue neither, really:

• Spending too little time on trying to solve a problem blocks us from practicing, learning problem solving, and/or catch bugs/UX/DX issues in a project.
• On the other hand, however, taking too long or never asking for help can hold a timeline or team back. Maybe someone can offer their perspective and be the saving grace because of their unique perspective or because they’re especially knowledgeable in the problem!

What helps is to have a consistent amount of time to try going at a problem before you reach out for help.

How long should I wait before reaching out for help?

The specific amount might vary from situation to project to situation, but I find it’s important to be consistent about it in that context. For example, one heuristic that I developed over time is to give a problem no longer than 30 minutes before reaching out for a helping hand.

This amount of time could be different for you, of course!

Asking for help effectively

Right, so the title of this post is not just about how to ask for help, but how to do so effectively. How can we maximise the time for ourselves as well as the person helping us out?

Asking narrow, pointed questions

I spent many years working in software support and teaching children to code, and I’m sure a lot of you can relate that the following tends to not be very helpful when being asked for help:

Could you please help me? My code is broken and nothing works.

It’s not bad, of course! But it can be better. What I recommend doing is offering as much information as possible upfront in order to get the person helping you to start thinking right away about a solution:

Hey, I’m having some trouble logging in since updating to the latest login dependency, could you please take a look? I’m updated to 3.1.4.

This way, we’re priming everyone for the problem as we arrange a time to pair on the issue.

Sharing what you’ve tried

Another helpful thing to do is to immediately start knocking out possible solutions that might seem like clear suspects to the person helping us. For example:

I’ve already deleted node_modules, made sure I’m on node 16, and restarted Docker, just in case.

Reproducing the problem

Another way one can help the person that’ll lend us their help is to outline the precise set of steps to reproduce the problem that’s got us stuck:

Ok so first I ran npm install, then I started up the dev environment with npm run dev, and then navigated to localhost:4000/login and then got the error message.

Requesting a pairing session

It’s been demonstrated that pair programming is a highly effective software development [Cockburn, Alistair, and Laurie Williams. “The costs and benefits of pair programming.” Extreme programming examined (2000): 223-247.], and this absolutely extends to problem solving with regards to getting unstuck. Having someone sit down with you to step through the code, one of you navigating and the other driving is super helpful!

And hey, why just keep it at two?

The more, the merrier: Requesting an ensemble session

Ensemble programming builds upon the concepts of pair programming by having not just a driver and a navigator, but also an ensemble of folks collaborating on a single coding session, looking up documentation, throwing out suggestions, and rotating at regular intervals. If there are resources to do so, this can be an incredible help session!

This is something we’ve practised before while open source coding live with Distribute Aid, live on stream with the chat as our ensemble. This has proven to be a lot of fun and useful for getting unstuck.

And those are some of the ways I’ve practised asking for help!

What about asynchronous work?

With so many of us working in remote teams, taking asynchronous communication and collaboration into account is necessary. There’s not too much to differ here, is there? The good thing about asynchronous collaboration is that we can send off a help request as early as we feel necessary, and continue trying alternatives.

The added time also gives us the ability to, once again, asynchronously add further context as we go along. We can also try different avenues for help, be it posts on forums or communication platforms, being helpful and keeping these up to date, too.

Update! Chad was kind enough to add some of his own experience:

When working on a problem, open a PR and if you run into an issue, push the code. Now you can ask for help asynchronously and can show the problem directly!

Asking for help is an essential part of software development

Just wanted to end this with a reminder: A lot of software is developed collaboratively. And this collaboration not only involves reviewing each others’ code, setting up helpful automations, or planning. It also involves getting others unstuck. Being on the side of offering that help is also tremendously gratifying.

I’d love to hear from you! What tips do you have around asking for help when stuck? Get in touch! I’m on Mastodon.