How to ask senior devs for help?

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 [e-mail] 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?

Comments

[David Lipschitz]

Ask questions, but don't expect the senior devs to do the work for you. There is so much help out there. Try to find it. In some cases I've hired very experienced people in my field to help me solve complex problems, perhaps UI issues that don't stop the program from working, but which would be nice if there was a better way of doing things.

[David Lipschitz]

Note that I personally believe in figuring things out for yourself. But if you have a process to follow and step 1 has failed, please don't try step 2. Try to figure out what's wrong with step 1, and then ask the senior / experienced developers for help.

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

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

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

[Heather Williams]

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.

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

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

[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/

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

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

[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

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

[sanidz]

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

[Gary Bell]

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

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