Before asking for help, make sure you understand your tools

I’m writing this blog post in response to Why Rockstar Developers don’t Ask for Help and So you want to be a Developer Rockstar?. Despite the use of the ridiculous term “Rockstar Developer” and quite a lot of humble bragging, I think the author is on to something, but just barely missed the mark.

I wouldn’t say that good developers shouldn’t ever ask for help, that’s crazyness. I’d change the wording a bit:

Try not to ask for help if you don’t understand the tools/software that you’re having problems with

What do I mean? If you’re trying to figure out how to rebase your branch in Git, or why PHPUnit isn’t running, or how to fix a particular C error, you’re probably uneducated about something relevant to the problem (e.g. you don’t understand rebasing or Git’s internal data representation). If you learn more about Git, you’ll have the understanding to fix the problem, and probably many more related problems (or variations of the same problem). On the other hand, if you just ask your co-worker for the command to rebase a branch, you don’t understand what is happening or why it works, so the problem remains. Put in the time to learn your tools, libraries, frameworks, etc.

If people took the time to learn instead of trying to barely skate by with as little effort as possible, there would be far fewer interruptions in the work place, far more productive and well educated developers, and significantly less noise on StackOverflow.

Of course this isn’t always the case. Sometimes you reach the point where you’ve spent too much time on the problem and need help getting to the next step. Or maybe you’re so lost you don’t even know where to start (in which case you should ask for pointers, not a complete answer). And of course, you may not have the time to learn something well enough to continue due to deadlines, but if this is the case, you should definitely follow up afterwards when you aren’t racing the clock.

When should you ask for help? A common type of problem is when something should be working. You understand the system and what’s going on, but it’s not working the way you’d expect. You aren’t blindly running commands with no understanding of how or why they work. Maybe you’ve overlooked something, or it’s just some small thing your co-worker will point out right away. I think these types of problems are fine to get help with.

Likewise, domain specific knowledge where you need an understanding of the business are typically fine to ask a co-worker about. How do you interface with this heavy duty crane transmission, what does this scientific shorthand mean, or what are the rules around who can access what content?

I also want to point out that this doesn’t apply to getting feedback, such as asking a co-worker for feedback on your design, approach, or code.

Leave a Reply