[HN Gopher] The hardest part of being a junior developer
___________________________________________________________________
The hardest part of being a junior developer
Author : pzrsa
Score : 48 points
Date : 2023-01-16 21:03 UTC (1 hours ago)
(HTM) web link (rachsmith.com)
(TXT) w3m dump (rachsmith.com)
| apozem wrote:
| 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 wrote:
| 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.
| madeofpalk wrote:
| Hell, as a reasonably mature-ish senior-ish developer I struggle
| with this! Whenever I run into a road block or struggle to figure
| something out, I get that wave of imposter syndrome-ish where I
| think "No, you're a senior dev, you can't be asking for help!"
| Scubabear68 wrote:
| 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.
| sibeliuss wrote:
| 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.
| marmetio wrote:
| 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 wrote:
| 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 wrote:
| Before slack, Stackoverflow was my rubber ducky.
| bob1029 wrote:
| 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.
| jedberg wrote:
| 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 wrote:
| 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 wrote:
| 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.
| c7DJTLrn wrote:
| >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
|
| May I ask how long ago this was? Although shit colleagues and
| shit workplaces still exist, it feels like these days it would
| be shut down pretty quick by HR in the average company.
| TexanFeller wrote:
| I have seen HR get involved in situations like this zero time
| in my career. I wouldn't want them to either.
| sshine wrote:
| I had a hard case of impostor syndrome at my first full-time
| job and spent an unnecessary amount of time being stuck because
| I was too scared to ask.
|
| I make sure that anyone in my office who is new or is my junior
| knows that I'm the person they can always interrupt. People
| never interrupt too much.
| drunkpotato wrote:
| I have junior engineers try solving their problem on their own
| for an hour. If they make no progress, ask for help. If they
| make some progress, repeat. I think it's a good learning
| experience while also providing a safety net, and I've gotten
| positive feedback from juniors on this advice.
| rejectfinite wrote:
| Same in IT in general. Probably a lot of knowledge based jobs.
| mkl95 wrote:
| 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.
| kiachnish wrote:
| 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
| Waterluvian wrote:
| 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.
| saghm wrote:
| > 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.
| TideAd wrote:
| 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.
| pydry wrote:
| Onboarding is hard even as a senior.
|
| On the one hand interruption is expensive:
| 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.
| pickledish wrote:
| 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"
| halfmatthalfcat wrote:
| 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.
| pm90 wrote:
| 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.
___________________________________________________________________
(page generated 2023-01-16 23:00 UTC)