loading...

How to ask senior devs for help?

sloan profile image Sloan ・1 min read

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?

Discussion

pic
Editor guide
Collapse
nataliedeweerd profile image
𝐍𝐚𝐭𝐚𝐥𝐢𝐞 𝐝𝐞 𝐖𝐞𝐞𝐫𝐝

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?

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.

Collapse
zaerald profile image
Zaerald

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.

Collapse
millebi_41 profile image
Bill Miller

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.

Collapse
mscccc profile image
Mike Coutermarsh

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.

Collapse
leviter profile image
Marcel van den Brink

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.

Collapse
klawrow profile image
Claro A Briones

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.

Collapse
fluffynuts profile image
Davyd McColl

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:

  1. Do your homework. Yes, I know that, especially when you're new to things, it's difficult to even know what questions to ask, but at least try to google stuff yourself. Keep a record of what you've looked for and what results you've found -- you'll need it later
  2. Start with an email. Not a slack message, or gtalk, or zoom, or anything "instant". Bear with me, there are good reasons.
  3. Lay out the problem you're experiencing in detail in this email. Add your results from (1). Re-read this email to yourself -- if someone else sent you this mail, do you think you'd have enough of a picture to start helping? Pinging a colleague with a short message like "hello?" or "I'm stuck" means you're putting the onus on the colleague to pull information out of you. This is another reason for using email and not some kind of instant messaging for your first round here -- it should encourage you to take the time to compose a thought-out question and show that you have tried to solve it yourself.
  4. Send the mail!
  5. Follow up with an instant message (eg Slack), no sooner than 10 minutes later, if:
    • you are completely blocked and can't work on something else
    • you haven't had a reply to your original mail in 1/2 a work-day (so, if you mailed in the morning, only message in the afternoon; if you mailed in the afternoon, message next morning)
  6. In an attempt to help people learn on their own, I often won't give the full answer to the question, but will instead try to guide them down a path of discovery. Whilst this may sometimes be frustrating, especially if you've been churning for a while, please bear with me! I really want you to learn as much as possible, and part of that learning is figuring out the techniques for answering questions on your own.

The primary differences between "junior" and "senior" developers, imo, are:

  • direct experience: there's a lot of things we've done before, so we can do them again
  • we've learned what questions to ask, so when we get stuck (and it happens plenty, trust me), we know where to look online, or at least how to structure a question for a web search
  • we're persistent: you can't get to a high level in this game if you give up too easily
  • we experiment: if we don't find an answer to the exact question we have, we might try tangential solutions, or variations of those solutions to figure out if perhaps our problem is related and just not documented online
  • we know the experts in our team, so when we have a problem in a specific area, we know who is most likely to be able to help with the least amount of effort and time
  • we may know experts outside of our team, who are equally invaluable, and we realise that we can't expect them to drop everything to respond, so we already follow steps like the above to elicit help

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.

Collapse
kant312 profile image
Quentin Delcourt

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).

Collapse
drewmullen profile image
drewmullen

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

Collapse
_garybell profile image
Gary Bell

The way I would hope my junior devs would work is as follows:

  1. Have a bit of a play and see if things make sense
  2. Get on your preferred search engine, and try and find the answer
  3. Speak to someone on the team who is available (to help bring them along)
  4. Come find me and ask me

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.

Collapse
incrementis profile image
Akin C.

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.

Collapse
klabautercoder profile image
klabautercoder

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.

Collapse
millebi_41 profile image
Bill Miller

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.

Collapse
kimberleejohnson profile image
Kimberlee Johnson

You are not alone in feeling this way! I know how scary this is, and I found Julia Evans' guide to asking good questions really helpful to me. I hope it helps you too!

jvns.ca/blog/good-questions/

Collapse
dwd profile image
Dave Cridland

I'll let you into a little secret. Senior devs ask these questions of one another too. When Junior devs ask us, we have a hope of actually answering the questions, and that's quite a nice change...

Collapse
mmc profile image
mmc

This was a good question. I agree to everything people have said above. Be humble, be enthusiastic to learn, but also be aware if you're in a toxic work environment.

I was in a job last year where I found out later I was hired to do part of a job that the senior dev didn't make time for. He was out to get me from the start, first ghosting me the first two weeks, then inconsistent communication and taking every opportunity to try to make me look "bad", especially to my manager and in front of our team. I was chastised for "asking too many questions" (about the codebase I inherited), and then shortly after, "he's not asking enough questions".

Just do your best, assume people have positive intentions(until proven otherwise), and try to find any way of becoming a valued member of the team.

Collapse
sanidz profile image
sanidz

Yes, try "Oi you old wanker, I need help with this nonsense code of yours"

Collapse
_garybell profile image
Gary Bell

To which the usual reply is "which part, there's so much nonsense code there?"

Collapse
alexgwartney profile image
Alex Gwartney

So while I have not gotten into the programming side of things yet. I can say personally working in the IT support side your never going to know everything. And when I first started that's all I did was ask questions. I feel like in any job they expect you to do so its how you learn.

If anything I feel like if someone was not asking questions. Then there is something wrong. I however personally when Im stuck on something I will ask a more senior colleague, in a way that shows I at least made a solid attempt unless Im just completely stuck.

This way you are at least showing that your willing to try and think something through before just saying hey can you come help. So it does not come off as them doing all the work ect.

Collapse
_rodrigomd profile image
Rodrigo 👨‍💻🤙

Hi,

You just have to ask. Senior developers are used to receiving questions, and most of us love to help and advise others. It is a mutual benefit; that way, we refresh our knowledge and consolidate concepts and ideas.

I recommend that you consider before asking that you have at least identified the problem or are clear about your doubt; try to find the answer by yourself beforehand. By the time you get help, there will already be a base from which to start.

When asking, it is useful to give context about what you are doing and inform your working environment: code editor, language, libraries, frameworks, operating system, etc.

Never stop asking. Some people will respond to you, and others will not. If you are respectful, you will have no problem.

Remember, there are no dumb questions. You will never learn anything if you do not ask questions of others or yourself.

Collapse
heatherw profile image
HeatherW

From my own journey I learnt the following useful things:

  • No question is too dumb. You may laugh about the silly thing you asked later but ask it. I once had to have someone else point out to me that my external screen was not switched on and that is my laptop appeared to not be working.
  • Read everything you can find about dev and in particular the tech you work with. Experiment with it, almost anything you do can be undone if you do break something. I have deleted crucial things before but learnt a lot in fixing the trail of destruction.
  • Be willing to learn. Take notes if that helps or find other ways of learning. After each project you work on summarise what you learnt.
  • Communicate. Let the senior devs know you want to learn but ask them to tell you if you are asking too many questions or bothering them too much. Usually though they are happy to help and teach others.
  • If you work at a company where mentorship is not important to the company and they do not really care about how you progress then consider finding somewhere else to work.
  • Keep track of your skills and the sort of things you are needing to ask, over time you start seeing progression and that helps you realise you are levelling up.

In short junior devs should have a good grasp of the basics of the programming language they work in, if you are asking questions about things like types (strings, ints, booleans) or writing basic logic then perhaps you need to revisit that and get good at that. But you cannot be expected to know about big architectural things or how to make a brand new table in a database, those things come with time and experience. By the end of the first year being a junior dev I should be able to give you e.g. a well spec'ed sign up form and you can implement just the form part with little guidance. But if I gave you a spec for the entire sign up process on a website I would expect to need to guide you through some steps in the process.

Collapse
jmlweb profile image
José Manuel Lucas

I couldn't call myself a senior developer if I won't be open to mentor and help other developers with less experience...