9 ms·

The hardest part of being a junior developer

119 points by pzrsa 4y ago

pickledish 4y ago
I like the advice! I think giving such a specific figure (one hour of spinning your wheels) might seem arbitrary to some people, but I can think of several folks right now (even myself in the past) who would have really benefitted from some kind of loose framework like this, instead of just “feel free to ask a question anytime”
apozem 4y ago
One time, as a junior, I was struggling with an old company API. I tried and tried to figure it out but finally broke down and asked a senior. He explained the problem and unblocked me. The incident always stuck with me because this problem was literally un-Googleable. It was an internal system that required a super specific method of interaction you’d never discover by accident. The only way to use it was to ask for help. So yeah, I agree with the author. Timeboxing tasks for juniors is a good way to teach them when to ask for help or clarify requirements.
debacle 4y ago
I give all my juniors a score from ~2-4, which is a multiplier on the estimate for any task they're assigned. If it would take me N hours to do something, I expect them to take no more N*M hours to finish the task, and if at any point they feel that estimate is wrong they should let me know. Usually it takes them 2-3 tries to realize that this system is in place to help ensure: 1. They understand the scope of the task 2. They don't spin their wheels too long on any one thing. When hiring juniors (mostly interns to direct hire), the two biggest things I look at are: 1. Do you do things outside of your coursework to enrich yourself? 2. Do you ask a ton of questions in the interview? The best intern we ever had (he is at Apple now) asked so many questions during the usually 45 min interview that I think it went to almost 2 hours. He was a phenomenally conscientious hire and managed his own time impeccably well.
jedberg 4y ago
Being a good manager is all about setting context. Timeboxing is actually helpful for senior engineers too, but for a different reason. When I ask for something that I have no idea how long it should take, I'll say something like, "don't spend more than half a day trying to get this to work. If we can do it that amount of time then it's worth it to the business, otherwise it's not worth the effort". If they can't get it done, no problem. I just ask them to document what they tried so that if someone tries it again later they have a starting point. Setting the context let's them know how much effort to put in regardless of junior or senior, it's just for a junior employee the context is less "value to the business" and more "here are my expectations".
cke 4y ago
This one hits home for me. Early on in my career, I had a "mentor" tell me to try it on my own before asking any questions only to swear under his breath when I messed up. It was a massive source of anxiety balancing between asking a question and the risk of messing up. When working with junior engineers nowadays, I go out of my way to let them know that any question at any time is acceptable. I'll put down what I'm doing and help them through a problem and then celebrate the solution with them. I never want them to feel the fear of work and failure that I did.
- Raed667 4y ago
  Agreed, but with the caveat of not making every single problem you encounter become your team's or your manger's problem. I've seen this especially with some interns, where given the (valid) advice of not being afraid to ask questions, go overboard and make every single task they might have everyone else's task as well.
  - actually_a_dog 4y ago
    Sure, that happens. But that's pretty easy to deal with. Just tell them before they start asking for help, they have to at least do some thinking about the problem. The explicit 1 hour time frame in the article is a great guideline.
    - Raed667 4y ago
      There is a difference when you say look for "at-most an hour" and "at-least an hour" before reaching out.
      - actually_a_dog 4y ago
        By Jove, I think you've got it! I'm not saying "do not bother me before precisely 60 minutes have passed," but just "go spend some time with this before you start pulling in other people, but also do not hesitate to pull someone else in if you've made literally no progress in about an hour."
rejectfinite 4y ago
Same in IT in general. Probably a lot of knowledge based jobs.
mkl95 4y ago
I loathed my time as a junior developer. Being a senior dev is like working in a different industry. Leverage beats jerks like rock beats scissors.
- tester457 4y ago
  > Leverage beats jerks like rock beats scissors. Could you expound on this?
  - DangitBobby 4y ago
    If you're senior people can't be assholes to you without risking you walking out.
Waterluvian 4y ago
I had a mentor at my last job who clearly really didn't want to be one. It was to the point that I would sit paralyzed behind him, loathing turning around to get his help. In all fairness, I had yet to learn a good way to get help without interrupting his hard work. I'm not sure he ever fully knew he was my mentor, but without his help I was completely blocked on making any progress on the deep-end project I was thrown into. What we both needed was the company setting very clear, explicit expectations. "X is your mentor. X's main job is to mentor you and help you swim in this deep end." Though I think the entire company was learning a ton of stuff at that phase. Thanks X for all your tolerance over those years. You have no idea how much you saved me, despite my loathing to bother you yet again.
- TideAd 4y ago
  I have a couple quasi-mentors like this. I'm stuck between feeling grateful for what they taught me (a whole lot) and feeling absolutely sure that I will never be that neglectful to a junior dev in my own career as they were with me.
- saghm 4y ago
  > What we both needed was the company setting very clear, explicit expectations. "X is your mentor. X's main job is to mentor you and help you swim in this deep end." Though I think the entire company was learning a ton of stuff at that phase. It's been a while since I've mentored someone, but that was always one of the things I made sure to mention in my first conversation with any interns/new grads I'd mentor: "While you're here, mentoring you is the highest priority thing for me to do. If there are ever any times when I have something so time sensitive that it would take priority over answering your questions, I will explicitly let you know. Otherwise, always assume that it's okay to ask me something, because if for some reason I can't answer and you don't know that, it's my fault for not telling you." It helped that the company where I worked at the time had very explicit time periods where someone was considered a "new grad" versus a full team member (since they actually would rotate on 3 teams before ending up on one of them full time), so this strategy might not work as well in places where the expectations for mentors are not laid out as well, but I honestly think that it will almost always be the best strategy to just be open and communicative with anyone you're mentoring. Mentees are just people like anyone else, and them being inexperienced as engineers doesn't make them any less able to understand clearly communicated guidelines, and if you need to adjust the guidelines as you go, there's no reason they can't understand that too.
pydry 4y ago
Onboarding is hard even as a senior. On the one hand interruption is expensive: https://heeris.id.au/trinkets/ProgrammerInterrupted.png https://heeris.id.au/trinkets/ProgrammerInterrupted.png On the other hand, spinning your wheels trying to figure out something for an hour is expensive. I've never really found a solution to maximizing my "interruption budget". Inevitably I end up both spinning my wheels too long sometimes and interrupting too much at other times. Meanwhile trying to solve this problem also consumes way too many brain CPU cycles.
halfmatthalfcat 4y ago
I just had to talk with a couple more junior people on my team about this. We're having difficulty on people wheel spinning and taking too long to reach out when there's problems but it's not because they can't but there's a sense you develop as you gain more experience on what that "red line" is when you need to reach out. It's a combination of experience with the task (language, codebase, etc), agile point values (or just "level of effort") and how easy it is to approach those with the answers. As they're continuing to do work, evaluate where the time you've currently spent matches up to each of those three things. If you've hit that red line, time to start sounding alarm bells (relatively). It really is a learned skill and takes time, juniors shouldn't feel bad and seniors/leads shouldn't make them feel bad. Seniors/leads should also be planning for learning this skill into their estimates to stakeholders.
Scubabear68 4y ago
This is not limited to juniors. I know some fairly senior devs who are afraid to say “I don’t know” or admit they are stuck. Particularly when they are working on someone else’s legacy code that may be of dubious quality. It is a shame, because in many cases just a little humility and admission they are human would make them much stronger developers. As it is, it leads to a level of distrust and uncertainty within the team and with management.
- warvariuc 4y ago
  I often recommend this video to Juniors in IT: [The Myth of the Genius Programmer](https://www.youtube.com/watch?v=0SARbwvhupQ https://www.youtube.com/watch?v=0SARbwvhupQ)
marmetio 4y ago
Time boxing progress their is good, but it also helps to explain how to ask for help. I tell them if they get stuck to give me a short writeup on the objective, what they tried, why it didn't work, and their questions. It makes them reflect on their work and helps me understand what they need. After a few times, they can usually solve most of their own problems.
Justsignedup 4y ago
I solved this problem, quite well, and still do this all the damn time: 1) try to solve the problem 2) Gee, it's hard. shit. okay think think think 3) okay ask for help. wait... let's write a slack message. First write the problem, explain exactly what you tried, and ideas for next attempts. Explain your confusions. 4) OMG I SOLVED IT or 4a) Hit send. I find that 70% of the time, I don't hit send. 30% of the time it was worth asking.
- tomkarho 4y ago
  Before slack, Stackoverflow was my rubber ducky.
- bob1029 4y ago
  I have an additional trick - If you are the person of whom help is frequently asked, employ a nominal delay before you get into it. "Sure - let's get on <conference line> in 5 minutes" I've found this to work well. "hang on I'm going to try 1 more thing". And, then you don't hear from them until tomorrow.
  - bluefirebrand 4y ago
    I use this trick a lot. I tend to vary between 10-20 minutes though. I also usually give them a starting point. "Hey I'm in the middle of something. I can chat in 15 minutes or so. In the meantime if you haven't yet, try X, Y, Z" This helps push them to at least try something so when I ask later "Did you try X Y or Z?" They can have some kind of answer.
  - groffee 4y ago
    I found this in a non-development role, this lady would constantly phone me for 'help' and I found that if I just ignored her (in a nice way) she'd fix it herself in a few minutes.
  - Justsignedup 4y ago
    brilliant idea. i will use this
- 4y ago
kiachnish 4y ago
As a fresh grad SWE I have felt this insecurity as well. "Seven Tips for a Junior Developer" [0] has some good parts on asking for help, and on the pendulum between unblocking yourself versus reaching out to others. I would love to read anything else on the topic. [0] https://www.pearlleff.com/seven-tips-for-a-junior-developer https://www.pearlleff.com/seven-tips-for-a-junior-developer
pm90 4y ago
Setting explicit time frames is really useful for both the mentor and mentee (or manager and employee etc). If someone is unable to complete a task within a set time, but explains their thought process and what they tried, I consider that to be a completely valid use of their time. Even if they are completely honest and say: "This seemed too hard and I tried for the first 15 minutes and then got bored and procrastinated" that is also ok. We're all humans after all. Its when someone spends their time on excuses and fobs that is really annoying and unproductive. Generally: most people will invent excuses. People that went to college (I went to college!) get really good at this since you need to invent excuses all the time to get past annoying social activities and classes. In most cases, providing the space to fail and proceed allows developers to gain the confidence to be upfront. Of course there will always be those that don't get the message, or try to game the system. But they tend to fall really really far behind and it becomes pretty obvious that they're not doing well.
- inopinatus 4y ago
  I like to tell juniors, "if you learned something, you didn't fail".
- ethbr0 4y ago
  Junior developers often can't tell the difference between "I don't have the skill to do this" and "I don't have access/knowledge of internal processes to do this." You can bang your head against the latter forever without making progress, especially if it's un/semi-documented, mostly tribal knowledge. And the best way you're able to guess at it is by prior experience at other companies, which junior developers don't have.
- hgsgm 4y ago
  Did I miss something? I didn't need excuses to manage my classes or social calendar. I wasn't great at either, maybe I should have used excuses to dodge consequences and get better grades and be more popular?
- revskill 4y ago
  [flagged]
deleted 4y ago
[deleted]
sibeliuss 4y ago
At the company I work for we've cultivated a very strong level of trust in terms of asking questions, and encouraging such. However, as the OP noted, it's never that easy. The best formulae I've found is to gently prod jrs towards a solution, but to also keep an eye on their progress and then, if things are taking too long, to reach out and suggest that even though the task isn't complete, to go ahead and open a WIP pr for the team to look at. This encourages them to "let go" of the hangup and to put the work out there, effectively making things a team effort. The sooner they learn that code isn't personal (which is admittedly hard), the sooner they're on their way to more senior levels.
LAC-Tech 4y ago
I wish developers talked and asked each other for help more. Not just juniors but seniors too. This idea that we're all supposed to solve problems in a shared code base completely independently and we're wasting time helping/asking for help is poisonous. Things get solved lot faster when someone comes in with a different perspective. And it keeps communication going. Of course maybe everyone else is a lone genius and I'm the problem. Maybe. But I kind of doubt it.
- hibikir 4y ago
  Agreed, but this is a cultural issue, which has a lot to do with management constraints. I've worked at places where everyone is teaching everyone else at all times, and therefore where everyone grows, year to year. But in those places, there was very little practical competition among developers. They where either all consultants, or they expected their results to have more to do with team performance vs individual performance. On the opposite situation, when programmers are stack ranked, or where it's otherwise clear that they should be playing zero sum games, nobody asks questions, and nobody answers them if they are asked. Tasks that are important enough to lead to chances of advancement are fought over. Everyone wants to build infrastructure for other teams, but using other team's infrastructure is admitting that they are going to get the up level and not you. In any of those world, every programmer is an island, and people get better far slower. Only in the middle, where there are few incentives, one can change a culture from one side to the other. In those cases, it's easier the more senior you are: No better way to get juniors to ask for help when they see seniors asking for help in public. Many a senior engineer is not socially aware enough to try techniques like that though.
- spike021 4y ago
  I mentioned this elsewhere in this thread, but something I've seen first-hand is that people sometimes with less time in the industry will assume someone else more senior "knows everything and shouldn't need help". So you get this imbalance of knowledge and it becomes "why don't you know this already?" instead of "what can we do processes/documentation/team knowledge-wise?" to bridge the gap. I think once you spend enough time in the industry, you learn that even younger/more "inexperienced" people could have better skills or knowledge of certain things (certain types of message queues, certain parts of a network stack, React, etc etc) than someone with more time. It's important to figure out how to balance that. But many people kind of gloss over it or frame it as "well why _don't_ you know this??"
hgsgm 4y ago
If you are worried that you are asking too many questions, you aren't asking enough questions.
annie_muss 4y ago
I'm a junior developer in senior developer's clothing and asking for help is one of the hardest things. That strong feeling of "I should be able to do this by now" often spirals out of control. "I'm stuck" --> "I should ask for help" --> "It's been a week and I've done nothing" --> "This feels so bad I'm just gonna futz around on the internet". It's a hell of a cycle.
- shynrou 4y ago
  Try to shift your perspective, asking for help when needed is a strength. It means you know your limits, that your not infalible. Asking for help is often the most productive thing you can do. It always feels bad not getting anywhere or even worse having to scrap past work, but not checking with others wastests everybodies time. Other people are waiting on your results even if you never meet them. And if nobody is able to help you can either try to plow through or accept defeat.
__MatrixMan__ 4y ago
One thing that makes this much harder is the slippery slope that turns standups into status meetings. I once had to forbid the manager from coming to the standup in order to get my team to start saying "I'm struggling with X" instead of "Look at me, I did Y" where Y is a rephrasing of what they did yesterday.
spike021 4y ago
I'm a mid (technically "senior" title at current job) level engineer with about 7 YOE. I still get stuck sometimes. The major difference from what I remember 5+ years ago is I try to ask early and often (like the vote early, vote often adage) when I need help. Something that I think is missed in this industry, though, is that everyone has different backgrounds. I started this job late last year and sometimes I'll have a lot of questions or get blocked on something I have zero experience in. It can be frustrating because I don't want to over-ask, and know how to timebox myself, but team members, or relevant engineers on other teams, may have less years of experience with more contextual knowledge/experience and occasionally don't want to be bothered to share it. We can get into the nitty-gritty of team culture and all that, but I think it really in this case just boils down to recognizing that someone may not know everything and they could be higher or lower level; it's just important to find the right method to get them up to speed.
zxcvbn4038 4y ago
I have not been a junior developer for a long time, but I occasionally get treated like one. One day after joining a new employer I raised my first or second pull request - and one of the longer term members of the team reviewed it and really let me have it! In every single line he found problems with my style, approach, everything - and he wasn’t really polite about any of it either. So I wrote back that it was actually his change from the previous day with all “dev” changed to “qa”. No response but the change was approved.
- watwut 4y ago
  Oh yeaaaah. This one sounds like extreme tho. But yes, practically, I eventually grew to consider most of the "how to behave on code review" social advice article to be naive and wishful thinking. Fairly often, you gotta show confidence and show boundaries.
- tidenly 4y ago
  I still work on a team the person who mentored me four years ago. He's a great guy, but sometimes in front of other engineers he'll still treat me like I'm a junior - and start explaining some incredibly simple concept to me like an idiot. Sometimes things I obviously knew before even joining, like how HTTP verbs work. It's just a quirk of his without malice I think, but it does get to me depending on who its in front of. I think he just wanted to be seen as the teacher.
  - jen20 4y ago
    Whenever I encounter someone attempting to be condescending while talking about “HTTP Verbs” I pull open the RFC for HTTP and demonstrate that the word “verb” literally does not appear in the document.
    - tjrDL6MjB2Zwwa 4y ago
      so what?
- distantaidenn 4y ago
Cyberdogs7 4y ago
I manage a team of fully remote junior developers, with some seniors mixed in. In my onboarding speech, and throughout their first 90 days, I am constantly emphasizing them to 'Be bold, ask the stupid question' as it highlights gaps in our documentation, onboarding process, or general knowledge graph. Also, I am very up front with all of them that I am here to keep them challenged, but they have a ripcord they can pull at anytime if things get too stressful or if things get too easy. I am very conscious to say 'If things get too stressful' and NOT 'if things get too hard'. A stressed out engineer is no good to anyone.
perrygeo 4y ago
An important skill is being able to distinguish between "stuck due to lack of technical knowledge" and "stuck because of inscrutable bureaucracy". The first, you can research, experiment and rubber-duck your way to a solution solo. The latter, the only way you're going to find out is to talk to someone inside the organization who holds the secret sauce.

119 points by pzrsa 4y ago

I like the advice! I think giving such a specific figure (one hour of spinning your wheels) might seem arbitrary to some people, but I can think of several folks right now (even myself in the past) who would have really benefitted from some kind of loose framework like this, instead of just “feel free to ask a question anytime”

apozem 4y ago

One time, as a junior, I was struggling with an old company API. I tried and tried to figure it out but finally broke down and asked a senior. He explained the problem and unblocked me. The incident always stuck with me because this problem was literally un-Googleable. It was an internal system that required a super specific method of interaction you’d never discover by accident. The only way to use it was to ask for help. So yeah, I agree with the author. Timeboxing tasks for juniors is a good way to teach them when to ask for help or clarify requirements.

debacle 4y ago

I give all my juniors a score from ~2-4, which is a multiplier on the estimate for any task they're assigned. If it would take me N hours to do something, I expect them to take no more N*M hours to finish the task, and if at any point they feel that estimate is wrong they should let me know. Usually it takes them 2-3 tries to realize that this system is in place to help ensure: 1. They understand the scope of the task 2. They don't spin their wheels too long on any one thing. When hiring juniors (mostly interns to direct hire), the two biggest things I look at are: 1. Do you do things outside of your coursework to enrich yourself? 2. Do you ask a ton of questions in the interview? The best intern we ever had (he is at Apple now) asked so many questions during the usually 45 min interview that I think it went to almost 2 hours. He was a phenomenally conscientious hire and managed his own time impeccably well.

jedberg 4y ago

Being a good manager is all about setting context. Timeboxing is actually helpful for senior engineers too, but for a different reason. When I ask for something that I have no idea how long it should take, I'll say something like, "don't spend more than half a day trying to get this to work. If we can do it that amount of time then it's worth it to the business, otherwise it's not worth the effort". If they can't get it done, no problem. I just ask them to document what they tried so that if someone tries it again later they have a starting point. Setting the context let's them know how much effort to put in regardless of junior or senior, it's just for a junior employee the context is less "value to the business" and more "here are my expectations".

cke 4y ago

This one hits home for me. Early on in my career, I had a "mentor" tell me to try it on my own before asking any questions only to swear under his breath when I messed up. It was a massive source of anxiety balancing between asking a question and the risk of messing up. When working with junior engineers nowadays, I go out of my way to let them know that any question at any time is acceptable. I'll put down what I'm doing and help them through a problem and then celebrate the solution with them. I never want them to feel the fear of work and failure that I did.

Raed667 4y ago
Agreed, but with the caveat of not making every single problem you encounter become your team's or your manger's problem. I've seen this especially with some interns, where given the (valid) advice of not being afraid to ask questions, go overboard and make every single task they might have everyone else's task as well.
- actually_a_dog 4y ago
  Sure, that happens. But that's pretty easy to deal with. Just tell them before they start asking for help, they have to at least do some thinking about the problem. The explicit 1 hour time frame in the article is a great guideline.
  - Raed667 4y ago
    There is a difference when you say look for "at-most an hour" and "at-least an hour" before reaching out.
    - actually_a_dog 4y ago
      By Jove, I think you've got it! I'm not saying "do not bother me before precisely 60 minutes have passed," but just "go spend some time with this before you start pulling in other people, but also do not hesitate to pull someone else in if you've made literally no progress in about an hour."

rejectfinite 4y ago

Same in IT in general. Probably a lot of knowledge based jobs.

mkl95 4y ago

I loathed my time as a junior developer. Being a senior dev is like working in a different industry. Leverage beats jerks like rock beats scissors.

tester457 4y ago
> Leverage beats jerks like rock beats scissors. Could you expound on this?
- DangitBobby 4y ago
  If you're senior people can't be assholes to you without risking you walking out.

Waterluvian 4y ago

I had a mentor at my last job who clearly really didn't want to be one. It was to the point that I would sit paralyzed behind him, loathing turning around to get his help. In all fairness, I had yet to learn a good way to get help without interrupting his hard work. I'm not sure he ever fully knew he was my mentor, but without his help I was completely blocked on making any progress on the deep-end project I was thrown into. What we both needed was the company setting very clear, explicit expectations. "X is your mentor. X's main job is to mentor you and help you swim in this deep end." Though I think the entire company was learning a ton of stuff at that phase. Thanks X for all your tolerance over those years. You have no idea how much you saved me, despite my loathing to bother you yet again.

TideAd 4y ago
I have a couple quasi-mentors like this. I'm stuck between feeling grateful for what they taught me (a whole lot) and feeling absolutely sure that I will never be that neglectful to a junior dev in my own career as they were with me.
saghm 4y ago
> What we both needed was the company setting very clear, explicit expectations. "X is your mentor. X's main job is to mentor you and help you swim in this deep end." Though I think the entire company was learning a ton of stuff at that phase. It's been a while since I've mentored someone, but that was always one of the things I made sure to mention in my first conversation with any interns/new grads I'd mentor: "While you're here, mentoring you is the highest priority thing for me to do. If there are ever any times when I have something so time sensitive that it would take priority over answering your questions, I will explicitly let you know. Otherwise, always assume that it's okay to ask me something, because if for some reason I can't answer and you don't know that, it's my fault for not telling you." It helped that the company where I worked at the time had very explicit time periods where someone was considered a "new grad" versus a full team member (since they actually would rotate on 3 teams before ending up on one of them full time), so this strategy might not work as well in places where the expectations for mentors are not laid out as well, but I honestly think that it will almost always be the best strategy to just be open and communicative with anyone you're mentoring. Mentees are just people like anyone else, and them being inexperienced as engineers doesn't make them any less able to understand clearly communicated guidelines, and if you need to adjust the guidelines as you go, there's no reason they can't understand that too.

pydry 4y ago

Onboarding is hard even as a senior. On the one hand interruption is expensive: https://heeris.id.au/trinkets/ProgrammerInterrupted.png https://heeris.id.au/trinkets/ProgrammerInterrupted.png On the other hand, spinning your wheels trying to figure out something for an hour is expensive. I've never really found a solution to maximizing my "interruption budget". Inevitably I end up both spinning my wheels too long sometimes and interrupting too much at other times. Meanwhile trying to solve this problem also consumes way too many brain CPU cycles.

halfmatthalfcat 4y ago

I just had to talk with a couple more junior people on my team about this. We're having difficulty on people wheel spinning and taking too long to reach out when there's problems but it's not because they can't but there's a sense you develop as you gain more experience on what that "red line" is when you need to reach out. It's a combination of experience with the task (language, codebase, etc), agile point values (or just "level of effort") and how easy it is to approach those with the answers. As they're continuing to do work, evaluate where the time you've currently spent matches up to each of those three things. If you've hit that red line, time to start sounding alarm bells (relatively). It really is a learned skill and takes time, juniors shouldn't feel bad and seniors/leads shouldn't make them feel bad. Seniors/leads should also be planning for learning this skill into their estimates to stakeholders.

Scubabear68 4y ago

This is not limited to juniors. I know some fairly senior devs who are afraid to say “I don’t know” or admit they are stuck. Particularly when they are working on someone else’s legacy code that may be of dubious quality. It is a shame, because in many cases just a little humility and admission they are human would make them much stronger developers. As it is, it leads to a level of distrust and uncertainty within the team and with management.

warvariuc 4y ago
I often recommend this video to Juniors in IT: [The Myth of the Genius Programmer](https://www.youtube.com/watch?v=0SARbwvhupQ https://www.youtube.com/watch?v=0SARbwvhupQ)

marmetio 4y ago

Time boxing progress their is good, but it also helps to explain how to ask for help. I tell them if they get stuck to give me a short writeup on the objective, what they tried, why it didn't work, and their questions. It makes them reflect on their work and helps me understand what they need. After a few times, they can usually solve most of their own problems.

Justsignedup 4y ago

I solved this problem, quite well, and still do this all the damn time: 1) try to solve the problem 2) Gee, it's hard. shit. okay think think think 3) okay ask for help. wait... let's write a slack message. First write the problem, explain exactly what you tried, and ideas for next attempts. Explain your confusions. 4) OMG I SOLVED IT or 4a) Hit send. I find that 70% of the time, I don't hit send. 30% of the time it was worth asking.

tomkarho 4y ago
Before slack, Stackoverflow was my rubber ducky.
bob1029 4y ago
I have an additional trick - If you are the person of whom help is frequently asked, employ a nominal delay before you get into it. "Sure - let's get on <conference line> in 5 minutes" I've found this to work well. "hang on I'm going to try 1 more thing". And, then you don't hear from them until tomorrow.
- bluefirebrand 4y ago
  I use this trick a lot. I tend to vary between 10-20 minutes though. I also usually give them a starting point. "Hey I'm in the middle of something. I can chat in 15 minutes or so. In the meantime if you haven't yet, try X, Y, Z" This helps push them to at least try something so when I ask later "Did you try X Y or Z?" They can have some kind of answer.
- groffee 4y ago
  I found this in a non-development role, this lady would constantly phone me for 'help' and I found that if I just ignored her (in a nice way) she'd fix it herself in a few minutes.
- Justsignedup 4y ago
  brilliant idea. i will use this
4y ago

kiachnish 4y ago

As a fresh grad SWE I have felt this insecurity as well. "Seven Tips for a Junior Developer" [0] has some good parts on asking for help, and on the pendulum between unblocking yourself versus reaching out to others. I would love to read anything else on the topic. [0] https://www.pearlleff.com/seven-tips-for-a-junior-developer https://www.pearlleff.com/seven-tips-for-a-junior-developer

pm90 4y ago

Setting explicit time frames is really useful for both the mentor and mentee (or manager and employee etc). If someone is unable to complete a task within a set time, but explains their thought process and what they tried, I consider that to be a completely valid use of their time. Even if they are completely honest and say: "This seemed too hard and I tried for the first 15 minutes and then got bored and procrastinated" that is also ok. We're all humans after all. Its when someone spends their time on excuses and fobs that is really annoying and unproductive. Generally: most people will invent excuses. People that went to college (I went to college!) get really good at this since you need to invent excuses all the time to get past annoying social activities and classes. In most cases, providing the space to fail and proceed allows developers to gain the confidence to be upfront. Of course there will always be those that don't get the message, or try to game the system. But they tend to fall really really far behind and it becomes pretty obvious that they're not doing well.

inopinatus 4y ago
I like to tell juniors, "if you learned something, you didn't fail".
ethbr0 4y ago
Junior developers often can't tell the difference between "I don't have the skill to do this" and "I don't have access/knowledge of internal processes to do this." You can bang your head against the latter forever without making progress, especially if it's un/semi-documented, mostly tribal knowledge. And the best way you're able to guess at it is by prior experience at other companies, which junior developers don't have.
hgsgm 4y ago
Did I miss something? I didn't need excuses to manage my classes or social calendar. I wasn't great at either, maybe I should have used excuses to dodge consequences and get better grades and be more popular?
revskill 4y ago
[flagged]

deleted 4y ago

[deleted]

sibeliuss 4y ago

At the company I work for we've cultivated a very strong level of trust in terms of asking questions, and encouraging such. However, as the OP noted, it's never that easy. The best formulae I've found is to gently prod jrs towards a solution, but to also keep an eye on their progress and then, if things are taking too long, to reach out and suggest that even though the task isn't complete, to go ahead and open a WIP pr for the team to look at. This encourages them to "let go" of the hangup and to put the work out there, effectively making things a team effort. The sooner they learn that code isn't personal (which is admittedly hard), the sooner they're on their way to more senior levels.

LAC-Tech 4y ago

I wish developers talked and asked each other for help more. Not just juniors but seniors too. This idea that we're all supposed to solve problems in a shared code base completely independently and we're wasting time helping/asking for help is poisonous. Things get solved lot faster when someone comes in with a different perspective. And it keeps communication going. Of course maybe everyone else is a lone genius and I'm the problem. Maybe. But I kind of doubt it.

hibikir 4y ago
Agreed, but this is a cultural issue, which has a lot to do with management constraints. I've worked at places where everyone is teaching everyone else at all times, and therefore where everyone grows, year to year. But in those places, there was very little practical competition among developers. They where either all consultants, or they expected their results to have more to do with team performance vs individual performance. On the opposite situation, when programmers are stack ranked, or where it's otherwise clear that they should be playing zero sum games, nobody asks questions, and nobody answers them if they are asked. Tasks that are important enough to lead to chances of advancement are fought over. Everyone wants to build infrastructure for other teams, but using other team's infrastructure is admitting that they are going to get the up level and not you. In any of those world, every programmer is an island, and people get better far slower. Only in the middle, where there are few incentives, one can change a culture from one side to the other. In those cases, it's easier the more senior you are: No better way to get juniors to ask for help when they see seniors asking for help in public. Many a senior engineer is not socially aware enough to try techniques like that though.
spike021 4y ago
I mentioned this elsewhere in this thread, but something I've seen first-hand is that people sometimes with less time in the industry will assume someone else more senior "knows everything and shouldn't need help". So you get this imbalance of knowledge and it becomes "why don't you know this already?" instead of "what can we do processes/documentation/team knowledge-wise?" to bridge the gap. I think once you spend enough time in the industry, you learn that even younger/more "inexperienced" people could have better skills or knowledge of certain things (certain types of message queues, certain parts of a network stack, React, etc etc) than someone with more time. It's important to figure out how to balance that. But many people kind of gloss over it or frame it as "well why _don't_ you know this??"

hgsgm 4y ago

If you are worried that you are asking too many questions, you aren't asking enough questions.

annie_muss 4y ago

I'm a junior developer in senior developer's clothing and asking for help is one of the hardest things. That strong feeling of "I should be able to do this by now" often spirals out of control. "I'm stuck" --> "I should ask for help" --> "It's been a week and I've done nothing" --> "This feels so bad I'm just gonna futz around on the internet". It's a hell of a cycle.

shynrou 4y ago
Try to shift your perspective, asking for help when needed is a strength. It means you know your limits, that your not infalible. Asking for help is often the most productive thing you can do. It always feels bad not getting anywhere or even worse having to scrap past work, but not checking with others wastests everybodies time. Other people are waiting on your results even if you never meet them. And if nobody is able to help you can either try to plow through or accept defeat.

__MatrixMan__ 4y ago

One thing that makes this much harder is the slippery slope that turns standups into status meetings. I once had to forbid the manager from coming to the standup in order to get my team to start saying "I'm struggling with X" instead of "Look at me, I did Y" where Y is a rephrasing of what they did yesterday.

spike021 4y ago

I'm a mid (technically "senior" title at current job) level engineer with about 7 YOE. I still get stuck sometimes. The major difference from what I remember 5+ years ago is I try to ask early and often (like the vote early, vote often adage) when I need help. Something that I think is missed in this industry, though, is that everyone has different backgrounds. I started this job late last year and sometimes I'll have a lot of questions or get blocked on something I have zero experience in. It can be frustrating because I don't want to over-ask, and know how to timebox myself, but team members, or relevant engineers on other teams, may have less years of experience with more contextual knowledge/experience and occasionally don't want to be bothered to share it. We can get into the nitty-gritty of team culture and all that, but I think it really in this case just boils down to recognizing that someone may not know everything and they could be higher or lower level; it's just important to find the right method to get them up to speed.

zxcvbn4038 4y ago

I have not been a junior developer for a long time, but I occasionally get treated like one. One day after joining a new employer I raised my first or second pull request - and one of the longer term members of the team reviewed it and really let me have it! In every single line he found problems with my style, approach, everything - and he wasn’t really polite about any of it either. So I wrote back that it was actually his change from the previous day with all “dev” changed to “qa”. No response but the change was approved.

watwut 4y ago
Oh yeaaaah. This one sounds like extreme tho. But yes, practically, I eventually grew to consider most of the "how to behave on code review" social advice article to be naive and wishful thinking. Fairly often, you gotta show confidence and show boundaries.
tidenly 4y ago
I still work on a team the person who mentored me four years ago. He's a great guy, but sometimes in front of other engineers he'll still treat me like I'm a junior - and start explaining some incredibly simple concept to me like an idiot. Sometimes things I obviously knew before even joining, like how HTTP verbs work. It's just a quirk of his without malice I think, but it does get to me depending on who its in front of. I think he just wanted to be seen as the teacher.
- jen20 4y ago
  Whenever I encounter someone attempting to be condescending while talking about “HTTP Verbs” I pull open the RFC for HTTP and demonstrate that the word “verb” literally does not appear in the document.
  - tjrDL6MjB2Zwwa 4y ago
    so what?
distantaidenn 4y ago

Cyberdogs7 4y ago

I manage a team of fully remote junior developers, with some seniors mixed in. In my onboarding speech, and throughout their first 90 days, I am constantly emphasizing them to 'Be bold, ask the stupid question' as it highlights gaps in our documentation, onboarding process, or general knowledge graph. Also, I am very up front with all of them that I am here to keep them challenged, but they have a ripcord they can pull at anytime if things get too stressful or if things get too easy. I am very conscious to say 'If things get too stressful' and NOT 'if things get too hard'. A stressed out engineer is no good to anyone.

perrygeo 4y ago

An important skill is being able to distinguish between "stuck due to lack of technical knowledge" and "stuck because of inscrutable bureaucracy". The first, you can research, experiment and rubber-duck your way to a solution solo. The latter, the only way you're going to find out is to talk to someone inside the organization who holds the secret sauce.