When you first start working as a developer, it can be a bit daunting to learn about the way things work among your fellow co-workers. As a junior developer, you probably feel and don’t want to burden the more senior developers with stupid or mundane questions. And as a senior developer, you probably don’t want to just spoonfeed them the answer and want them to learn.
When I first started, I used to simply say things like this. “Hey, I don’t know how to do this, can you help me?”
Then it slowly evolved to something like this. “Hey, I’m not sure how to do this and I have tried doing [stuff], what do you propose I should do?”
It might not be a big difference, but the first question acts as if you want them to solve your problems. The second question shows that you are being proactive and a lot more motivated.
Let’s discuss! Senior developers, what do you expect from new/junior developers when they ask questions?
Top comments (4)
I think you nailed it.
As a junior in my current tech stack but senior in general I can be in both sides at the same time. (aka the Schrödinger's seniority 😂)
It's very important to show the senior how commited you are with this, that you're ok knowing you don't know but you tried to solve by yourself... but... the next question could be, did I spent too much time on this task?
That's why you ALWAYS should try hard to ask as much as you can before start the task even the easyest ones, because at that time the senior is mentally prepared for your question storm, and really WANT to help you.
Where this feature should be placed in code?
What is this bug causing exactly? How the end user usually notice this bug?
What is the expected behavior? And the current one?
Where is a similar object/component/piece-of-code that does something similar than this? Why aren't we using that and creating this new code instead?
That generic questions can help you, junior, to have a smooth start and ask better questions later.
I love this tip and I agree. Questions in the beginning is a lot more welcome than questions in the end.
Plus, by struggling with it yourself first, the solution will be a lot more meaningful. And honestly, once you know it (and feel some confidence it's correct), I'd highly recommend going through the thought process again, possibly even several times, so that you can get from that problem to that solution in the future. The first time is the hardest, but only yields like 20% understanding. Thinking through it 2 or 3 more times takes less time and effort and gets you another 40-60% understanding.
An understanding of the goal. Skepticism (but not like unreasonably so, more like what a scientist would do, like "okay, I think I hear what you're saying, and if I unde__rstand correctly, then this should be true, let me check it with you to see"). Really, if anyone sciences an answer I give them, then I will feel so happy about how we spent that time (even if I turn out to be wrong).
Great post! I really like how you explained the difference between “Hey, I don’t know how to do this, can you help me?” and “Hey, I’m not sure how to do this and I have tried doing [stuff], what do you propose I should do?”
This is a skill I have been developing in myself over the last few months because 1. My manager doesn't want to babysit me and 2. I hate being handed an answer anyways.
If I have absolutely no idea where even to begin, I will say something to the effect of: "This is completely new to me and I don't know where to start. Can you point me toward a good google search query or tutorial you've had luck with in the past on the topic?" This way he can give me the nudge I need but not have to hold my hand the whole way.