Iyfjky

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?

possible duplicate of How do I deal with a reluctance to consult with others? — Mar 6 '15 at 8:58
Question: "How do I ask?" Answer: "Ask" ; you have stated you are in a junior position; it is expected that you will not know how to do everything and it is just as expected you will ask if unsure about anything. — Mar 6 '15 at 18:57

score 29 · Accepted Answer · 2015-03-06 03:03:11Z

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.

Suggested addition (if you agree, feel free to edit in and flag this comment as obsolete): ask answerable questions. That is, be specific enough that somebody can help you without committing the afternoon, and have an idea of what you want to know. — Aug 19 '16 at 2:55
A single up vote isn't enough for this answer. Only addition I might make is a direct link to MCVE, a topic I've been thinking about putting together a talk on internally at our company. But the point about matching up question difficulty with team members is huge--not every question always has to go to the already-busiest colleagues. — Aug 20 '16 at 19:21
This one's definitely the best answer, and I will add this additional point from experience: ask your PM/Scrum Master/Project Leader to allocate time for one of the more senior developers to answer questions you may have. If the person you are asking has time freed up in his/her schedule to work with you, instead of your questions merely adding to his/her workload, you will feel much less resistance to asking, and s/he will have more freedom to answer thoughtfully and helpfully. — Aug 22 '16 at 19:56
Woa, woa, woa! Stack Overflow hates questions, especially n00b questions, so that's probably not that great of an example. — Oct 20 '17 at 20:36

Telastyn 33.9k977120 · Answer 2 · 2015-03-05 21:50:06Z

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.

+1 "...And even great programmers will regularly run ideas past their peers to make sure that the idea/design is sound...." — Mar 6 '15 at 3:49

fragilewindows 1133 · Answer 3 · 2016-08-18 23:14:50Z

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.

Tam Hartman 48228 · Answer 4 · 2016-08-22 19:41:49Z

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.

score 29 · Accepted Answer · 2015-03-06 03:03:11Z

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.

Suggested addition (if you agree, feel free to edit in and flag this comment as obsolete): ask answerable questions. That is, be specific enough that somebody can help you without committing the afternoon, and have an idea of what you want to know. — Aug 19 '16 at 2:55
A single up vote isn't enough for this answer. Only addition I might make is a direct link to MCVE, a topic I've been thinking about putting together a talk on internally at our company. But the point about matching up question difficulty with team members is huge--not every question always has to go to the already-busiest colleagues. — Aug 20 '16 at 19:21
This one's definitely the best answer, and I will add this additional point from experience: ask your PM/Scrum Master/Project Leader to allocate time for one of the more senior developers to answer questions you may have. If the person you are asking has time freed up in his/her schedule to work with you, instead of your questions merely adding to his/her workload, you will feel much less resistance to asking, and s/he will have more freedom to answer thoughtfully and helpfully. — Aug 22 '16 at 19:56
Woa, woa, woa! Stack Overflow hates questions, especially n00b questions, so that's probably not that great of an example. — Oct 20 '17 at 20:36

Telastyn 33.9k977120 · Answer 6 · 2015-03-05 21:50:06Z

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.

+1 "...And even great programmers will regularly run ideas past their peers to make sure that the idea/design is sound...." — Mar 6 '15 at 3:49

fragilewindows 1133 · Answer 7 · 2016-08-18 23:14:50Z

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.

Tam Hartman 48228 · Answer 8 · 2016-08-22 19:41:49Z

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.

Search This Blog

Iyfjky

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

4 Answers
4

Your Answer

Post as a guest

4 Answers
4

4 Answers
4

Post as a guest

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

Category

Random preview

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

4 Answers 4

Your Answer

Sign up or log in

Post as a guest

Post as a guest

4 Answers 4

4 Answers 4

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

4 Answers
4

4 Answers
4

4 Answers
4