10 Things You Should Never Say to Junior Developers

"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!

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.

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) {
    Logger.info(`Item ${id} is named ${name}`);
}

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.

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.

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 :)

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.

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

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?")

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.

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.