The hardest part of being a junior developer

Setting explicit time frames is really useful for both the mentor and mentee (or manager and employee etc).<p>If someone is unable to complete a task within a set time, but <i>explains their thought process and what they tried</i>, I consider that to be a completely valid use of their time. Even if they are completely honest and say: &quot;This seemed too hard and I tried for the first 15 minutes and then got bored and procrastinated&quot; that is also ok. We&#x27;re all humans after all.<p>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.<p>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&#x27;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&#x27;re not doing well.

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

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.

This one hits home for me.<p>Early on in my career, I had a &quot;mentor&quot; 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.<p>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&#x27;ll put down what I&#x27;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.

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

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

I had a mentor at my last job who clearly really didn&#x27;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&#x27;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.<p>What we both needed was the company setting very clear, explicit expectations. &quot;X is your mentor. X&#x27;s main job is to mentor you and help you swim in this deep end.&quot; Though I think the entire company was learning a ton of stuff at that phase.<p>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.

Being a good manager is all about setting context. Timeboxing is actually helpful for senior engineers too, but for a different reason.<p>When I ask for something that I have no idea how long it should take, I&#x27;ll say something like, &quot;don&#x27;t spend more than half a day trying to get this to work. If we can do it that amount of time then it&#x27;s worth it to the business, otherwise it&#x27;s not worth the effort&quot;.<p>If they can&#x27;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.<p>Setting the context let&#x27;s them know how much effort to put in regardless of junior or senior, it&#x27;s just for a junior employee the context is less &quot;value to the business&quot; and more &quot;here are my expectations&quot;.

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

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.

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.<p>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 <i>only</i> way to use it was to ask for help.<p>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.

I&#x27;m a mid (technically &quot;senior&quot; title at current job) level engineer with about 7 YOE. I still get stuck sometimes.<p>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.<p>Something that I think is missed in this industry, though, is that everyone has different backgrounds.<p>I started this job late last year and sometimes I&#x27;ll have a lot of questions or get blocked on something I have zero experience in. It can be frustrating because I don&#x27;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&#x2F;experience and occasionally don&#x27;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&#x27;s just important to find the right method to get them up to speed.

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

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”

I give all my juniors a score from ~2-4, which is a multiplier on the estimate for any task they&#x27;re assigned.<p>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.<p>Usually it takes them 2-3 tries to realize that this system is in place to help ensure:<p>1. They understand the scope of the task<p>2. They don&#x27;t spin their wheels too long on any one thing.<p>When hiring juniors (mostly interns to direct hire), the two biggest things I look at are:<p>1. Do you do things outside of your coursework to enrich yourself?<p>2. Do you ask a ton of questions in the interview?<p>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.

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 &#x27;Be bold, ask the stupid question&#x27; as it highlights gaps in our documentation, onboarding process, or general knowledge graph.<p>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.<p>I am very conscious to say &#x27;If things get too stressful&#x27; and NOT &#x27;if things get too hard&#x27;. A stressed out engineer is no good to anyone.

As a fresh grad SWE I have felt this insecurity as well. &quot;Seven Tips for a Junior Developer&quot; [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.<p>[0] <a href="https:&#x2F;&#x2F;www.pearlleff.com&#x2F;seven-tips-for-a-junior-developer" rel="nofollow">https:&#x2F;&#x2F;www.pearlleff.com&#x2F;seven-tips-for-a-junior-developer</a>

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

At the company I work for we&#x27;ve cultivated a very strong level of trust in terms of asking questions, and encouraging such. However, as the OP noted, it&#x27;s never that easy.<p>The best formulae I&#x27;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&#x27;t complete, to go ahead and open a WIP pr for the team to look at. This encourages them to &quot;let go&quot; of the hangup and to put the work out there, effectively making things a team effort. The sooner they learn that code isn&#x27;t personal (which is admittedly hard), the sooner they&#x27;re on their way to more senior levels.

This is not limited to juniors.<p><pre><code> 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. </code></pre> As it is, it leads to a level of distrust and uncertainty within the team and with management.

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

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&#x27;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.

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

If you are worried that you are asking too many questions, you aren&#x27;t asking enough questions.