DEV Community


5 ways to create a junior developer-friendly culture 🚀

Updated on ・5 min read

Let’s face it - being a junior developer is anything but easy. Imposter syndrome kicks in multiple times a day, asking questions can be absolutely terrifying, and the more you learn, the more you realize how little you actually know. As junior developers, we are often extremely hard on ourselves. We often question our own capabilities, force ourselves to come up with the solution to a problem on our own, and continuously feel the need to prove ourselves.

One of the ways we can make it a little easier, though, is to place ourselves in the right environment and to surround ourselves with the right people. Below, I have compiled 5 things to look for if you are aiming to join a supportive engineering culture that will contribute to your learning and growth.

These 5 pointers are not only relevant for junior developers who are perhaps looking for their first (or next) employer, but also, for example, for senior developers who get the opportunity to work with junior developers or for tech leads trying to make improvements to their engineering culture.

Without further ado, let’s jump right in.

1. Empathy and respect

Empathy is an incredibly helpful factors in ensuring that junior developers are given the space to grow.

It is something that can be observed and expressed in multiple different ways. Some simple examples are:

  • Avoid derogatory speech.
  • Don't assume that the person you're talking to has the exact same knowledge as you. Don't assume they know absolutely nothing, either.
  • Take your time to answer questions without any shortcuts.
  • Make eyecontact. I lost count of the amount of times colleagues only look at other senior developers when talking, as if I wasn't even in the room.

And honestly, if you really do have 30 years of experience writing code and you don’t feel like dealing with junior developers, then respectfully stay in your own lane and don’t get in their way. Don’t go around trying to complicate other people’s lives, or even worse, start bullying them. That, too, is a way of showing respect and allowing others to grow.

It’s very easy to forget that everyone started off as a junior once.

2. Use “we” instead of “you”

This point more or less builds on the previous points. Being part of a team that takes full responsibility and ownership of what they work on is incredible to see. This means all working towards the same goal and trying to keep a clean codebase, rather than criticizing each other’s work.

This point can be observed very easily in code reviews. When you see room for improvement, rather than commenting “why did you write it like this?”, an alternative approach is asking “maybe we can try a different approach in this case because it would be better for this or that reason”.

To illustrate this mentality of "we" instead of "you", I'll share a short story about a situation I found myself in at work. I once shipped code that consisted of a lot of small changes in many places throughout the codebase. A couple of days after that, one of the developers realised that something was broken on production. I quickly apologized for breaking features on production. Then, another colleague turned to me and calmly said: “No, you didn’t break it. We all broke it”. In fact, no one managed to spot the mistake before we shipped the changes. While making the actual mistake itself was rather unpleasant, it's comforting knowing that your colleagues are never waiting for the moment they can blame you for something.

Try to to join and build a culture of breaking and building together and to not engage in any finger-pointing at other developers. Knowing that your colleagues won’t judge you for making mistakes creates psychological safety and is a huge growth accelerator.

3. Pair programming and debugging

For junior developers, pair programming with multiple different developers is highly valuable to improve your communication skills and to get exposure to various ways of working and problem-solving approaches. In turn, it may also help develop your own preferences and “style” of writing code, rather than copying a single person’s way of working and opinions.

Admittedly, pair programming is something that takes a lot of time and patience. It’s very easy to say “it will get done faster if I just work on this feature by myself”. The same can be said when reaching out for help with debugging: it’s much faster to just hand your colleague the solution, rather than walking through what’s happening step by step. Nonetheless, it’s far more valuable to teach someone certain ways of thinking.

4. Find your stretch zone

Tara Ojo has done a wonderful talk on working from your stretch zone. She explains how every developer has three zones they can find themselves in:

  • Firstly, there is the comfort zone. As the name suggests, work that falls within your comfort zone is not challenging. It’s too easy and as a developer, regardless of your experience level, you don’t learn anything new by staying in your comfort zone.
  • Secondly, there is the panic zone. This is the extreme opposite of the comfort zone, where the task at hand is far too difficult, leaving the developer responsible for it feeling extremely frustrated, possibly intimidated, and essentially just extremely lost and not knowing where to even begin. In this zone, too, the developer ends up getting overwhelmed and therefore also does not learn anything.
  • Thirdly and lastly, right in between the comfort zone and panic zone, there is the stretch zone. This is the perfect sweet spot where the developer is sufficiently challenged, has the right knowledge to get started, and is capable of learning new things with just a bit of guidance from peers and colleagues.

Finding one’s stretch zone requires some experimentation, especially when working with junior developers. One way to discover what’s right for the junior developer is to start with tasks such as small bugs or technical debt, allowing the junior developer to work in limited parts of the codebase (so they don’t get overwhelmed). If these kind of tasks seem to be going well, feel free to go ahead and continue with building small features. Identify the knowledge gaps and slowly increase the size of the tasks to help the junior developer deal with challenges without feeling awfully uncomfortable.

5. Say “I don’t know”

This may sound silly to some people, but in my opinion this point carries just as much importance as the previous ones. Hearing other developers say “I don’t know” is absolute music to my ears. As a junior developer, hearing others say “I don’t know” is extremely reassuring and erases the common misconception that experience developers know the answer to every question, and have a solution in the back of their mind for every type of problem. Admitting you don’t know something is nothing to be embarrassed of -- instead, it’s a new learning opportunity for everyone involved! It may even lead to another occasion to pair programming or debug a problem together (see point #3 😉).

Similarly, if you're a junior developer, don't be afraid to admit not being familiar with something. You're a junior, you're allowed to ask questions, and this also gives others the chance to test their own understanding by explaining something to you!

I hope this was helpful! I'd love to hear from you next: what are some things you value as a junior developer? And if you're a senior, what are some examples of how you work with junior developers and contributing to their growth and development?

Discussion (27)

kunde21 profile image
Chad Kunde

Use “we” instead of “you”

Unquestionably, the blame/responsibility is always the team and that's a good start.

The other part I try to foster, on top of this, is an ownership share in the system. Celebrate the first PR as their own, the first delivered feature, first code in production, first bug discovered/hunted, etc.

It's not a big celebration, but at least talk about it. Maybe buy them lunch and congratulate them on the milestone, if you're in the same location.

The backstop, though, is exactly what you mentioned. No one person breaks a system and no one person is to blame. The team deals with bugs and downtime together.

ben profile image
Ben Halpern
  1. Use “we” instead of “you”

I'm really big on this.

_ezell_ profile image
Ezell Frazier

Agreed. I felt like my first job was brutal because I felt like I was an and one than part of the team.

Didn't help that the other devs were a bit condescending at times.

cybermischa profile image
Mischa Spiegelmock

These are important things to write about, thank you.

Another good thing you can help as a mentor is to ask junior developers how they think a problem should be solved, instead of immediately dictating how you think it should be solved.

hkly profile image

Say “I don’t know”

This was so good for me to hear when I was just starting at a new job. Not only did it help me accept that you don't need to know everything to be a good dev, but it also helped the team show that they fostered a culture of humbleness and openess to learning.

wizardrogue profile image
Joseph Angelo Barrozo

Loved your article! Thanks for sharing your experiences and ideas on the issue.

As a struggling senior developer, I can't tell you how much of a joy it is to watch junior developers grow and "stretch." I personally believe that the benefits outweigh the effort when creating a great working environment for juniors, even if it might be tedious to the seniors. Kudos to you!

therealkevinard profile image
Kevin Ard • Edited

Along with the others, one I try to throw out:

Learn from my mistakes/learning.

I usually come back from lunch with some gem I casually toss over to him, and we have a quick intro convo about it. It's friendly. Nothing too heavy.

But what it IS usually falls into 1 of 2 categories:

  • crap. I should have done that THIS WAY. And I know that because (blank)
  • I've studied (blank) for 18 months, and NOW I know (blank)

He goes straight to Google (just like I did for the last 18 months lol), and... Idk... I hope it's a little jumpstart

johnmutuma5 profile image
JohnM • Edited

Great article.

Well, while it's okay to admit that "I don't know", it's also important to keep in mind that junior developers may sometimes be hesitant to publicly do that. It's imperative, therefore, that senior developers keep reiterating that there's nothing wrong with not knowing something, and expressing the desire to explain it, or even exploring it together.

pierreturnbull profile image
Pierre Turnbull

Before starting to work as a developer, I worked in a factory to make money for a new PC. This was an annoying time since my superior seemed condescending and pissed off at me every time he saw me.

Then I went to school and started working in a company as an intern and none of my superiors had such life-ruining behaviours. Empathy, respect, listening and trust were the norm. It was a thousand more enjoyable and motivating.

I still work for them btw :)

muscaw profile image
Kevin Grandjean

I think you explained very well these things. It's never easy to start after school in a totally different environment with stuff you never really saw at school. But having a team there to support you will allow you to progress much faster.

Thank you for your article. It's well written

trisha114 profile image
Trisha Aguinaldo

Pauline, this was a great read! As a junior dev (right off bootcamp) in a male dominated startup I often feel the imposter syndrome. Thankfully, I have great co-workers who pretty much do most of what was mentioned in your article. I am really lucky that my teammates are people who are receptive to constructive criticism. Anyway just wanted to thank you for writing this article!

jmcphe profile image
James McPhee

The most important thing I had to learn as a lead/senior was to give positive feedback as/more often than negative. Reinforcing what someone did was correct is worth more than pointing out where they are wrong. After all, there's an infinitude of ways to do something wrong, but only a few to do it right. Building those mental models is key.

Also, if people only interact with you when you're telling them they're wrong, they shut down when you approach.

cubiclebuddha profile image
Cubicle Buddha

Thank you for #5. I like hearing my coworkers admit that it’s okay to “not know.” I even blogged about the value of empiricism here:

But I rarely say “I don’t now myself.” Thank you for reminding me of the importance of modeling the behavior that you want to see. :)

adamespi profile image
Adam Espinoza

I honestly needed to hear/read this! It's definitely important that managers have standards in how they interact with junior developers. Good read 🎉

elisabethdiang profile image

use “we” instead of “you

Thank you for including this. It’s so important for a cohesive team. Developers would be compelled to learn from seniors through collaborative efforts too.

davidmm1707 profile image
David MM🐍 • Edited

I wish I started as a dev in a place you described.

When I got my first dev job I was the only worker there, working with a language I have learnt 3 months ago, using a framework I never I have used before. It was brutal: No way to know if what I was coding was right, no one to ask, no code reviews, help, nothing.

More people were hired. Now I could ask others but sometimes I feel like I shouldn't, by the way they answer me, like if I was asking if it was day or night.

People with less experience than me were recruited and I see the same. People with 15 years of experience baffled because people with 3 months of experience don't know what they do.

Empathy is very important. Companies lose workers because a lack of it.

kriska profile image
Kristina Gocheva • Edited

This post does not apply only for a junior developer-friendly culture. To me it is for a developer-friendly culture in general. It is not necessary to be a junior. Joining a new company, no matter the position always makes you feel the imposter. In order to adopt what's new for you and feel welcomed, all of the above should be observed within the company culture.
My personal favorite is 3. Pair programming and debugging.

dtamai profile image
Daniel Tamai

I agree! I've been trying to follow four steps when helping junior developers with some specific issue, I just go to the next if they still need help.

  1. understand the problem. Empathy and respect are important here
  2. pinpoint the problem. Good moment to say "I don't know" and pair research
  3. pair program or guide them to a solution, but let them own the solution. This is an exercise in their strecth zone.
  4. give away the solution. Maybe they were in the panic zone.
kwstannard profile image
Kelly Stannard

This is great. I will share it with my team.

I have been mentoring for a couple years now and I will offer this:

  • Prioritize helping out your team members. Your project can wait a few hours.
  • Always explain why. Your team members will thank you. It will also improve your ability to think critically about the problems you are facing in the future if you force yourself to say what you are thinking out loud.
  • Don't wait for people to ask for help, offer your help. Especially on teams that don't do pairing.
  • Look for opportunities for juniors to make valuable contributions to the business.
theweeappshop profile image
Tony Ross

AWESOME article Pauline; thank you SO much for writing this. I've been coding for around 30 years now and it's refreshing to re-visit these wise principles. I, TOO, needed to hear them again and remind myself.

nemethricsi profile image


nileshsanyal profile image
Nilesh Sanyal

Empathy and respect, I agree with you on this point. If junior developers are given proper respect, it will help them to grow as a developer.

skattspa profile image

Thank you for the article! It´s making me think about the "strecht zone".

rifaimartin profile image
Rifai Martin

thank you for sharing, this makes me touched

reach009 profile image
Reach Allen

Thanks for sharing. I am a junior developer myself and I find most of your contents agreeable.

jaepass profile image

I have yet to go through the full post but after reading the first couple of paragraphs, this completely speaks to me! I'm only in my 2nd month and imposter syndrome is raining down hard on me. Only junior dev in a small core team at a startup!

artoodeeto profile image

not in this company. senior sits on my chair fix issues smash enter button and then leaves. lools