How to ask senior/mid level developers for guidance (if you're a junior)?

Question

I want to ask a twist to the popular question that was posted yesterday about the junior developer who refuses help.

Just some background...I recently graduated and have been working with my company for 6 months now as a junior. I am the lowest on the totem pole on my team, with the rest of the team consisting of two mid level developers, two seniors, and one technical director (who I report to and I guess is the best programmer on the team). I have been getting mostly low-risk maintenance assignments and tasks, which is expected and I have no problem with.

Soon, I will be tasked with developing an internal tool that will improve productivity with deployments and operations that is sorely needed here. In my Master's program I took classes on requirements elicitation and coming up with designs and use cases and all that, and feel that I would be okay there. The difficult thing I am facing is how to actually think about programming all of it in terms of how to abstract databases, creating data models, coming up with effective APIs, GUI design, and so forth. It is meant to have front-end and back-end components which I like, since I will develop great skills that way.

However I find myself nervous, because I don't want to screw this up. I am by no means a great programmer simply by natural talent, but I know it can be learned to some degree. I aspire to become a great engineer followed by management in my future, and I know I need guidance from senior people to get there.

Everyone on my team is swamped, and it's very hard to ask for advice without feeling like I am bothering them, and I feel useless sometimes. What is the best way to go about asking for advice without seeming like a complete noob, and doing it with enough tact as to not take away from the productivity of the team?

Answer 1

A lot of the same best practices for asking a question on Stackoverflow apply to asking your coworkers. Which makes sense if you think about it; the only big difference is that you're asking strangers on the internet rather than your coworkers. In fact, you mention that your team is extremely busy, so if you're allowed (would you need to release proprietary details or have you signed an NDA?) and think it's reasonable to do so, you might consider asking first on SO rather than going immediately to your teammates. Doing so may take longer to get a good answer, though (it might not, but you should expect that it will and act accordingly).

On asking:

• Show you've put effort into understanding the problem. You should be able to have a reasonable discussion about the matter. This doesn't mean debating the implementation nuances of a complicated algorithm or the which compiler optimization flags to use. You're in a junior role, so it's unreasonable to expect you to display mastery of advanced material. But you should be able to explain what you know and what you don't, and ask intelligent questions about the material.
• If it's regarding debugging code, you need to show specifically what goes wrong, where, and how. A guess about why would be helpful, but isn't necessary. If your colleagues ask you to try something but you don't understand its relevance, do it without complaining. You should ask why it would help, but make it clear you're doing so because you want to learn, not trying to argue with them.
• Don't expect handholding. If they offer a broad solution or a general idea, make an honest effort at implementing it. If you have specific problems, you can always ask again. But if you ask for complete solutions or help with simple syntax, they will quickly tire of assisting you.
• Don't ask for immediate help unless it's an emergency. You have to fix a critical production bug in two hours and can't figure it out? Then it's appropriate to go physically ask someone for help ASAP. If it's not an emergency, send an email or IM so you don't interrupt anyone's workflow. If they don't answer quickly or ask you to wait, don't be offended. They're not criticizing you, but simply prioritizing tasks.
• Try to match the technical level of the question to the experience and workload of the coworker you ask. Don't ask the team lead what the syntax for an anonymous function is; one of the mid level developers, who are probably less busy, can answer this easily. Conversely, if you've found an error in critical code that only the lead has write permissions on, then it makes little sense to talk to the mid level devs.
• Most importantly, don't be afraid to ask questions. You don't know everything; nobody does. You're in a junior role; questions are expected. I'd be worried about a junior teammate who never asked questions. How are you going to learn more without asking about it? Putting in reasonable effort is different from assuming you have to do it all on your own. Spending forever trying to independently solve a problem is a waste of time, and therefore, money. Not just your time, but also the time of whoever has to review your work. And fix it, because your solution to a difficult problem will very likely have its own problems.

There are a few key ideas about asking questions that underlie these points:

• Other people's time is valuable.
• Display desire to contribute and learn.
• Asking for help is not a sign of weakness.

Which questions you ask and how you ask them is one of the biggest indicators of your usefulness and ability. In a junior role you'll be judged on how you learn a lot more than what you know (assuming your colleagues are reasonable people). Asking insightful questions and showing that you learn from the answers will earn you respect and credibility.

Answer 2

What is the best way to go about asking for advice without seeming like a complete noob, and doing it with enough tact as to not take away from the productivity of the team?

"Hey Alice/Bob, do you have time to talk through this thing I'm working on?"

"No? Maybe this afternoon?"

Seriously, programmers these days work in teams. And even great programmers will regularly run ideas past their peers to make sure that the idea/design is sound. This is common, and to a degree, expected.

As a beginner at the company, you'll have questions about how stuff works at the company. You can't google for it, so you might as well stop wasting time and ask. As a beginner with a technology, you'll have questions about how stuff works in the technology. Sure, google can help here, but not as well as an expert with a whiteboard. These questions are common, and to a degree, expected.

So be humble, but stop wasting your time and potential by not asking. Do a bit of research/experimentation on your own so you can ask good questions, but then just ask and listen to what they have to say.

As long as you're reasonable (1-2 questions a day is fine. 1-2 questions an hour, maybe not) and learn enough to not ask the same question again and again, it'll be fine.

Answer 3

First always be polite. I know this goes without saying I just thought I'd reiterate a bit. Something as simple as asking if they have time to speak with you before asking your question or thanking them for their help after they answer, can go a long way. They are taking time out of their busy schedule to help you, the least you can do is let them know you appreciate it and that you realize they're busy.

Understand the difference between asking for help and asking them to do your job. This can be a finer line than you think. Do your homework first. Show them that you've investigated the issue. Tell them where you're stuck and what exactly is causing you to hit a wall. "How should I proceed with X?" or "Do you have any idea what vague error message Y might mean?" are okay, even expected from a junior developer (I should know, by most standards I'm still junior myself). But "hey how do I do X? Could you show me a code example?" is bad. If they're just going to write the code themselves, what do they need you for?

That being said understand that it's okay to ask questions. At some point everybody has jumped down a rabbit hole only to realize hours or even days later that they were going about things all the wrong way. Most senior developers, team leads, managers, software architects, etc. would rather take 5 minutes to answer your questions in the beginning so that you go down the correct path than risk things getting held up or hard to fix bugs being introduced because you did things the wrong way.

If the question is not time sensitive, I suggest contacting them via instant messenger or email. These methods are unobtrusive and can be addressed at their leisure.

If somebody is nice enough to really sit down with you and help you out don't argue with them. It's fine to voice concerns or ask for additional details but when you do, be careful how you word it. Make sure the person understands you just want to learn more about whatever it is they're teaching you and not that you're trying to question them too much.

No matter what you do, no matter how innocuous your questions or how polite you are, you will occasionally annoy them. It happens. They'll probably get over it, so will you, if it means the difference between you being able to complete your tasks and meet your deadlines or not.

Answer 4

When working as a team open communication (without being distracting) is key. Be as informed as you possibly can about each element that you're exploring before you bring it to someone else. For every problem that you pose, try your best to come up with a solution before approaching someone else on your team. It's always better to posit problems/solutions in pairs.

One thing to consider is that if everyone knows you're a junior dev and it's your first major project, they'll want to see what you can do but they'll also probably be a bit more understanding about helping you out. Aside from that, do your best to have a sense of situational awareness (don't interrupt existing conversations unless they go on forever and you need an answer RTFN, don't bother someone in crunch time, just common sense stuff like that). In all honesty, the other people on your team will value you coming to them if you need something rather than keeping it quiet and surprising them with issues later.