Asking questions is literally the first piece of advice anyone gives to a brand new developer, and there is a good reason for this. I cannot emphasize the importance of utilizing your teammates as resources to help you learn. The whole point of working in a team is so that teammates can help each other out. If you aren't constantly asking questions within the first couple of months on the job, you are not taking full advantage of the resources around you.
There is a caveat to this point that isn't talked about enough: not only should you be asking plenty of questions, but they should also be the right questions. Before I go any further, I want to emphasize that I am not trying to scare anyone out of asking questions. I don't mean you should be worrying about whether your question is a "stupid question" or not - it is perfectly acceptable to ask a "stupid question". It is also perfectly acceptable to ask for help. Instead, I believe there are certain ways to phrase typical questions that can help better set you up for success. Let's explore a few examples.
Don't Ask: "Can you explain <insert business process here> to me?"
Do Ask: "Do you have any resources about <insert business process here> that can help me learn more about it?"
Chances are, there is some resource that already exists to explain the business process to you - and this resource likely will be a lot more thorough than the answer your teammate will have to come up with on the spot. If this resource still doesn't help you understand everything you need to know, then you can ask follow-up questions for further clarification. You now also have a bookmarkable page that you can refer back to whenever you need a refresher. Win/win!
Don't Ask: "What's wrong with my code? Can you fix it?"
Do Ask: "I am having issues with my code, I have tried x, x, and x. Do you have some time to rubber duck this?"
It is normal to ask another team member for help on your code, this is another one of the whole points of working in a team. However, blindly asking for help is disadvantageous for both you and your teammate:
- If you get into the habit of immediately asking for someone to fix your code as soon as it breaks, you'll never gain the skills to debug complex problems on your own
- From the teammate's perspective, getting asked to "fix someone's code" is a very frustrating experience. You then have to spend time understanding all the context of the code before you can even begin to debug.
The Do Ask question in this scenario does a few things:
- By forcing yourself to wait until you've tried a few different approaches to your problem, you force yourself to think more critically. You might even stumble upon a solution and not even have to ask for help. This is the best way to learn!
- If you don't stumble across that solution, then at least you can tell your teammate what you have attempted before asking them for help. This reduces the amount of time your teammate has to spend debugging the problem, hopefully allowing them to figure out the issue even sooner.
Don't Ask: "How do I do this task?"
Do Ask: "I am a bit confused about this task. Do you have any suggestions on how to get started?"
As an inexperienced engineer on a new team, one of the scariest things is getting assigned that first Jira Story and having no idea how to do it. Again, this is the point where I reiterate that I am not trying to discourage junior engineers from asking for help, I just think there is a better way to go about it than straight-up asking for help.
Say you ask "How do I do this task?". Your teammate will then hop on a call with you and guide you step by step through the process. Or worse, they'll do it for you while you watch. There is some value to this, but there is even more value if you are given the opportunity to attempt the task on your own before you reach this point. By asking the "Do you have any suggestions on how to get started?" line, you give yourself that opportunity. Your teammate can now start you on the right path, without accidentally doing all the work for you. If you still struggle, then it might be time for that step-by-step walkthrough. But make sure that you are the one doing the work, rather than them showing you by doing it themselves.
Asking questions is one of the scariest things you need to do as a new developer. None of these examples are meant to imply that you should be scared to ask questions - in fact, quite the opposite. They are meant to show you how you can make your questions even better and more useful for you. By thinking a little bit about how you communicate, you can gain way more out of a simple Slack DM. And you might even impress your teammates along the way.
If you liked this article and want to be notified when I publish another, consider subscribing to my mailing list.
Top comments (5)
From my experience, I have seen another type of question that is difficult to answer.
It hard for me to explain exactly what is the problem, and this is why I'm commenting here, maybe you can define it.
The problem is about the context of the question. The junior is trying to feel professional, or he ashamed his lack of knowledge, so he try to ask you "professionally", going directly to the specific point of failure (the point he is thinking it is), with a lot of professional words.
He think he "helps" you to go directly to the problem, but the truth is that you can't answer correctly because you don't understand the context.
I’ve seen what you’re referring to as well, and you’re right it’s a hard problem to define.
I think this type of question likely falls under the “Can you fix my code?” category, where the junior dev knows better than to directly ask that question. But, instead of going the direction that I laid out in this article, they instead just try and mask their question with confusing jargon that they barely even understand.
It might help to be honest with them: tell them they don’t need to be ashamed for asking these types of questions and that we’ve all been there. Maybe then they’ll feel more comfortable and ask clearer questions.
Awesome article, Erik. Thanks! I just published something similar here on dev.to too and I couldn't agree more with the points you raised.
Good content , sometimes the way that you formulate a question make all the difference and save you a lot of Time , God knows that been a developer is Time consuming !!!!
Thanks for this. Finding an open source project is the next task for me