Some time ago, I was stumped by a spec failure. Having decided that I’d spent enough time on it, I asked a colleague over and began to explain the problem I was facing.

“Here’s the feature on which I’m working. Here’s the spec that I just wrote. Here’s the failure message and how I interpret it. Here’s the code that I thought would make it pass. Here’s what else I tried before asking for your help.”

After a few minutes, my colleague admitted that he was stumped, too. I thanked him for taking a look and said I’d let him know when I found a solution and what it was.

A project teammate, who was working remotely that day, had just pinged me in iChat for our status update on the day’s work. I let him know that I was stuck at the moment on this spec failure.

Since he only had a few minutes before he had to leave to catch his train, I pushed my work in progress to a remote branch. He would check it out and call me if he noticed anything.

Minutes later, my phone rang. My teammate had immediately spotted the problem, corrected it and pushed his changes.

Why was my teammate able to identify the problem so easily?
Was he more skilled in this area than my first helper or me?
Did he have better tools? Was he more familiar with the code?

In a word, no.

He was able to identify the problem so easily because I hadn’t constrained him with its history; he was completely open. If he needed more information, though, he could’ve asked for it.

The next time you ask for help, say no more unless and until your helper asks you to. For, as the saying goes: “Speech is silver; silence is golden.”