October 15, 2018

Seven Things to Do Before Asking For Help

Asking for help is important, but so is learning how to give problems your best shot beforehand.

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.

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:

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.