The hardest part of being a junior developer
rachsmith.comSetting 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.
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.
I like to tell juniors, "if you learned something, you didn't fail".
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?
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.
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.
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.
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.
brilliant idea. i will use this
When I was young in the pre-Slack era when you actually had to find a colleague physically to explain the problem to, this was called "cardboard engineer syndrome"; i.e., talking to a cardboard cutout of a colleague would have been just as effective.
I know this as rubber ducking. Explain your problem to a "rubber duck" on your desk. It doesn't have to be a real rubber duck.
But it's funnier if it is.
You can also use an infant. Now that my youngest is two years old this doesn't work any more.
On step 3, explaining exactly what you tried and ideas for next attempts is crucial! I've never heard of an engineer that took the time to communicate those points and still get rebuffed for help.
I work alone, but I can’t count the number of github issues I typed but never opened because of this.
Before slack, Stackoverflow was my rubber ducky.
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.
It's their ego. I'm now at the CTO level, but I still code as a hobby (daily) and will contribute as necessary to a product with coding. A couple years ago, during a stretch with a previous client, I wrote a bit of code. With my second PR, one of the code reviewers tore my code to shreds. It was 90% styling and 10% theory. As for the styling, sure, it was fair enough. I was new to their culture and it was trivial changes -- 5 minutes of work.
The last 10% was simply a theory issue. The reviewer wanted things his way, which would have taken an inordinate amount of time for the feature. I told him that it was unnecessary, and would increase dev time. I was thinking about the entire product process, while he was focusing on how the code should look -- which was purely arbitrary.
He wouldn't waver, and delayed my PR. It eventually was escalated to the head of engineering, who sided with me. It was a trivial feature, and my code was tested and worked -- it just wasn't the reviewer's way of doing things.
Anyway, it got merged as is. But, I can only wonder about how a junior dev may have handled it. Wasting hours of time to conform to a particular senior engineer's arbitrary "way" of doing things -- correctness be damned. As for my own code reviews, I follow a simple process: 1. Can I parse it in 10 seconds? 2. Does it fit the specs? 3. Is it tested? 4. Is it extensible?
You describe something that I experience in almost any organisation. I am not a CS grad, I've seen many projects in different technologies through the years and also have more business-oriented mindset as for software engineer. The amount of arbitrary requirements in code, especially in languages with no clear code styles (like Python) and specifically with people who don't expose themselves to different technologies (work in the same company for years or so) is a major productivity and motivation killer.
What are the useful techniques to deal with such people? Many times, it is just easier to comply to their vague requirements rather than engage in prolonged discussions, as they usually don't have the ability or will to look at things from the other side. I consider escalation to a higher management the last resort.
Does anyone produced some successful strategies to deal with that?
If they were actually competent the styling changes would have been caught/fixed with automation. If they can’t set up linting and formatting as part of their CI…well I don’t think they have any right to call themselves senior.
Yeah, I tend to take the position that the only appropriate way to request code style adjustments is via automation.
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.
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.
so what?
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.
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.
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.
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.
There is a difference when you say look for "at-most an hour" and "at-least an hour" before reaching out.
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."
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.
> 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.
I go even further than that. I tell juniors there's literally no way you can screw anything up so badly that we can't deal with it. If they write code that doesn't do what it's supposed to do, and it's not caught in code review, the reviewers are more to blame than they are, because they're supposed to know better. A junior shouldn't have the access level necessary to do something like drop the production database -- that's on their more experienced colleagues to set up those guard rails.
Maybe this is a cultural thing, but did you ask what you were doing wrong when they swore?
For me, if somebody swore about something I was doing, I’d likely laugh and challenge them to either ask how I’d fucked up or how they’d recommend doing it.
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.
>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.
I have seen HR get involved in situations like this zero time in my career. I wouldn't want them to either.
That depends IMO. Is the "mentor" really the "manager?" If someone with power over your performance evaluations and future at the company is swearing under their breath every time you do something wrong, that's a problem that HR maybe should be involved in.
HR is not there to solve your problems. HR is there to protect the company.
It's fine to be friendly with HR (some wonderful people work there), but remember who is paying them and whose interests they are supposed to look out for first. Definitely not yours.
HR wants all the info they can get from you. They will cheerfully listen to everything you tell them. And then they will do their job, which is to analyze the situation for potential risks around legal exposure, and take steps to mitigate those risks.
I would basically never bring HR in to a problem unless you are very confident that solving your problem and the goal of protecting the company are truly in alignment. Maybe retraining the manager is better for the company, but who knows. They can also solve their problem by removing the new employee who is being treated badly.
A hostile work environment is the company's problem.
Someone who needs to be on a performance plan expects HR to force coworkers to be more patient? Sounds about right
What are you on about with "performance plans" and such?
Call me skeptical. In 20 years, I've only seen HR only get involved for hiring and firing. You'll be lucky to hear from them for anything else, maybe for benefits renewal or a DEI seminar.
HR is not your friend, unless you work in management or above.
HR is not intervening in lows stakes ordinary day to day conflicts, power struggles or personality clashes such as this one. Nor are they able to.
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.
It's also just silly to get stuck on little things for too long because of ego. I've done it, and honestly it still happens sometimes, but it's so freeing to not have to feel that pressure.
In one of my previous jobs I had a great relationship with one developer in particular. We've both seen great work from each other so knew we weren't just coasting but it took one of us to just say, hey dude any idea why this isn't building? I took one look and it was something obvious - easy fix and he could move on. That didn't make me feel like a genius, it just made me happy to know there was such trust. He knew I wouldn't judge him and since then the back and forth was super simple. Greatly improved both our work, since now it's also way simpler to ask eachother for input on other things.
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.
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??"
Solving things faster is not always the goal. I make a point to fully "rubber-duck" the problem before asking for help. Is this slower, yes. Does this build deep knowledge in a way that is superior to just being handed the answer, absolutely. Knowledge comes from direct experience - if you always rely on someone else's direct experience to get the job done, you might move faster in the short term but are missing out on a vital part of learning.
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.
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.
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.
> 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.
> "X is your mentor. X's main job is to mentor you and help you swim in this deep end."
I don't think that will ever happen, nor should it. No ones main job should be to mentor someone else. The best teams all help each other. Early and often.
A good work environment will see only good from developers asking each other questions to gain a better understanding of the complex systems being worked on. I was pretty senior in one of my last few roles, and I regularly asked questions of the folks that had been building the system before me. And I always made time to support other devs (and QA and support folks) that came to ask me questions, be it about code I wrote, general questions about technical things or whatever. Being supportive to each other is what made it a really fun place to work at.
I think your opinion is strongly founded on a bunch of personal assumptions given how little information was provided. Be careful not to miss the point by fixating on details.
I’ve seen a lot of bad engineers and most of them undervalue helping others. Good engineering leads know that they can write more code by supporting everyone than by writing code themselves. Definitely a form of mentorship. I’ve seen some that are almost 100% mentors.
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.
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".
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.
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.
> Leverage beats jerks like rock beats scissors.
Could you expound on this?
If you're senior people can't be assholes to you without risking you walking out.
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.
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.
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.
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'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.
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.
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
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.
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.
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.
I often recommend this video to Juniors in IT: [The Myth of the Genius Programmer](https://www.youtube.com/watch?v=0SARbwvhupQ)
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.
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.
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't asking enough questions.