The majority of devs work in teams regardless of whether its a small shop, big shop, open source project or even single developer shops. Teams are typically more productive than a single developer working alone, and there are some legendary teams out there like the WhatsApp team that supported 450 million users, on multiple platforms, with only 32 engineers. This is why a fundamental job requirement in most job postings is the ability to work well in teams.
If you think back to your experience working in teams you may have come across one or two of these types of teammates? The first guy is the teammate that the other team members cringe when they have to interact with him/her. The teammate that causes mild anxiety whenever they check-in/commit some code. The one that the others feel is dragging the team down or cannot fully be trusted. On the other hand is the great teammate. The one other team members to bounce ideas of and brainstorm with. The one whom everyone respects and who has a great reputation. The guy that raises the productivity and harmony of the entire team.
Here are a couple of things to get you on your way to being that great team mate.
Unit tests help to verify at the most basic level that the code you wrote is consistent with your intent and behaves appropriately under varying inputs. Good unit tests don't only test the happy path but also exceptional and edge cases. But its not good enough to write unit tests, they also have to be run. Unit tests that don't get run are just as useful as not having unit tests at all. In teams that value unit testing, bad dev teammates don't write/run the tests and reduce the code coverage.
Another important form of communication is documentation. Users of your library, class, app, script or service need to know how to use your product. And your fellow developers need to understand the problem you are trying to solve in order to be able to support the product when you are unavailable. Documentation is part of being a good citizen.
Transparency about your strengths and weaknesses also aid the team in delegating tasks to everyone's strengths and allows the team to function at peak efficiency.
Clean code is simple and direct[2]. It's expressive, doesn't obscure the designer's intent but rather is full of crisp abstractions and straightforward lines of control[2]. It has meaningful names, minimal dependencies, which are explicitly defined, and provides a clear and minimal API[3]. The logic should be straightforward to make it hard for bugs to hide, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations[1]. Clean code can be read, and enhanced by a developer other than its original author[3].
In the same vein, be humble, give others credit when its due, admit it when you are wrong or made a mistake. No one likes an arrogant prick.
When you concern yourself with what others are working on, it weaves you deeper into the fabric of the operation of the team and makes you more indispensable.
What's great about stepping up and making the little extra effort it takes to alleviate these pain points is that you are not only solving a problem for the team, you are also solving the problem for yourself.
Sometimes the solution is not something you have to do, but something you have to research and find out. When you find that "greatest regex cheat-sheet" or "git reset tutorial", be sure to share it with the team if its a common pain point.
Have more advice for how to be a great developer teammate from your experience? Leave them in the comments.
[1] Bjarne Stroustrup. Clean Code (page 7) [2] Grady Booch. Clean Code (page 8) [3] Dave Thomas. Clean Code (page 9)
If you think back to your experience working in teams you may have come across one or two of these types of teammates? The first guy is the teammate that the other team members cringe when they have to interact with him/her. The teammate that causes mild anxiety whenever they check-in/commit some code. The one that the others feel is dragging the team down or cannot fully be trusted. On the other hand is the great teammate. The one other team members to bounce ideas of and brainstorm with. The one whom everyone respects and who has a great reputation. The guy that raises the productivity and harmony of the entire team.
Here are a couple of things to get you on your way to being that great team mate.
You write good unit tests and run them often!
Bad dev teammates don't test their code! They push out broken code to the central repository or into production and wait for someone else to find the bugs.Unit tests help to verify at the most basic level that the code you wrote is consistent with your intent and behaves appropriately under varying inputs. Good unit tests don't only test the happy path but also exceptional and edge cases. But its not good enough to write unit tests, they also have to be run. Unit tests that don't get run are just as useful as not having unit tests at all. In teams that value unit testing, bad dev teammates don't write/run the tests and reduce the code coverage.
Side bar: In writing unit tests, care should be taken to ensure that the tests are fast. When tests run slow, you won't want to run them frequently.
You communicate any and all information that could be beneficial to your teammates.
Make a breaking change to an API? Found a new trick/tool that could be useful? Found a bug that affects others? Don't think you can make that deadline? Changed the database password? Created a new web service or shared library? Communicate that. Send out a message on the dev channel of whatever collaboration tool you use or to the team email inbox or wiki. Make a habit of broadcasting information you think may be remotely useful to someone else on the team. Information exchange is the currency by which a team functions. Individuals who frequently communicate relevant information capture the ear and attention of audiences.Another important form of communication is documentation. Users of your library, class, app, script or service need to know how to use your product. And your fellow developers need to understand the problem you are trying to solve in order to be able to support the product when you are unavailable. Documentation is part of being a good citizen.
You know your strengths and weaknesses and be honest with your team about what they are
This helps with expectations. If you pass yourself up as great at javascript but end up writing crappy javascript code you break the trust of your teammates and invite greater criticism of your work. However, if you are honest with your javascript skills and ask for help or a peer review, your teammates will respect your effort and will jump in to help. You'll get some learning out of the experience and would have fostered an atmosphere of cooperation.Transparency about your strengths and weaknesses also aid the team in delegating tasks to everyone's strengths and allows the team to function at peak efficiency.
You write readable / clean code
We spend 10 times more time reading code than writing it; therefore code should be written with readability in mind. How many times have you wanted to punch the developer who wrote the massive mess of spaghetti code you are now having to maintain / refactor. How about the dev who wanted to show how smart he/she was so they implemented a really convoluted architecture or distilled a 20 line block of code into 1 unreadable line.Clean code is simple and direct[2]. It's expressive, doesn't obscure the designer's intent but rather is full of crisp abstractions and straightforward lines of control[2]. It has meaningful names, minimal dependencies, which are explicitly defined, and provides a clear and minimal API[3]. The logic should be straightforward to make it hard for bugs to hide, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations[1]. Clean code can be read, and enhanced by a developer other than its original author[3].
You listen to the opinions of your teammates (even the ones you think you are smarter than)
I've had team leaders before who didn't listen to my opinions on architectures, designs or ideas. Do you know what happened with that relationship? I stopped giving them my opinion! There aren't too many things that kill communication faster than deaf ears. There's a difference between hearing and listening. Hearing is passive and takes no effort. Listening is active and implies leaning in. Even if the other person's pitch may be flawed, listen to it without deriding them. If necessary, show them where you think the shortcomings in their arguments are. Think about the factors behind their proposed solution. Take time out to prove things. Don't be in-flexible or unwavering.In the same vein, be humble, give others credit when its due, admit it when you are wrong or made a mistake. No one likes an arrogant prick.
You take time out to help your teammates with their questions, issues, or bugs
There is a tendency for some of us devs to get really focused on our tasks and not be willing to help others out with their questions, ideas or bugs. We often do this because distraction is a top killer of productivity. However, we need to understand that while your productivity is important, of equal importance is the productivity of the team! And if a teammate cannot move forward because of an issue, question or bug that they need your help with, you may get your stuff done but the team suffers as a whole. Stopping what you are doing to help out not only unclogs the gears so that the engine that is the team can start functioning efficiently again, it also earns you appreciation, respect, beers and IOUs.When you concern yourself with what others are working on, it weaves you deeper into the fabric of the operation of the team and makes you more indispensable.
You solve pain points on the team
Is there a compiler warning that bugs the crap out of the team but no one makes the little change to make it go away? A small improvement to the painful deployment process to make it a little less painful? A small tool or library that needs to be written or introduced in order to solve a common problem? A script that can automate an oft repeated manual process? An office printer that needs to be taken out into a field and beaten to death with a baseball bat?What's great about stepping up and making the little extra effort it takes to alleviate these pain points is that you are not only solving a problem for the team, you are also solving the problem for yourself.
Sometimes the solution is not something you have to do, but something you have to research and find out. When you find that "greatest regex cheat-sheet" or "git reset tutorial", be sure to share it with the team if its a common pain point.
Lastly, Don't be lazy
Laziness leads to that unclean, untested, untestable, unmodularized code that causes maintenance nightmares for your teammates. Laziness also sends the message that you are unreliable and untrustworthy as a teammate. It damages your reputation. Hardwork on the other hand is infectious. It causes the rest of your teammates to raise their game. It earns people's respectHave more advice for how to be a great developer teammate from your experience? Leave them in the comments.
[1] Bjarne Stroustrup. Clean Code (page 7) [2] Grady Booch. Clean Code (page 8) [3] Dave Thomas. Clean Code (page 9)
