This is an anonymous post sent in by a member who does not want their name disclosed. Please be thoughtful with your responses, as these are usually tough posts to write. Email sloan@dev.to if you'd like to leave an anonymous comment.
I'm a junior software developer with 1 year of experience as a product engineer. Sometimes I feel as though I'm asking for too much help & have too many questions.
How can I go about asking for help & to what extent should I ask for help? Is it normal for junior devs to asks programming or framework-related concepts to senior devs?
Top comments (24)
Yes :) Completely normal!
I would say, if you think you need help, stop and consider if you've researched every avenue. I prefer a junior dev coming to me and saying "I'm stuck on X, I've tried A, B, and C, but it hasn't worked" rather than just "I'm stuck on X". It shows initiative in them trying to learn and understand on their own, they've just hit a brick wall. The best way we can learn as developers is by doing. That also means failing, and doing the wrong thing.
If you're in an environment where you feel you can't ask for help, that's toxic. A good environment encourages questions, collaboration, and joint progress/learning. Our industry moves forward so quickly we can't keep up with everything at once.
Adding to this, it is good to keep a digital notes, a summary of what you did and what did not work (e.g. errors) this way you can share it to your senior or your team and they can check whenever they're available, so you can avoid the bad timings of interruption if they're focused on something. This is also good when you've solved the problem, take note of the solution provided to you, so whenever you've experience it again, you can come back to your notes and avoid bothering your team again for the same problem.
I agree. Remember that in many cases you learn the most by figuring out the problem yourself, but don't struggle too long. "Too long" is team/task dependant, sometimes 1 hour is too long, sometimes 1 week is too long. When in doubt ask a "quick" question of a senior about if they think you've been struggling too long. They may have a quick tip that may put you on the right track to figuring it out. Ask what to look for to lead to a solution (for cases where you can't find a bug or what might be obvious to the senior in a log file), the information to that question can be gold for future investigations.
Also, don't expect to be "spoon fed" (i.e. given the answer) all the time. If you can't deduce how to solve a problem you will stay a junior for longer. Learning how to solve a problem is the part that is rarely taught during any education, in many cases because it's different for each person.
It's part of senior engineers job to help unblock others. Don't feel bad :). Their purpose isn't to write code all day. It's to help level up the team + write some code.
A couple thoughts:
I'd recommend asking in a public channel if you can. Then there's multiple people who can help. Which distributes the questions beyond DM'ing the same person.
It also helps if you can include as much info as possible in a single message. Then that reduces the back and forth. @nataliedeweerd explained this well in their comment.
Everyone who is senior was once in your position. They remember how it feels. And soon enough, you'll be the one answering the questions.
I have been doing development for almost 25 years now, so I can speak from experience here.
Part of being a senior developer (probably the most important part) is to teach and mentor other people. And it is not just about helping other developers, but personally I also see it as another learning experience for myself.
After doing development for years you will notice that certain things will go "automatically". You implement something without any thought (of course you think on how to solve it, but since you recognise problems you also quickly find solutions). If someone asks questions about it... and especially the 'why' question, it makes you think again on why certain things are solved in a certain way. For the less experienced developer (I hate having names like junior, medior or senior) it is gathering of knowledge. For the experienced developer it is a reality-check. Explaining why something is done in a specific way also might bring other solutions, or problems, to the surface.
What I also learned over the years is that people are somehow scared to ask questions and think they are asking too much (just like you indicated). If you start your question with "Can I ask you a question about....", you allow the other developer to quickly consider the topic and estimate how much time it would cost to explain something. If he/she is in the middle of something, the reaction could be to come back later. This is not a way to tell you that they do not want to answer your questions, but are probably in the middle of solving a problem and want to keep their focus... and do not forget to indeed come back later, because the developer probably already has forgotten you had a question in the first place.
Best times to ask questions, is at the start of a working day... or right after a lunch or coffee break. The developer then did not start working again and is out of focus anyway (unless he/she had a great idea to fix a problem that he/she was struggling with).
But again.... do not ever stop asking questions!
Oh, and it works both ways!! If you see another (more experienced) developer sweating, sighing, etc... ask if you can help and if the problem could be explained. It feels very counter-intuitive, but is in fact very helpful. By explaining a problem to someone else, you almost always find the solution you were looking for.
Well said! I second this view point, ESPECIALLY your last point! I've been stuck on several occasions along the way and I've found that if explain the problem to somebody (anyone really, lately it's been my wife) it clears your mind long enough to solve the problem.
I'm so glad you're asking how to ask for help! As someone considered a "senior dev" by the rest of the team, I'm often the one called upon to help -- and I enjoy helping, but there are some tips which can make it much nicer all around:
The primary differences between "junior" and "senior" developers, imo, are:
At the end of the day, a good "senior" dev should always be willing to help, but you can make the whole experience a lot more pleasant by following the plan above. Just like you, we have dev tasks we need to complete, and business often expects us to complete more, quicker, so our time is both limited and quite precious. However, we should be more than willing to give it, if for no other reason than that we're all on the same team, and when one team-member is struggling, the whole team is not operating at full potential.
From experience I would say that the golden rule is to minimise the amount of interruptions. I prefer to spend 1 hour to explain several things than to be interrupted 6 times for 10 minutes 😅
After that, it's all a question of balance. Research is very important but if you stay blocked for hours on something, everybody loses. It shouldn't be a problem to ask a (few) question(s).
Junior dev should be called apprentice dev. You'll "never learn" without input from masters (hyperbole but you get my point).
Do some googling first b4 asking and maybe consider spreading your various questions to multiple seniors
One option is to query your teammates that are also reasonably junior, as they may have figured out the one point that finally made a solution obvious (in many cases some tidbits within the product/organization are globally useful and may not be obvious to more senior people). Even if your peers haven't figured out a similar problem, the solution or ideas you learn from them discussing your problem may help, and ideas you think of during your investigation may be useful to them in return.
I take the following approaches when I need help from an experienced developer:
Whenever I am assigned a task, I always ask who is the best person to ask for information and coding help if needed
Whenever I am assigned to a task, I always ask if there are any documents related to that task that could help me understand things better (not everything can be googled).
Before reaching out to a senior, I'll build the necessary setup so we can quickly navigate to the problem. If my lead developer is not in the same location as me, I will write a team meeting invitation (email) describing the problem
If the senior reacts with an aggressive attitude (this is not uncommon), I politely ask him if he has time for a coffee break and try to build a relaxing conversation
I also always thank everyone who takes the time to help me, even if the person did not manage to solve my problem
When I am frustrated, I share my feelings and reasons with my manager. Sometimes the solution is a workshop.
I think the most important thought is to understand your feelings and current skills and to take the time to communicate them clearly.
The way I would hope my junior devs would work is as follows:
I know that it's not easy to see who is available (especially during COVID remote working), so people may skip that part and come to me. But it is my job to help. If I can't (as in literally cannot spare the time at that moment - usually because I'm about to go on a call) I'll ask them to interrupt someone specific.
It's a very specific point in my induction process for new developers that it is more than OK - it's actually expected - that they will have questions. Ask those questions and, if you forget the first time, ask it again. If you need something explaining again because you didn't quite get it, it's not your fault, it's mine. I didn't articulate it clearly enough.
If you as a junior developer fail, it's not because you aren't good enough, it's because I failed you. If you actually aren't good enough, then I failed you by hiring you for the role and not interviewing properly. Or I hired you thinking I had more time to help than I did, so I failed due to bad planning. It's (almost) never your fault as a junior developer if you don't understand, or if you make mistakes. You will learn in time.
My point of view is, that we seniors (I do the job since 2000) want make every junior able to work indepently. But we also not want do make the juniors dependent from us.
I also work as trainer for new Software Developers. We talk about the issue of asking questions and use the following ruleset:
Show what brings you to the point to ask your questions. Most questions are not the point, but the work before.
Be sure that you not just want to get a fast solution for your problem by asking the senior. The way to become a professional is quite hard. We want you get get experience in that.
For me this is the big difference in beeing a junior. Juniors need to learn methodical thinking with the help of the seniors.