On Helping Junior Developers:
Communication Styles and Why Juniors Should Pick Their Own Mentors
First, some context. I’ve been working in tech for the past few years as a frontend developer. All my roles so far have been at start-ups, which have been amazing opportunities to be exposed to a lot of different skill sets and areas of business. I’ve even been lucky enough to work with extremely talented senior developers who really enjoy teaching. They make time in their schedules to help others and they’re patient if I don’t feel like I completely understand their answer the first time around. I’m not afraid to ask clarifying questions and don’t feel like I’m wasting time by asking for advice with tools they have more experience using.
It’s been incredibly helpful working with so many skilled coworkers and their help has increased the quality of my code much faster than I could on my own. That also means new features and bug fixes I’m assigned come out faster than if I struggled through difficult tasks completely on my own.
In addition to this “teacher” type of coworker, I’ve also worked with more senior developers who consider themselves a good resource for development information but have more difficulty communicating information. Often it’s a difference in communications styles, although in some cases they’ve openly expressed a lack of interest in building the skills that are required for effective communication.
In short, some developers prioritize what they’re saying over how they’re saying it. They admit to being less interested in so-called “soft” skills.
When I first entered tech I was honestly a little worried about the interpersonal aspect of working with other developers. Prior to working in tech I worked in mental health care; I was used to emotions and communication being the most important topics in my day. First as a manager in a recovery centre, I spent most of my day having direct contact with clients and health care practitioners, while also doing more independent work like invoicing and scheduling. After that I started my Masters of Social Work and was a clinical intern at a mental health hospital for a year doing individual and group therapy.
Both experiences emphasized the importance and subtleties of language. I learned that it’s often more important to accurately get the tone of my message across than it is to get every little detail right: you can usually clarify what you mean but you may not be able to continue a conversation once a person decides they don’t want to talk to you anymore. Your intention typically doesn’t matter once you say something that causes the person you’re speaking to to lose trust in you.
These lessons about the importance of tone in communication have applied far beyond mental health services. Of course what we say is important, especially in fields like development where things either work or don’t work. However, in any field there are great communicators who can manage the tone of what they’re saying, and there are people who are more “content”-oriented. That is, they care about communicating the content of what they’re saying accurately with less regard for how they say it.
With these experiences in mind and from talking to friends in the field, I’ve noticed four main personality types related to the junior-senior developer relationship. I believe that the behaviours exhibited by these personality types are sometimes intentional — the person takes pride in them or is at least aware they act this way — and sometimes not. We don’t always know how others perceive us and our intentions can vary greatly from how we’re perceived.
Noticing these patterns in communications styles has also made me reflect on which ones have been most helpful in my own coding journey. Professionally, some colleagues have made me a better coder, whereas some have actually ended up making me feel less confident and capable.
The first personality I’ve noticed is everyone’s favourite: The Smart Communicator (or “A” in the plot above). They’re well-informed on the topic they’re discussing and they discuss it in a way that is concise, engaging, open to discussion, and not condescending. This personality is especially helpful for junior developers because they can provide information without making the person asking for help feel stupid or like time is being wasted for asking a question. They say things like, “Please let me know if I’m going through this too fast,” or, “Which way do you learn new concepts best?” In short, they’re empathetic to the person they’re speaking to while delivering technically-strong content.
I personally feel so lucky when I meet a “Smart Communicator” because they often become an amazing source of information, support, and community in a field that can often be intimidating or overwhelming. I genuinely enjoy learning from this person and they seem to enjoy teaching. Our interactions feel balanced and productive.
The second personality is the more stereotypical software developer: The Asocial Intellectual (“B”). This is the person who knows a lot but describes how things work with little regard for the person to whom they’re speaking. They may have more difficulty with experiencing or demonstrating empathy. This person is sometimes genuinely trying to be the “Smart Communicator” but haven’t fine-tuned the social skills to properly represent that intention yet. They may come off as harsh or move through ideas too quickly for the junior afraid to interrupt. Conversations can end up feeling counterproductive because the knowledge sharing may end up taking longer than learning on one’s own.
In my experience, I find this sort of personality is often well-intentioned but awkward or rigid in conversation. If this communication style seems unintentional, I don’t take any harshness personally. Working with others means bending to meet people where they are, and hopefully they do the same.
However, there’s also the “Asocial Intellectual” who doesn’t want to consider with whom they’re speaking. They may not see the importance in managing the tone or delivery of what they’re saying; the energy it takes to manage how information is communicated might not seem worth their effort.
I’ve found this is the person who typically knows a lot but is difficult to learn from. They leave little room for clarification and can often amplify any feeling of imposter syndrome a more junior developer may already be feeling. This is the person who I think wrongly considers coding the only job of a developer.
I’ll put less of a focus on the last two groups here because we all know these people but typically try not to go to them for support or information. They’re the Ill-Informed Jerk (“C”) and the Overly-Confident Sweetheart (“D”). Both seem to have a hard time admitting when they don’t know something, as well-intentioned as their help might be. The former category is the person who doesn’t have enough information and is somehow also rude or insulting about you not knowing either. The latter category is the nice person who answers questions in a kind or thoughtful way but probably should have added the disclaimer they don’t know the topic well enough to give a reliable answer.
I typically view both of these responses as a defence mechanism: we all feel vulnerable when we don’t know something we think we should, or are scared to be called an imposter. Some people have a harder time than others admitting they don’t have enough information to discuss the topic at hand.
Part of the reason I’m trying to emphasize that the intention of these four personality types can vary is because it doesn’t necessarily matter for the more junior person with whom they’re speaking. In conversation, often how you make a person feel is more important than the content of the conversation.
While working in mental health, one of the reoccurring lessons we learned while training to be therapists is that the therapeutic alliance is more important than the style of therapy being done. That is to say, it’s more important that a client feels connected to their therapist than which type of therapy they do to achieve their therapeutic goals. Relationships matter and strong relationships lead to more positive long-term outcomes.
I think this applies to junior-senior or mentor-mentee relationships as much as it does to therapeutic relationships. When a junior can ask a senior a question without fear of feeling more stupid by the end of the conversation, or they feel questions are a good thing because it promotes knowledge sharing, they are more likely to continue asking for support and learning at a faster pace.
So, what does this mean in the context of improving how senior developers can help more junior developers? First and foremost, not every senior developer will be an effective teacher for others on the team. These four personalities I’ve mentioned aren’t strict rules but may indicate that some colleagues may just not be strong knowledge-sharers. This isn’t necessarily a bad thing; we all have different skills and some people go into software development because they can spend more time in private, deep thought than in many other fields of work.
However, given that some people may not excel at knowledge sharing (and may not want to), it is therefore important for employers and developers to self-reflect on this when trying to create a supportive and educational environment for more junior developers. If nothing else, senior employees should ask juniors for feedback on their work together so everyone can have a better sense of where there may be room for improvement. Empathy, like coding, is a skill that can be learned for most.
Overall, communication styles are a key factor in how teams will interact and even more so with a junior-senior power dynamic in place. It is not enough to have knowledgeable employees on teams when introducing more junior developers; there must also be value given to how knowledge is communicated.
This also means junior developers may naturally be more inclined to ask for help from certain people on their team than others. Because of this, it can be counter-productive to assign team members to more junior people once everyone has learned each other’s communication styles. Put anyone in a room full of people and they’ll naturally feel more inclined to speak to some people more than others.
For senior developers, this also means being more reflective on your own communication styles and if this is an area you should consider improving. If it’s not a skill you’re confident in, start asking others for feedback. Often we can’t know how we’re perceived without asking others. For those who know it’s a skill that needs work, consider this the area that you are more “junior” in.
If the goal of working on teams is to improve overall team skills, then we all have areas of improvement. Some more technical than others.
Note: I don’t think developers can be split into “junior” or “senior” groups in any objective way; however, I’ve chosen these terms to reflect how team members are often distinguished.
