Much has been said about the virtue of trying before asking, particularly in the software development world. The basic idea is that, when you have a problem, you should exhaust all of your available, non-human resources before asking another person for help. And it’s true.
Typically, the stated reason for this is that you should avoid disrupting another’s work whenever possible. I agree with this, but there’s another reason. A reason that’s probably just as important as the first:
To avoid looking like a dumbass whenever possible.
If you take the time to make sure you’re actually stuck (instead of just assuming you are at the first sign of trouble), you’re much less likely to have your coworker walk over and solve the problem in under five seconds because you missed something obvious. Trust me, I’ve been on both sides of this little scenario and, as the “asker” of the dumb question, I feel incredibly stupid for having not taken the time to rule out the obvious culprits.
In our personal and professional lives, we work on a sort of credit/debit system, not unlike a checking account.
If I do the dishes for 20 nights in a row, my wife will probably be cool with the fact that I didn’t do them last night (either because I was too tired or simply couldn’t muster the will).
If I routinely ship quality code and documentation, the occasional “duh” mistake is more easily forgiven.
Now, the flip side…
If I didn’t do the dishes for twelve nights in a row (which are my responsibility in our house), my wife would probably be a little miffed and not terribly interested in whatever excuse I’d managed to cook up.
If I routinely ask my coworkers for help with my “head-scratcher” code issues and each time the problem is simple and obvious, I’m going to earn a reputation as a—say it with me—dumbass!
So, try before asking. Try really hard. Assume nothing.
(This was intended more as cathartic self-talk to myself than as the wisdom of an expert.)