5 ways to create a junior developer-friendly culture

Lets 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, lets 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 I wasn't even in the room.

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

Its 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 others 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 didnt 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 wont 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 persons way of working and opinions.

Admittedly, pair programming is something that takes a lot of time and patience. Its 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: its much faster to just hand your colleague the solution, rather than walking through whats happening step by step. Nonetheless, its 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. Its too easy and as a developer, regardless of your experience level, you dont 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 ones stretch zone requires some experimentation, especially when working with junior developers. One way to discover whats 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 dont 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 dont 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 dont know is absolute music to my ears. As a junior developer, hearing others say I dont 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 dont know something is nothing to be embarrassed of -- instead, its 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?