Not Only Code

Supporting your teammates

Gregory Witek -

In this video I'm talking about how to start supporting other team members, even if you do not feel very confident about your own skills. I explain what are different ways that you can collaborate together and what are some DOs and DONTs when it comes to working with other developers.

📚 Resources:

Notes

Introduction

One of the responsibilities of senior developers is to support other team members, especially those who are less experienced. It's not an easy thing and besides technical skills like debugging or problem solving, it requires empathy, some teaching skills and, well... definitely some patience. Let's discuss how you can become better at supporting junior developers!

How to start?

If so far you've always been the person that asks others for support, it might be quite intimidating to give advice and you might feel too humble to do it. Especially if you're a rather shy or if you're a new person in the team.

First of all: it's alright, that's normal. The feeling of stress when giving someone advice, because you're afraid that what you suggest might be wrong, it's real.

Start with something you feel quite confident about. For example, someone might be working on a feature that you initially implemented. You can just tell them, "hey, I worked with this code before, if there's something you don't understand or you're not sure about, let me know".

And be assured that there's nothing wrong if you say "I don't know" or "I'd rather ask someone who knows more about it, cause I don't want to give a wrong advice". I am a team leader and I say it everyday!

Ways to support others

Ask whether everything is clear

You can always ask the other person "Hey, I see you're working on this task, is everything clear there? If you believe you could use some help, let me know!". You can suggest having a chat over coffee or a video call. Very often people get stuck on something but they're afraid to admit that they don't know how to make progress, because they believe it might make them feel stupid, or they simply don't know who to ask for help. Hell, I never have any problems asking people for help, and I still appreciate when my manager or one of my peers checks up whether I need some support. Even when I don't need any help, it just makes me feel better to know, that I can count on others

Go over a problem together

There's this saying that 4 eyes are more than 2, or that 2 heads are more than 1, or that... you know, that by working together we might solve problem that we can't solve alone.

Just sitting down and going through some problem together might be a big help. Your teammate can explain you where they get stuck or what they don't understand, or how they have 2 alternative solutions and they don't know which one to choose.

Pair programming

While it's a technique that requires some practice, pair programming might be a great way to crack a problem together. Make sure to get some space where you can comfortably talk without interrupting others (ah, the beauty of the open office, ain't I right), take a big screen and laptops with you, sit together and work on a problem. If neither of you has much pair programming experience, it might be initially awkward, so you might want to read some guides before you start. Still, it's a great idea, no matter whether it's 2 senior developers working together, or senior and a junior, or 2 junior developers - pair programming helps to produce better, less buggy code

Pair code review

Similarly, code review (which I hope you do regularly, even if you're junior engineer), can be done together. There are 2 good ways to do that:

  1. Sit down together and go through the changes. As you try to understand the code, you are asking questions, and suggesting changes. For each discussion or change you can leave a comment on the pull request
  2. Alternatively, you can write a draft review first, and before publishing it, sit down together and go through your comments.

What way works better - that depends no you. Some people might say that the 2nd one is not a real pair code review, but it doesn't matter. As long as you go through the code together, clarify doubts, agree on what and how to change, you're going to be fine.

DOs and DONTs

DON'T: be impatient

See what I did there? Double negation, let's fix it!

DO: be patient

Remember that everyone's knowledge is different, and that knowledge impacts the pace at which we learn some new information. For someone who's been mainly involved in web development, it might take more time to understand some aspects of writing desktop applications etc.

I used to struggle with this in the past, sometimes I found some concepts very simple and I struggled to explain them well and got impatient when people could not understand what I meant. That led to stressful situations for both sides. By remaining patient and remembering that learning is a complex process, you ensure that you remain in a good relation with whomever you're helping.

DONT: worry about making mistakes

Everyone makes mistakes! If you suggest something that later appears to be a bad idea, just say "sorry, I hadn't thought about this" and move on.

I've suggested something that eventually didn't work more times than I can count. Sometimes thankfully it was caught by another developer, sometimes it was caught by my CTO when he got an alert in the middle of the night. It happens. Apologize for making a mistake, remember the lesson, move on.

DONT: force anything

Remember not to force anything. If you still don't feel ready to proactively tell others that you can help them, that's fine, it might take time. If you offer someone to pair program together, but they're not convinced - that's fine, tell them about the benefits, send them some resources to check, but don't force anything.