Coding in a team requires more than just coding skills. A modern software developer is not only a programmer but also an architect, communicator, teacher and learner. There are many tools and practices that help developers to work effectively in a team and to create code that is maintainable and extendable by all team members.
In this article you will learn what is important if you want to develop great software with a team. Great meaning the code is working, clean and easy to change.
The modern software developer
As Steve Ballmer, former CEO of Microsoft, knows the developers are the foundation of every team which creates software (see his great speech!).
When I talk about software developers I don’t talk about mere programmers. Modern software developers are not code monkeys but skilled team players. They must have social skills as well as technical skills. They have to be team coders.
Developers are responsible for the code they write, but they don’t own it. Code is always owned by the whole team. We should avoid knowledge silos. Every developer should be able to continue a task of a team mate if the team mate, for any reason, cannot continue with the task on her or his own.
Of course there will always be experts for different areas. Imagine a database geek. This person shouldn’t do any task which has to do with databases on her own. She could be responsible for databases but she must not be the only one in the team who has a clue about it. Instead, she should introduce her team to the topic through pair programming or other methods which I will write about in upcoming articles.
Traits and tools of a team coder
In a team you have to trust others and be trustworthy yourself. You need to be honest and transparent. This seems simple and clear since our mothers always told us to be honest but in reality it’s often different. We all remember situations where we should have been transparent but tried to hide some information just to feel more comfortable. Sometimes we are afraid to admit that we can’t find a solution for a problem, because we fear that others think of us as less professional. But real professionals inform their teams when unexpected problems occur and in a healthy team there will be somebody who offers help.
Not everybody in a team has to know all the details about the things that you are currently working on but everybody should know which task you are working on and what your problems are. Only known problems can be tackled and it is a huge advantage of a team that you don’t have to remove all the stones, that are blocking your way, by yourself.
Transparency also means that you say “No” to unrealistic goals set by your manager. It is both unprofessional to lie and say “Yes, we can do that” and to say “We will try” even if you are sure that it is almost impossible. Transparency and honesty to your manager and your company or customer is as important as to your team. There is an interesting chapter about “Saying No” in Uncle Bob’s great book The Clean Coder.
Knowledge and experience are the capital of a coder. In our fast-evolving industry we are forced to always update and extend our knowledge. Like Gerald M. Weinberg has written in the 10 commandments of egoless programming:
No matter how much “karate” you know, someone else will always know more.
Team coders will always try to find people they can learn from and to establish a culture of learning which means that they will constantly share their knowledge.
The best way to learn is to teach. Sharing knowledge with the team doesn’t only help your teammates but also yourself. If you explain something you are forced to think about the topic and it’s details which deepens your understanding of it. The feedback from your Padawans will also provide you with new perspectives.
Extreme Programming provides a lot of great ideas how to perform software development in a team effectively. This blog is going to cover some of them like continuous integration, test-driven development and ways to create a simple software design.
What if you don’t have a team?
So what if you always work alone? If you have your personal projects or if you are the only person developing that software in your company? Then you also have some team members: The future versions of yourself! Because after a few months you may not remember what the hell you were thinking when you wrote that piece of code.
Even if you work alone you use tools like Git and some kind of task management tools or to-do-lists, right? And why do you do that? You do it to communicate with the future versions of yourself. Because they probably won’t know every detail you know now. So even if you work alone you should always work like you had a team around you.
The future versions of yourself are not the only team mates you’re going to have if you work alone. Imagine working in a company. You have your own project which you work on. If you are successful and the software grows over time, the time will come where you cannot work on it alone anymore. You will have to introduce new developers to the project and then you have your team mates. And they will be very thankful if you have applied a few team coding techniques.
Also, if you leave the company somebody else has to step into your footprint. This person will be a bit like a future-you but with the big difference that he or she knows nothing about your past which makes everything even harder.
We are always working with some kind of a team even if we don’t realize it. The future versions of yourself are team mates like every other team mate and making their lives easier is a great investment.
Learn more about team coding!
In this blog I will write about my experiences as a software developer in different teams. Many ideas are inspired by discussions, books and blogs and applied and tested in real life. This blog will be like a diary of the most valuable things I have learned. You will find both technical articles and articles about the soft skills a team coder needs. I have many subjects in mind about which I want to write so be excited :) I also hope that I will kick off some interesting discussions with my blog posts so I can also learn from you!
Your feedback is always highly appreciated!