Today I learned how to be a valuable team member. The original title was “How not to be a jackass teammate”, but keeping a positive attitude is one of the tips I’ll show. You can call this post the “soft skills guide”. I will take you through a developer’s day and explain how person-to-person communication can make you a better team member. Your team’s go-to person, the one that everyone likes, and, after all, the first to get a salary raise and promotion.
But why? Except for your ego and self-promotion. A good teammate can save lots of time! The right help for a teammate can save him days of googling, trial, and error. Connecting with the team can point them toward your flavors. And after all, you can make a significant impact on your company.
But how can I talk about this subject? If you have read through the about me page, you already know I was in quite a few teams. My mom says I’m friendly but in each and every one of these teams I got this feedback. People tend to reach out even though I’m not the smartest person in the room. Since I am a calculated person, I wanted to maintain this status, and even improve. So, I disassembled my behavior, and I looked at what I do and others don’t (spoiler alert- it’s not related to how intelligent you are). Now, I give it to you, free of charge.
Prerequisite
Just as a proper how-to guide would, this blog has a prerequisite section. You might not be the most popular or people-loving person… Being the most professional in your role is also not a must. Yet, in order to succeed you must at least accept these:
- Put your ego aside. This is not about YOU, this is about the team. you should always look for the team’s success, not your own.
- It will consume some of your work time. so be prepared.
- Some of the people in your team like to work solo. Respect that and try to feel people before/when approaching them, that beats every tip I say.
Start with you
As I said, it will take time. So manage it. Try keeping 20% of the week/sprint free. This will give you 2 wins – you’ll gain a deadline buffer, and you’ll have a chance to assist your team members. We sometimes tend to forget it, but helping a friend on a Zoom call is almost never on our schedule. The 10-20% buffer will allow you to help without losing yourself in the sprint.
Do you have some spare time? Reach out to the team on your own, take a quick tour of the office or call one of your available team members. “Hey, what are you working on?” Everybody I met loved talking about what they were doing. Normally, the answer is “can you take a look?” or “do you know…?” This is your chance to also become more involved in what’s going on. And for the most part, it will make you the first person they turn to the next time they need assistance or a consultant.
Be a junction, not a dead end. When a person finally tries to reach you for help, don’t be a dead end for him or her. Whenever you are unable to solve a problem, point to the next place to look. You can suggest a name of a person from the organization, who is more relevant or might have an answer. Alternatively, it can be a link to StackOverflow/Google search/name of a framework or product. But whatever you do, never answer with just “I don’t know”.
Pull-Requests
This small workflow task has an enormous impact on communication and appreciation for each other. If you think about it, PRs are basically a criticism of our work. You did it and finished your task thinking everything went well. And then someone comes and says that you have bugs or that he does not like your style. In the better case, this brings the good-old LGTM (looks good to me). In the worst case, people turn to passive-aggressive tactics. I collected a few helpful tips you can use in the next code review you give.
We’ll start by discussing what (looks) good (to me). Unless the PR has 2 lines of changes, you must comment on it. Teams that work together are the most effective. In our case, it means that one program’s code is a bug for another. Try looking at it from the perspective of a debugger. What information will you need? Do the variable names indicate their role correctly? Are the function names informative? Maybe something is obvious now but will lose context unless commented on…
If you still find that all is okay, I’d recommend adding a comment about something that is uniquely great in this PR. A well-done algorithm? Maybe an informative variable name. sometimes it is a good code comment… It’ll accomplish 2 things: You’ll praise your teammates, and they’ll know their work was considered and appreciated. Literally the opposite of criticism. And it forces you to actually look at the code and maybe find some other relevant comments you missed. It’s okay to mix reviews with good words. Not all comments have to be bad.
now let’s move to the bad- you found some issues in the pull request that should be addressed. happen to us all. Most of my comments consist of 3 parts:
- What is problematic – it is not enough to mark the line(s) but explain further about what is the issue itself
- Why it is considered an issue – add some background, context, or theoretical explanation about it. Feel free to include any related StackOverflow question, blog post, or wiki page.
- What is the expected fix – Provide a sense of assistance. Usually, people tend to agree more when an example is added, especially when there is an additional explanation of good practice.
Here is some example of how it should look like-
Bad comment:
Don’t use init function
❌ Negative approach
❌ Missing good pattern
Good comment:
Using init function concidered bad practice because it is hard to follow when it is invoked. You can write regular function and add it to the main()
✅ Positive
✅ Explanation about the bad practice
✅ Suggested fix
Focus the Team
We tend to forget that we are all on the same team. It usually occurs in the IT vs. Dev conflict, where you feel that YOUR requirements are not being met on time. Or when the product manager drops a new feature or changes the scope of your work. Sometimes a person from another team requests you to do something for them. In these cases, I totally recommend raising a flag to your team leader as fast as possible. You don’t always hear what you like, but it is the team leader’s job to ensure everyone is on the same page. Sometimes IT will not be able to help you due to budget, and the PM request will override your cool-tech feature. But sometimes you will get along with that other-team-person requesting stuff from you. Plus you’ll get political points for “Sorry, but my team leader told me to focus on my tasks now”.
Give them credit. Daily-s, Show and tell, 1on1s, it doesn’t matter when. If you have a chance to talk about a task you are doing, never forget to thank the person or people that helped you along the way. Even if they simply looked at your code and said they had no clue. People love to be appreciated, just like you.
What other things do people like? To hear that they do such fantastic work! If they gave you a tip that solved your problem. Or you find an answer on someone else’s wiki. You might pass by someone showing off a cool tool she created. It may be obvious but not everyone responds with a positive attitude. Just saying “Thank you for X this helped me a lot” can make someone’s day.
Build time is learning time. The scenario where you fix someone’s code and you check it together probably sounds familiar to you. So you compile or run the tests and usually, these things take a minute or two. So you find yourself checking your phone or email/slack… STOP doing that and use that wasted time to explain to your team member what you did. This is one of the biggest time investments and it costs 0.
– don’t be an “add –no-cache it will solve your problem“.
+ Be more like “let’s try with –no-cache. you probably have an old build dependency that conflicts with the change you did. The default cache is good when… but…”
Summary
There are a lot of small things you can do to be a more valuable team member. But from all of these tips, the most important thing to remember is to place yourself as the other person: “If I was this junior developer, what would I not understand and want someone to explain to me?” Once you start with that, you will see that this article is pretty obvious. But also if not – I hope you take at least one of the tips here. They will help others but most will help you.