How to ask for help
How to ask for help
Asking for help is one of the most effective ways of not only getting work done but learning at the same time. However, it can be a very difficult, and in some ways, delicate thing to do. We often do it in inefficient ways - sometimes giving too much or too little information for those that want to help us.
This is a very common problem not only in the workplace but also in the Open Source community. Issues opened without a predefined template of questions often results in many comments asking for more information and more context.
Here are the main steps that I follow when asking for help:
1) Give Unbiased Context
We get it. You're in the zone. You have written some damn good code, or designed some beautiful logic. Or maybe you haven't even started yet, but have massive and great ambitions.
Problem is, no-one else knows about your work apart from you.
Whenever you ask for help, the first thing that you should talk about should be context surrounding the problem you're facing. This could be explaining;
- What project you're working on
- What language it's written in
- What ticket the work belongs to
- What you are trying to achieve
Any high-level information you can give the helper is invaluable. It will not only ensure they have a clear starting point to begin the discussion from, but also help them understand your mentality and mindset going into the conversation.
A core part of this is being unbiased.
Keep this part as objective as possible - a simple, brief objective overview of where you're coming from.
2) Be concise and clear
It is very tempting to give a full and in-depth backstory to your issue. For you to go into every minute detail, talk about every insignificant element of your work - hell even start monologuing about your life story to date. It happens to the best of us, it really does.
People want to help you. They do. But it's hard when you can't tell what's relevant and applicable to your issue, and what's just... fluff.
When describing your problem, be incredibly clear and concise.
Describe what the actual problem is, how you got here, what you have tried, and maybe what you think the issue could be with.
The reason why you should only maybe give your thoughts is due to a bias you may have regarding your issue - that you may then pass on to the person helping you. Of course, if there is valuable information or even an educated hunch they need to know about by all means tell them. However, if you have an uneducated hunch/guess that it could be something XYZ, then maybe hold off until they have had some time to look over and understand the problem thoroughly.
Note: Github issues are actually a fantastic example of properly designed concise issues with plenty of context for others to help with.
For example, GatsbyJS has a template that looks something like this:
A great example of how much context, and then actually problem-based information to give.
3) Be patient
Someone is taking the time out of their day to help you - something that they do not have to do.
They most likely have work to be doing themselves, deadlines to be hitting or other commitments to fulfil at the same time as helping you with your problem.
Therefore you should give them time to help you.
4) Thank them, and return the favour
Even if they weren't able to fix your problem, this step is still the most important!
Make sure you thank them for their time and more importantly offer to help them in return (and fulfil that offer).
You don't have to be an expert in a domain to provide support and help to those working within it. The most junior developers can still provide valuable insights to the most senior developers - even if it is just being a rubber duck.
Growing a culture of teaching and learning in a workplace is an incredibly difficult yet invaluable thing.
And it begins with understanding that everyone can give help, and everyone requires help.
- Olly