DEV Community

Cover image for 10 Things You Should Never Say to Junior Developers
Tori "Code Mom" Brenneison
Tori "Code Mom" Brenneison

Posted on

10 Things You Should Never Say to Junior Developers

Hey, experienced developers–this one’s for you! 

When coaching juniors, it’s important for senior developers to be mindful of what they say.  Your choice of words may affect a mentee in ways you don’t anticipate, even if your intentions are good.  The ultimate goal of mentoring junior developers is to build confidence, foster learning, and encourage professional growth; one of the ways we can help our mentees become successful developers is by using supportive and constructive language–i.e., not the phrases in this article!

If you have said one of these phrases to a junior in the past–well, we all make mistakes, and sometimes we don’t even realize we've done it.  The important thing is to be better next time, and try to remove these phrases from your vocabulary. 

“This is easy/simple,” or, “It’s not that hard.” 

It is really tempting to say this–because, with years of experience, a certain task may be really easy!  (I know I have accidentally said this more often than I should have.)  Remember, even though something may seem simple to accomplish to you, that doesn’t mean that someone who is new to programming won’t find it difficult.  It’s important to acknowledge that certain tasks may be a challenge for new programmers! 

“You should already know this,” “You should figure it out on your own,” and “Why don’t you understand this yet?” 

These phrases can set expectations way too high and create an atmosphere of pressure that can undermine a junior developer’s confidence, lead to imposter syndrome, and discourage them from asking for help.  Juniors are learning on the job, and they might not be familiar with certain concepts–it’s far more helpful to explain things and share resources to help them learn than it is to criticize. 

“How could you make this mistake?”, “That's not how I would have done it,” or, “Maybe you’re just not cut out for (insert task here).”

Criticisms like these can have lasting effects on a junior’s self-esteem.  Instead, focus on giving constructive feedback and offer suggestions for improvement. Being overly critical or expressing a preferred personal approach can discourage juniors and make them hesitant to share ideas or solutions.

“You’re taking too long", “It's faster if I do it,” or “I don’t have time to explain this to you.”

Okay, Big Bad Senior Developer–we get it, you’re busy.  However, while it can be tempting to take over a task that a less experienced developer is struggling with, they won’t learn if you take opportunities away.  Instead, offer to guide juniors through complex tasks by helping them break down those tasks into smaller steps and offering your assistance in completing them.  Also, dismissing a junior’s request for help can discourage them from asking again in the future–which can lead to poor performance due to stress and fear.

“Just do it this way,” or, “That’s not how we do things around here.”

While maintaining standard procedures and best practices is important, don’t dismiss ideas from juniors out-of-hand, as they can bring new ideas and fresh perspectives to work.  Encourage critical thinking and creativity in the workplace by having discussions about the whys and hows of processes, and explain the rationale behind preferred practices.

“You’re too new for this,” “You’re just a junior developer,” or, “You won’t understand until you have more experience.”

Comparing juniors to seniors, often unfavorably, can not only undermine juniors’ confidence, but lead to an unhealthily competitive work environment as they desperately try to “prove themselves”.  Instead, try to focus on individual growth by helping juniors set professional goals and coaching them toward reaching those goals, celebrating all the progress they make along the way.

“You’re lucky to even be here.”

This one’s a doozy–implying that a junior should be grateful for their job can easily come off as diminishing their accomplishments and contributions, and make them feel as though they don’t belong.  

“That’s a dumb question.”

Discouraging questions or labeling them as stupid is an obvious no-no, but it still happens.  Doing this can make juniors hesitant to ask for help.  Instead, try to focus on collaboration and create a safe environment where juniors can ask whatever questions they have and receive quality answers and feedback.  Emphasize that learning is a continuous process, and encourage professional development for both your junior and senior teammates.  

“Real programmers don’t use ,” or, “That’s not how it’s done in 'the real world'.”

Developers have preferences, and we hold to our preferences so strongly that sometimes we start believing that our preferred way is, in fact, the one true way of doing things.  I know that I can be guilty of this one, too!  (Cough, cough… "Just use git through a bash shell, like nature intended.")  However… disparaging a junior’s tooling or technology choices can contribute to imposter syndrome and destroy their willingness to explore new things. 

You need patience and empathy to coach junior developers, as well as a genuine desire to help them learn and grow professionally.  Coaching is an opportunity for senior developers to guide newbies toward success–and most of us still remember that one senior who mentored us in the beginning, don’t we?  We owe it to juniors to try and create a positive and supportive work environment that sets them up for long-term career success.

This article was originally published at!

Top comments (31)

lucaschitolina profile image
Lucas Chitolina

"You’re taking too long" used to destroy my self-confidence and caused me to produce bugs that wouldn't have been done if I had taken it easy.

Another thing, talking about deadlines, is when you don't specify the time for the junior and only when you realize it's taking too much time do you go there and say "this could have been done in less time". That is terrible to say to a junior.

Nice article!

j3lte profile image
Jelte Lagendijk

Great post. I disagree on one of them though, it can be said, but in the right context: "You should figure it out on your own."

I would say to a junior dev "I want you to figure it out on your own. If you think you've found the right solution, let me know and we look at it together"

I got this lesson from one of my first jobs, a great mentor. He encouraged me to research it on my own and come up with a solution. That part of researching makes you learn a ton more new things. He would encourage me to check things for myself, come up with creative solutions and then talk about what is 'right' and 'wrong' about it.

I still do the same with junior devs I encounter, encouraging them to do it themselves and find a solution that fits. Then I go over it with them, pointing out potential flaws, but also prease them if they come up with something I hadn't thought about myself. The plus side here is that you also get to learn new things yourself.

pinotattari profile image
Riccardo Bernardini

I guess it depends a lot on the context and on how you say that.

I teach DSP and I am a strong believer in having the students figuring out things by themselves. I usually say "You have the competences, do it by yourself, I believe it is more useful than seeing me doing that. Of course, if you are stuck and need help, you know where my office is."

However, "figure it out by yourself" can also be said with the spirit of "This is trivial stuff, do not waste my time with that, figure it by yourself. If you cannot you are worthless."

It is difficult to communicate this nuance with written text, but with a verbal exchange IRL the difference is quite clear.

teamradhq profile image

Some of these are dependent on context. If you read all of these with a gruff tone of voice and assume that the person speaking simply uttered the phrase before turning back to their work and putting their headphones on, then sure... you've got a point.

In my experience, many of these phrases or the ideas that they convey are essential to the career development of juniors.

This is easy/simple

I use this phrase all the time with less experienced developers. This job is stressful enough, without being made to feel that simple things are hard, so when I see a developer's confidence suffering because they're struggling with a problem, this phrase is a good way to counter their lack of self-confidence.

Validating the idea that a simple problem is hard encourages negative thought processes that won't encourage collaboration. Instead, explaining why problem is easy to solve and then walking them through the solution, seeing their realisation (that the solution is in fact easy once its understood) will lead to more productive knowledge exchange.

Reassuring them that it's frequently the case that problems we struggle to resolve appear stupidly simple after we've resolved them (missing semi-colon, amiright?) is a good way to encourage healthy patterns of thought over the negative ones that were causing their stress.

And when somebody feels things are easier, they're encouraged to seek explanations of relevant concepts and develop a deeper understanding of the topic.

You should figure it out on your own,

I don't see how this is a negative phrase. Upon helping someone to understand a problem, I frequently encourage them to seek out additional resources to deepen their understanding. This is probably one of the most common pieces of advice I give to developers because the ability to learn independently is one of their most prized attributes.

That's not how I would have done it

What is wrong with explaining alternative solutions? It's frequently the case when reviewing Junior developer's code that I will explain the ways they should improve their code before being accepted. A good example is explaining patterns that they should apply to their work, or existing tools that could be applicable in their case, such as using a Logger class instead of console or using array methods where we prefer loops.

Here I'd explain the reasons for these preference and how I would recompose a piece of their code:

// Before
items.forEach(items => {
    const [id, name] = item;
    console.log(`Item ${id} is named ${name}`);

// After
for (const [id, name] of items) {`Item ${id} is named ${name}`);
Enter fullscreen mode Exit fullscreen mode

Now they can go off and make the required changes to the rest of their code. How would you achieve this without saying you would have done it differently?

Just do it this way / That’s not how we do things around here.

Again, why not? No idea is original and if somebody had already thought of their ideas, and they didn't work, then it's a good thing to explain the way things are done and the reason for it. If your goal is to encourage critical thinking anr rationale, isn't it good for a junior to experience the reality that their assumptions may often be incorrect?

I know you suggest taking time for explanation. But maybe someone is traumatised from the experience the last time someone suggested it because of how badly things went. Perhaps that person is sensitive to an area that they consider to be their problem domain. Maybe they're just tired of so many graduates telling them how they should do things when they have no experience.

You’re lucky to even be here.

I would say this to every single developer whose employed with a developer salary. It's a very privileged position to have, and many people would love to have it. It's important for developers to understand the value of their position, the opportunities it provides, and the responsibility that it entails.

That’s not how it’s done in 'the real world'.

I assume by "real world" you mean in a commercial environment. If you come into the real world armed with a head full of tutorials, it's a common experience to realise that this information represents ideal conditions that you'll rarely, if ever, encounter in the real world. And on the topic of tooling, it's great to have shiny and new things, but if they don't provide some kind of benefit vs the cost of implementation or maintenance, then they're not worth using.

You need patience and empathy to coach junior developers, as well as a genuine desire to help them learn and grow professionally.

So true, as is the inverse. I would struggle to work with a developer who was unable to have their assumptions or ideas challenged and I think

  • Know that for the rest of your career, you'll encounter hard concepts that will look easy once you understand them.
  • It's important to be able to develop your skills and knowledge independently.
  • Be receptive to more experienced developers' ideas and explanations.
  • Respect the way your team works if you want to make a valuable contribution.
  • We're lucky to be here, and we should be grateful for the opportunities we have.
  • Your academic knowledge is not representative of commercial realities.
rockykev profile image
Rocky Kev

Absolutely agree with your key points. Especially this one:

That’s not how we do things around here.

This is a statement that HAS to be said.

For example, mild sexist jokes or 'edgy-humor'. I don't care how your previous job did it, but not here.

In the technical space, it's not to discourage. Devs can have autonomy, but it doesn't mean they can do whatever they want. There's a LOT of excellent rules of thumbs that can't be implemented at a company without other major trade-offs. So you have to use this statement, to show them the hack/the why.

nh profile image
Neil Hoskins

Assuming that because you're senior, you can do everything better than someone who is junior is pure arrogance. I've been developing software for 30 years and I've had apprentices teach me things and certainly make me think long and hard about code I've written. New blood brings new ideas and new perspectives, I am always open to new ways and what most people dread, change.

I always try and put my juniors in front of clients too, show them how the software they've written is being used (if it's favourable!). There's nothing quite like getting praise from someone who's invested in the software you're creating. I simply don't hire developers who I couldn't do this with.

leob profile image
leob • Edited

If you say any of these things then you're unfit to be called a senior, and unsuitable to mentor juniors - it betrays arrogance and a poor mindset :)

brianwaustin profile image
Brian Austin

Forget junior developers, that's some downright toxic feedback. Don't assume you know more or have everything figured out because you've been coding longer.

People that say stuff like this are a PITA to work with, at any experience level.

thedenisnikulin profile image

I've heard many of these... it hurts

meeroslava profile image

I was a witness to "you should know this by now". This is such useless comment. It doesn't help the person that clearly doesn't know "this", it delays the process and hurts in-team cooperation. If you want to damage your teams/company progress - use this phrase. If you don't want to answer the same question again and again, help your teammate to understand the topic and ask them to write it down for the future reference. And if the question comes up again - ask them to explain and see where the gap in knowledge/understanding is.

mark_nicol profile image
Mark Nicol

Lovely article. Reminded me of a couple of bits of advice I was given about explaining things.

Avoid the words 'simply' and 'just' they don't add anything, may cover up laziness in your own thinking or explaining and make people feel bad.

Ask questions don't tell when people have done something differently from the 'usual' way. You might both learn something.

_ndeyefatoudiop profile image
Ndeye Fatou Diop

I totally agree with all of these. Sometimes, people don't even say this, but you can feel it in how they react, which is worse. That's why I always strive to create a safe environment because I know how it feels to not be in a safe one (I also did my best work whenever I felt safe since I was free of worries :))

peteraba profile image
Peter Aba • Edited

Meh. First off, some of these are fine in certain situations, others you should never use with anyone, yet some others make the person saying them sound so stupid, they probably shouldn't even be doing software engineering in the first place. (For example: "Why don’t you understand this yet?")

andreasjakof profile image
Andreas Jakof
That's not how I would have done it
Enter fullscreen mode Exit fullscreen mode

There is One way to say this correctly:

That's not how I would have done it, it‘s an interessant approach. Please explain to me, why you did it that way.

estelle-k profile image

Very nice article!

It is perhaps necessary to remember that a junior is actually a human. We must respect him as he must respect us.

It is the basis of any relationship. “Hierarchical superiority” does not claim that the senior knows everything. He should simply pass on his knowledge.

This is something that doesn't suit everyone.

caleb82 profile image
KWIZERA Caleb • Edited

I agree with the post , this actually should change because those words can make people lose confidence. Also post how one can learn Software development as fast like in three months . That I mean Front-end and Back-end

aadarsh-nagrath profile image
Aadarsh Nagrath

This is so good post hm...............