I’ve only ever worked with small teams in my short career, but I’ve worked in teams for most of my life, having played basketball since I was 8 or so. All these team sports have really strengthened my skills in working as a team, working with others to achieve a goal. No matter what happens you always had your team by your side, it’s much like in the developer world. Unless you're working on a project by yourself, chances are you're going to be working in a team. You’re going to have to get used to other people, in fact you have to pretty much live with them. You will spend 8 or more hours each day with them, which is probably more time than you spend with anyone else in your life. You’re going to have to get along with, now you don't have to love them, you don’t even have to like them, but you have to respect them and work effectively with them. You can’t do everything yourself, nor would you want to, it’s way too much work. Instead you’re going to have to delegate, work together, lean on other’s strengths, own up to your weaknesses, and not kill each other. All this is teamwork, all this is what’s going to make up how effective you are in your career.

Seeing as teamwork is unavoidable, how about we get better at it. It will be a skill that if it’s not your absolute strength it’s going to be your absolute weakness. Michael Jordan says it best: "Talent wins games, but teamwork and intelligence win championships." --Michael Jordan,  he might have been the best player to ever play the game, but if it wasn't for the incredible teammates he had throughout his career he wouldn't have been nearly as successful, sure he would have been just as good individually but he wouldn’t have been nearly as successful overall. He worked effectively with others, and not just okay people, but future hall of fame players, some of the best players to ever play. It’s not only about working with people who are as good as you, or worse, it’s also about working with people who are much better. That can often be the hardest part, because people who are better than you can be intimidating, it can make you feel worthless, simply because they are so much better than you currently are. Yet it’s these types of people that you can learn from, grow from and make you better. It’s not all one sided either, everyone can learn from everyone else. Everyone has something to offer, we all have different strengths and weaknesses, different experiences in life. No two people have had the same path in life, there for no two people will have the same wisdom.

Rules of being an effective teammate

Rule one: Everyone has something to teach.

It doesn’t matter if your the newly graduated computer science student or the 40 years of experience tech lead. You have something to learn from everyone. The sooner you realise that everyone can teach you something, that everyone can learn from everyone, the better teammate you will be. Forcing yourself to be humble, to open up your mind to the thought that everyone can teach you something, allows you to treat people differently. For example, if you walk into a room with the mindset that everyone is beneath you and you know more than anyone in the room. You will walk out of that room a worse person than you went in. You will miss out on the experience of everyone there. I can’t tell you the amount of times I have met someone, thought to myself, well they're just a normal person, they don’t have anything special to add to me, and then been completely wrong five minutes later. One time I was talking to a colleague who was an intern, now he was the same age as me, he was a designer/user experience intern. I expected him to have pretty poor skills on the count that he hadn’t even graduated yet, he hadn’t had any work experience. Boy was I wrong, he had incredible skills, and yet it wasn’t even in the field that he was interning that I was most impressed. He not only knew about programming and could program quite adeptly but he had also been a professional gamer, playing Starcraft 2 professionally at 16! This guy was 22 and had done more than most 42 year olds had. I never would have guessed that an intern, someone who is portrayed as a coffeeing fetching youngster had already done so much in his life and was so incredibly skilled at his job. These experiences humble me each time they happen and i'm grateful that even though I go into every engagement with an open mind, I’m still routinely blown away. I’ve learnt some of the coolest things from the most unlikely sources. Always remember you can learn something from everyone.

Rule 2: Respect everyone in the team

Whether it’s the intern that’s been there one day, or the tech lead who’s been there 40 years, you have to respect each and everyone. This goes far beyond simply “respecting” them, it extends to listening to everyone’s input, not talking over people when they speak, truly listening to people when they say things. Nothing feels more disrespectful than not being listened too. One of the most important things to keep in mind in this day and age, with the abundance of notifications right at our fingertips is the notion of putting it down when someone else is talking. There was a fascinating book I read years ago and have long forgotten the title, but it was about relationships. 90% of the book was about the idea of bids, what are bids? They are the little calls for attention, like when your partner asks you what you think of this couch they are interested in online. Turning and facing your partner, looking up from your device looking them in the eye and actually caring about what they say makes them turn towards you. By turning towards you I mean they get a positive experience out of that interaction, strengthening the bond between the two of you, you turning towards them, makes them turn towards you in the future. When you fail to look up, giving a grunt in approval you turn away from them, giving them a negative experience. These littler interactions are called bids, now I’m not saying you should treat your boss like your lover, that’s just slightly inappropriate in the workplace. However, I am saying you should treat them in a similar manner, turning towards them whether they're telling you how their weekend was or if they're telling you about a bug they have. Turning towards them, paying attention and listening fosters positive interaction, with strengthens the bonds between the two of you. Strengthening the bonds brings you closer together, it brings the team closer, the closer the team is the better it will work together. Treating each other with respect means they perform better at work, feeling valued at work will provide more efficiency boosts than any fancy office equipment could.

Rule 3: Understanding everyone’s strengths and weaknesses

Everyone one has things their good at, similarly everyone has things they're bad at. Understanding how you benefit the team and how others also benefit the team, makes the team work in a more cohesive manner. The chain is only as strong as its weakest link, when you have someone who works exclusively with Javascript and the frontend, to then get put on strict SQL, all while the person who’s very good at SQL but not at Javascript is stuck programming in Javascript. They're not going to be very effective, either of them, simply swapping what their doing will provide huge benefits. Most of the time it’s not going to be that simple, yet the example is still valid. Getting developers do perform work on the things that they're good at will lead to better results than getting them to do things that they aren’t good at. Take for example when I was working on a ticket it required some SQL I went to my boss, Vlado and discussed the problem with him. Now I haven’t done a tonne of SQL before, I know my way around, I can do the basics and work out the rest, but this problem was a little over my head. I went to him and asked for help, we worked on it together, I learnt some things about SQL, we solved the problem together, we also solved it much faster and probably much more efficiently than we would have if I had done it on my own. Now I did about 80% of the ticket, but that last 20% was above my head, I could have sat there and tried to nut it out, but instead I went to someone that knew more than me. Leaning on the strengths of others helps more than just you, it helps the team as a whole. It saves time, money and more time.

Rule 4: Communication

Working in a team is another way of say I’m stuck with a group of people that I spend more time with than my spouse. Working in an effective team is the same as having a harmonious and successful marriage, you have to work out your problems, you have to communicate with each other and you will fight. Communication is what turns fights from little mishaps to relationship dividing events. Communicating with each other in an effective, calm and open manner is what allows you to work. In agile development we have the concept of standups, we sit or stand and discuss what we have been working on, any blockers, questions, and concerns. It’s this time that allows us to tell each other how we are feeling with the current work and how it’s progressing. Yet often the communication stops there, instead of reserving it for 5 minutes at the start of the day, talk more often. Everything from personal issues that could be affecting your work here, to the backend progressing so slowly that the frontend is left twiddling their thumbs. As the frontend developer, you could sit there, blame the backend, complain, get angry, but it’s not going to help you in the slightest. Instead talking to the backend developers about why the feature they said would be done last week isn’t finished. This leads to the backend devs saying well we ran into some huge issue with the way wanted to implement this feature, it’s going to take much longer than we originally anticipated. This communication can turn the hostility of the two parties into an understanding moment. It turns from a “lazy backenders” to an understanding that unforeseen things happen. I’ve said it so many times already but communication is key to any team endeavour.

Rule 5: Take responsibility

When you have the guy who thinks he’s god’s gift to programming, come in and produce this atrocious bit of code, commit it and then blame everyone else for its poor quality, will result in a very hostile environment. Instead, if you write some terrible code, you own it, you ask how you can improve it. Your teammates will be very willing to lend a hand when you take responsibility for the atrocity you created. Furthermore, how many times have you written some code and then later down the track it turns out that it was actually terrible code and it’s causing a whole bunch of issues which ands weeks of development time to the project? Well it happens often, everyone at some point in their career has written some god awful code and it’s come back to bite them. Just own it, don’t try and hide, don’t pretend you didn’t know what you were doing at the time, don’t make any excuses, just accept that it was terrible code and fix it. People don’t care about any of the thousand excuses you could make, they just care about the way you fix it. Go out and fix it, accept that you fucked up, and fix it. You will earn more respect from your fellow hackers by owning it and fixing it, than pretending that it’s all good, or making some terrible excuse.

Being part of a team is of one the hardest parts of being a programmer. It requires a lot of practice, you have to handle people's emotions and egos, you will have to deal with people that have 10 times the skill you do and 10 times less skill than you. You will fuck it up, you will get into arguments but you can mitigate it and you can be someone who others actually want to work with and always follow the golden rule. Don’t be a dick.