Seven Things to Do Before Asking For Help

In my roughly three years as a developer, one pattern of events kept popping up:

1. Tackle problem with confidence
2. Hit roadblock and shatter said confidence
3. Ask a smarter coworker, aka any coworker, for advice
4. Coworker points out solution that was in plain sight
5. Feel weird mixture of joy and humiliation, and continue working
6. Repeat at least twice a day

As you'd expect, I've grown tired of this happening. Problem-solving is a big part of our jobs, and having to rely on others is a signal I need to improve. So for my reference and other developers, here's seven things to try before asking coworkers for help.

To be clear: I'm not saying you should never ask coworkers for help. This post is about developing basic research skills so you don't lose your cool and needlessly ask others for help.

Restart The Workflow

This tried-and-true trick works around half the time. This works for changes related to the configuration or workflow itself, or if there's a glitch in the build. It's a reliable way to confirm something is a real bug, not just a ghost popping up in the machine. Unless my project has a long build process, it's always my first step.

Scour StackOverflow for Similar Issues

Virtually every code bug has happened before, and was solved on StackOverflow. Even if it's not quite the same, the answer at least nudges me in the right direction. I can look at the problem from another angle, search again, and repeat until I'm out of angles.

I don't limit myself to StackOverflow. Doing smart Google searches for debugging is a useful skill on its own.

Reread Any Related Info

Several times, a problem's answer was staring me right in the face and I overlooked it. That's why I double-check every relevant word in any related document I can think of. All things worth reading are:

• The project's README
• Related API documentation
• Comments on pull requests and issues
• Sticky notes under desks
• Manic scribbles written in red on the bathroom walls.

Too often the answer was in a few words I skipped over or misread, and only caught after rereading it several times.

Look at Similar Code

Often the code I worked on was a different version of something else, in that project or another. This is common with established frameworks like Rails or Ember, where there's conventional ways and patterns to solve problems. Even if I'm not working with a framework, it's easy to find similar codebases at least doing something similar.

I don't think of it as stealing, but as "taking out an illicit, creative loan."

Talk to a Rubber Duck

The "rubber duck" trick sounded silly to me at first - explaining a problem in simplest terms to an inanimate object, like a rubber duck. But it forced me to think about the problem differently, which helped me find the answer as the duck listened. Like searching StackOverflow, it at least changed my perspective and got me closer to the answer.

Plus, no one talks to the rubber ducks. They deserve some company!

Walk Away for a While

If none of the above tricks work for me, I'm literally and figuratively banging my head on the desk. At that point trying anything else is pointless. I take a walk outside and think about anything else. Distractions give the subconscious mind time to work problems out.

There have been many times I take a walk, sit back at my desk, look at the problem, and the solution hits me out of nowhere. So don't let people tell you work breaks can't be productive.

Punch the Computer

If all else fails, going into a rage and punching the computer makes the problem go away for a little while. It's worth it for a little while. Then it's not worth it for a long, long time.

Instead of this, I'd recommend finally asking a coworker for help. Both because you've genuinely tried everything you can, and it'll keep you from destroying a good laptop.

Comments

[Ali Spittel]

This is awesome! I love this for rubber ducking!

[Esteban Rocha]

Woa that's awesome! Thanks for sharing it!!

[Max Antonucci]

Ah I've seen this before! I've found it the most useful for those new to rubber ducking. As I've gotten used to the process I've been able to give my real rubber duck more attention :)

[Lavinia]

You also have to decide when you have spent too much time looking for an answer on your own. Sometimes the time is not our ally.
Btw, the rubber duck trick is great, I like to call it "el truco de la gallina" bmbt.co/3w

[Malgosia]

These are quite good tips (maybe beside hitting the laptop :P I broke my squash racket over a wall when felt frustrated during training once - not worth it:p)

I really feel your pain about this point though:

Feel weird mixture of joy and humiliation, and continue working

But additionally I realized one thing - you should know who to ask about the problem and how you ask.

Most of people will go straight up to giving you proper solution if you ask for it (which can make you even more frustrated as you feel it was something obvious you should probably came up with)

But maybe after talking to rubber duck you will ask question correctly to someone be able to rephrase the question in such way a good techlead he will be able to point you out the way to figure it out on your own :)

I'm trying out to not ask exact question but put an abstraction over it and make it sound like some general problem.
Instead of asking "how to solve this specific case" try to ask what are different ways of solving similar problems in general.

Doing this you probably will just get some new perspectives on topic and it is much more probable you will feel you've finally came up with specific solution on your own (e.g. by choosing between solutions).

[Nick Cinger]

Good advice, and nice write-up :D

It just saves everyone some time, and helps the person progress faster. Also helps later one when you don't have anyone else to ask - especially duck debugging!

[Max Antonucci]

Exactly. You never know when something you see will push your mind in the right direction. Walking and taking in the scenery is a great way to do that.