(This is part 3 of 3 in my series of thoughts on The Clean Coder)
The third part of The Clean Coder by Robert C. Martin (Uncle Bob), is about the how professionals realize that they will always be part of a team, and embrace the complexities of team dynamics. He knows the value of being part of a well functioning team, and that he needs to do his part to make it, and keep it, well functioning.
This is a repost from my old blog thecompilerdoesntcare.com and was originally posted in 2017.
You Are Not Alone!
Rarely is software created by a single person – it is almost always created by a team of people including developers, project leads, managers, and customers. Because of this, it is not enough to simply be good at programming, to be a good professional. The professional developer works well with other people. Including non-technical ones!
Ownership
Professionals aren’t possessive of the code they produce, they encourage their teammates to review and question it. Fresh eyes on your code is always good. Even if there is nothing wrong with it, you can still have a good discussion about the choices made and spread out the knowledge of the code base, in case the next person that needs to work with that piece of code isn’t you.
Pair-programming should also be practiced often, and with many different partners. When we are pair-programming, the review is happening as the code is written, and bugs and errors are often caught immediately. It also spreads out the ownership of the code between more people on the team. More people feel at home in larger parts of the code.
Professionals don’t need to prove that they are better than everyone else. They see the value in raising the level of the entire team by working together – something which, in the end, will produce much better software.
Teams
A team is not something that can be created in a day. A team is not just a group of people sitting close to each other.
A group of people starts to become a team, when they have worked together long enough to start forming relationships, have gotten to know each others strengths and weaknesses, when they have learned how to collaborate. This isn’t something that can be forced – it just takes time.
At this point the team has gelled and a gelled team is what you want as customer or as an employer! A gelled team gets things done, everyone on the team has a role, and they complement each other.
Once a team is gelled, they shouldn’t be broken apart. If they finish a project, they should be put on a new project, or at least stay together on the maintenance of that project. It is a waste of very effective resources to split them up.
It takes time to reach this level of effectiveness, and projects should be organized around teams, not the other way around.
Mentoring and Apprenticeship
Uncle Bob is constantly surprised by the low level of CS graduate’s technical skills. Being a fairly recent CS graduate myself, I can only confirm that it is true that CS graduates really aren’t very good developers.
We are taught to program, not develop. Knowing the how a compiler works or the syntax of a programming language is not the same as being able to write quality software.
Never in my time at university has anyone looked at the quality of my code and given me feedback on it, so that I could improve it.
Just like doctors need to go through residency before they are allowed to practice medicine unsupervised, so do green developers need mentorship before they can a level of proficiency were they can take ownership of a project.
They should get constant feedback from senior developers – professionals who know that by helping and teaching their juniors, they will improve their own skills.
Uncle Bob says that professionals will always seek out mentors, people that are more skilled in the areas where they feel they need to improve. A professional can have several mentors with different skills, while simultaneously have their own mentees, that they help improve.
No matter your level of seniority there will always be someone better than you that you can learn from, but also someone that you can teach something. Professionals know this and take part in this ecosystem.
Conclusion
“Teams are harder to build than projects” – Uncle Bob.
This certainly is something to think about as a manager. Forming and disbanding teams around single projects is a waste of effort, and will ultimately result in lower quality projects and unsatisfied employees. A gelled team is like a family, and no one wants their family broken apart.
A professional wants to work well with his team, but his employer also has a responsibility to create the framework for well functioning, long running teams.
Professionals teach their juniors and seek out new knowledge from their peers and seniors. They know that they are never done learning from others, and welcome colleagues to learn from them.