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?
If you enjoyed reading this post or if it was helpful to you, you can support me by buying me a coffee — I'd really appreciate it! 🙏
Top comments (27)
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.
I'm really big on this.
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.
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.
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.
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!
I honestly needed to hear/read this! It's definitely important that managers have standards in how they interact with junior developers. Good read 🎉
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!
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.
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: dev.to/cubiclebuddha/why-i-was-wro...
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. :)