Asking questions at the right time, in the right way, to the right person
Almost all freshers will agree that they've been encouraged by their teammates and managers to ask questions. However, this has a fine print : it actually goes, 'ask questions, if you can't find out the answer yourself'
And not because they don't wanna answer, but because
- If you keep asking questions you can find out with a few google searches, you're no good as a developer - you need to learn the art of googling.
- The managers/teammates usually have tasks of their own and are helping you on the side, which means that more often than not, they won't find enough time to answer your questions.
- Answering questions is wayyyy tougher than asking them, especially if you're answering to a noob. Suppose you ask a question that you think is innocuous, and has a one line answer - "What does this imported package do". Now, your teammate's mind races back to what the package is, why it was brought in, why it's used, how it's used, and a few zillion other things, most of which would make no sense to you. So, she/he has to filter these out in a way so that you're able to grasp the essentials without feeling dumb or overwhelmed. That's tricky business.
So, what should you do? How should you 'ask questions'?
First, the 'right way'
- Any query you find, first google it. Right away, as it is. Maybe you find a blank google search result - very very rare. You'll find something that can complement your understanding in some way, even if it doesn't give you the complete answer. But you'll at least have some more idea and can ask the question to your teammate in a more refined way so that the tough choices your teammate would face, mentioned in point 3 above can be minimized.
- Instead of asking a teammate to explain it all - tell her/him what you've understood and ask her/him to validate/correct you. If you've got it 70% right, the teammate only need explain 30%, saving both of your times. If you've got it entirely wrong, the teammate would know that there's something lacking in your fundamental understanding and correct that first. If you've got it entirely right, you're getting a promotion sooner.
- Try asking the teammate for a resource where you can learn more about the question you're asking. That way, the teammate will not be under pressure to explain 'everything' to you, and instead, guide you to a resource, which can help you better.
- Make a habit of taking notes of what you ask and their answers. We often overestimate our memories and underestimate all the crap that's gonna take a chunk off our memories, so you best have it in written somewhere so that you can save yourself from your teammates' irritation by asking the same question 20 times.
Next, the right time. If you're an overexcited sorta person, you wanna know the entire architecture and each and every package right on the first bloody day of the job, because you then wanna go and be Napoleon. Or if you're the shy sort, you keep stalling, waiting for the 'right time' until it's too late. Figuring out the right time to ask comes mainly with experience, but a thumb rule is that if it's something that's blocking your progress, ask it right away. If you think the teammate is going to come to this question, give her/him an opportunity to address it. If they skip, then ask. Finally, ensure that the teammate is in the right frame of mind when you ask a question, not when they're debugging a critical prod issue.
Finally, the right person. You could ask the same question to an immediate senior, your manager, and your team lead, and get different answers. You need to figure out which of these would work best in the context in which you're seeking an answer.
For instance, if you're struggling with a syntactical issue, you should most likely reach out to an immediate senior, someone who has the closest interface with the code, since they can give you the quickest answer. If you're looking at understanding a big picture of a project or a feature, someone who's been around longer can help better.