This post was originally published, by myself, on the Bit blog

In my career, I have had the pleasure to work for several years with teams from different parts of the world, each with different ways, cultures, and experiences. Of course, there have been highs and lows, both from a personal and technical point of views.

This makes me often reflect on how the soft-skills capacity of each team affected not only the technical results but also the personal wellness and job satisfaction. That is why I strive every day to improve and reflect upon my own soft-skills and to share with others my thoughts and my advice.

This article is ultimately a write-down of my thoughts about being a good teammate, and what I wish every single one of my future colleagues would know.

Before we start: what are Soft Skills?

Soft Skills are a mix of communication, emotional, social and people skills that enable us to work well with other people.

These are often overlooked, and yet, a crucial set of skills in the software development world that in my opinion, every software developer should understand and try to develop the beginning of their careers.

Sure, writing good code is important, but I tend to place hard skills and soft skills on the same level of importance for every programmer. In my opinion, a great programmer (or the infamous 10x engineer) also needs to be a great teammate. The two things go hand-in-hand.

If you’re about to embark on your first programming job, or even if you’re a veteran already, read on and reflect on the points below.

A great programmer (or the infamous 10x engineer) also needs to be a great teammate. The two things go hand-in-hand

Develop Empathy

Empathy is the ability to understand the feeling of another person. To momentarily imagine yourself as another being, and try to think what’s it like to be that person. This is, in my opinion, the foundation of every interaction.

As developers who have to collaborate with numerous people, some of which you may like or not like, our empathy is challenged multiple times daily, in a variety of situations, such as:

• when pairing and reviewing

• when gathering requirements

• when debugging someone else’s code

• when leading other programmers

The importance of Language

Language and communication have a huge impact in our every-day lives: too many times, I notice that people come off as condescending or brush due to culture and language-related skills rather than their lack of empathy; especially for some people who have not mastered 100% a certain language, they are often more easily misunderstood than native-language speakers.

Due to the diversity of the teams I work in, situations like these happen daily; it’s not easy not to get frustrated sometimes. When a person speaks another language, you’re faced with two issues: words-choice, and cultural aspects.

Words-choice can, of course, be driven from cultural aspects: for example, in English (and especially in the UK) we often use “sorry”, “thank you”, and “please” in our sentences.

Of course, we expect the other person to be knowing this and to be using the same words when due. But what if our interlocutor’s language does not make use of these words as often (or at all!)?

I am myself not a native-English speaker, which is the reason why I can relate with other people in this sort of situations: I’m empathetic towards them.

In short, that’s why it is so useful for programmers to be empathetic. It’s a skill that we need to use all day, every day, even if we don’t really know that.

Listen, then talk

This is probably common sense that is universally valid, but it needs to be listed. As developers, after all, we strive to be efficient in every aspect of our lives.

Interrupting your colleagues is one of the most common behaviors I see during meetings. That’s a sure way to frustrate your colleagues, in case you were wondering.

Listening first and carefully is incredibly important, and not only a for a matter of respect, even when you are disagreeing on every single word. You may think it’s a waste of time, and yet it’s the right thing to do.

Listen carefully, then talk

Teach, but also learn at the same time

It is very easy to come off as condescending when you are trying to make your point, explain something, or while mentoring someone else.

Communication is extremely hard, so you should expect this to happen even when you totally did not mean it.

There are ways we can try to avoid sounding condescending while discussing:

• of course, choosing carefully your words is important, and my advice is to be as neutral as possible: for example, rather than “a bad approach”, I would say it is “not optimal” or that “it could be better”

• stop commanding, start advising instead: instead of saying “you should do it that way”, you can say “my advice would be to do it that way”

• stop only talking about your point of view; ask questions regularly and check your interlocutor’s view about what you’re discussing

• stop assuming you know everything about the subject

Communication is extremely hard, so you should expect this to happen even when you totally did not mean it

Accept criticism & Be open to change

Ours is a creative industry.

To us, our code is art, the same way a painting is to an artist or a song to a songwriter.

Being developers means being judged every day, in a way or another. As we tend to identify personally with our outputs, we take any judgment to our code, our ideas, and our views extremely at heart.

One of the hardest parts of our jobs is accepting criticism from others, be it during interviews, meetings, PR reviews, etc.

I don’t think I have nailed this one yet myself, but I surely improved drastically since my first years as a professional.

We spend years crafting our skills in a particular technology, and as time passes, we become accustomed to our ways of doing things, or to the ways of our team. As a result, we become increasingly resistant to changes, especially when they’re brought in from a third party.

Remember that new guy who wanted to start refactoring the whole codebase? Or the one who wanted to introduce Go and replace your Java stack? I’m sure we all, at some point, lived such situations: I don’t know you, but to me, they (irrationally) felt these as personal attacks.

Understandably, developers hate change.

If you haven’t noticed, this goes both ways:

• the new hire likes the architecture at his previous company and is impatient to rewrite everything the way he’s used to, cause he’s 100% sure it’s better

• the team, instead, is used to the way they have written their codebase (or to the way they inherited it) and have no intention to let the new hire change everything

Of course, this is a generic scenario (very common, though), and any of the parties may be right. Maybe the current architecture really is bad and needs refactoring, and maybe the guy is just being very opinionated.

The point is that if you instantly feel attacked when someone else brings up the eventuality to change something, then the problem is with you, rather than with the idea itself. You’re **irrationally getting defensive **against a new approach before evening fully understanding it.

I think this happens to me all the time. It’s how I am, and how many others are. How do I make sure I don’t combat the idea because of me?

• I listen carefully to it

• I ask my colleague to give me some time to make some research and think about it

• I get back with my honest thoughts

If you instantly feel attacked when someone else brings up the eventuality to change something, then the problem is with you, rather than with the idea itself.

General Advice

• If you think a colleague did a good job, don’t hold back and compliment them genuinely

• Give credit to others when due

• Be as transparent as possible: talk to your colleagues about clarifications, changes, and opinions. For example — sneaking in commits when someone is out-of-office is not a nice way to refactor someone else’s code. Talking and thinking about it together openly is

• Sometimes conflicts will happen if you did nothing wrong and followed all the possible advice; remember that this is absolutely normal, we can’t control everything. Companies and humans are complex, and this is simply a simplification of what actually happens every day

Takeaways

Of course, this is a personal opinion of mine about what makes a good team-mate and how a well-rounded software engineer should behave with colleagues and in the workplace. These are not scientific aspects — just my view based on my experience.

In summary, here are some of the aspects that I would want to see in someone as my next colleague:

• Being empathy makes you a better person but especially a better colleague

• Try to understand the other’s point of view, taking into account culture, language, and how their social norms can differ from yours

• Stop dismissing other people’s opinions before hearing their’s full argument

• Try not to be condescending in situations where misunderstandings and conflicts are easy to arise

• Try to be more open to criticism and change, and understand when you’re irrationally getting defensive for your opinions

• Sometimes bad situations will happen even if did everything correctly from your point of view; don’t get discouraged, it is normal and these will serve as experience for your long career