8 Tips to improve communication between junior and senior developers in tech teams
Currently Packlink is hiring new developers and some of them are junior talent for our tech team. As a junior myself and after being in this role in different companies, based on my experience I gathered some tips to facilitate communication and make collaboration an easier process. Hope you find it useful. Let’s dive into it.
There is no question that is stupid…
or not important enough to ask.
Every junior thinks their questions are not important, not relevant or even plain dumb.
It is true that sometimes the questions are about processes specific to the company, small details, sometimes they are not pure algorithmic logic, but that does not mean they are not valid questions.
To have an experienced buddy or colleague that makes us, the juniors, feel that we can ask anything is very important and valuable.
With that being said, It is also true that juniors need to try as much as possible to find their own solutions, but when there is no other option, it is time to ask.
Did you understand?
It seems an inoffensive question, but it is not an easy question to answer, let me explain why.
It is hard to say no.
No means, without any shade of doubt for a junior, that their brain is not working fast enough to understand the brilliant explanation just given. So there is a high probability of the junior saying a yes, when they didn't really understand.
What we can do about this scenario can be as easy as changing the question. An option could be “Should I explain it in a different way?”
To this question the answer is easy “OK”. Much easier to say without feeling that they are not good enough.
Another option could be to not even make it into a question at all, for example “Let me explain it in a different way”. To that sentence the other part can remain silent and with that accept or stop you because really they already understood.
With this small change we make this exchange a bit more amicable.
Tasks well defined...
To have well defined tickets, complete, with all the information required to perform the tasks, will really help more inexperienced roles to perform their tasks independently.
When is a good moment to talk…
To the junior eye, everything is more important than their questions. We think that our buddies and more experienced roles always have more important things to do and that their time is too valuable to waste with their interruptions.
It is partly true, the time of a senior role is valuable and more expensive but mentoring is part of the more senior roles, most of the time they are happy to help juniors with their questions, but when?
My tip here will be to get to some initial agreements that work for both parties. I’ve seen different solutions, from having no boundaries (meaning talk anytime you need anything) to having an hour every day to do some pair programming or just to solve any questions gathered during the day by the junior.
Having an agreement on this will reduce uncertainty for the junior profile and it will also allow the senior roles to plan their work and increase focus time.
Refactor timing…
When a junior requests help with a code related issue while developing a task, sometimes it requires the senior colleague to take a look at the code that the junior is currently developing. When this happens the experienced eyes of the senior role immediately sees a long list of things that are not wrong but can be easily improved, shorter, done with a newer method, cleaner, basically reducing the junior solution from a 100 lines long of code to 3.
In this case I will advise that the priority is to unblock the junior in their development, so they can continue with their solution and make it work, keep the ownership and understand their own code.
In a later stage, maybe the PR will be the perfect moment to suggest refactors and improvements.
The pull request review…
This one goes for the juniors. It is a truly overwhelming feeling, more so the first time, to put your code out for others to review and receive comments about it. With time I understood that this is the best opportunity to learn and improve. You have a solution that works but now is the time to build on it with their help, to pick the brains of your colleagues and incorporate their knowledge. There will be different suggestions to improve, reminders for errors, possible corner cases not taken into consideration initially, etc. Many opportunities to learn and get the code to the standard that the team has set for the code base. This is part of the task. For me, the best approach here will be to take one comment at a time, solve them, and request clarification if needed and move to the next comment, until you are done. It will get easier with time and experience.
Understanding the knowledge of the inexperienced colleague…
This will require an extra effort from the more experienced profiles and also a bit of time, to understand what things the junior knows and which ones they don't. So when having a conversation about code we will know things that require explanation and more details and which don't.
Impostor’s syndrome…
It is real. We all suffer from it. It does not matter the years of coding or how much you know about it.
As our on-boarding in Packlink says:
“We’ve hired you because we’ve seen a high potential and we trust you!”
So let’s believe it, trust that you can be better, you can learn and contribute to your team and company goals. Because you can totally do it!
