This is the twelfth article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the twelfth chapter.
Most software is created by teams. Teams are most effective when the team members collaborate professionally. It's unprofessional to be a loner or a recluse on a team.
Programmers versus people
In general, we, programmers, enjoy the mild sensory deprivation and cocoon-like immersion of focus. We are happiest when we are alone in a room for hours deeply focussing on some really interesting problem.
Programmers versus employers
It's good to be passionate about what we do. But it's also good to keep your eye on the goals of the people who pay you.
The first responsibility of the professional programmer is to meet the needs of his or her employer. That means collaborating with your managers, business analysts, testers, and other team members to deeply understand the business goals. This doesn't mean you have to become a business work. It does mean that you need to understand why you are writing the code you are writing, and how the business that employs you will benefit from it.
The worst thing a professional programmer can do is to blissfully bury himself in a tomb of technology while the business crashes and burns around him. Your job is to keep the business afloat!
So, professional programmers take the time to understand the business. They talk to users about the software they're using. They talk to sales and marketing people about the problems and issues they have. They talk to their managers to understand the short-and long-term goals of the team.
Programmers versus programmers
Programmers often have difficulty working closely with other programmers. This leads to some really terrible problems.
Owned code
One of the worst symptoms of a dysfunctional team is when each programmer builds a wall around his code and refuses to let other programmers touch it. This is a recipe for disaster.
Collective ownership
I prefer teams in which any team member can check out any module and make any changes they think are appropriate. I want the team to own the code, not the individuals.
Professional developers don't prevent others from working in the code. Rather, they work with each other on as much of the system as they can. They learn from each other by working with each other on other parts of the system.
Pairing
Many programmers dislike the idea of pair-programming. I find this odd since most programmers will pair in emergencies. Why? Because it is clearly the most efficient way to solve the problem.
Professionals also pair because it is the best way to share knowledge with each other. Professionals don't create knowledge silos. Rather, they learn the different parts of the system and business by pairing with each other.
Professionals pair because it is the best way to review code. No system should consist of code that hasn't been reviewed by other programmers.
Professionals work together. You can't work together while you are sitting in corners wearing headphones. So I want you sitting around tables facing each other. I want you to be able to smell each other's fear. I want you to be able to overhear someone's frustrated mutterings. I want serendipitous communication, both verbal and body language. I want you communicating as a unit.
There are times when working alone is the right thing to do. There are times when you simply need to think long and hard about a problem. There are times when the task is so trivial that it would be a waste to have another person working with you. But, in general, it is best to collaborate closely with others and to pair with them a large fraction of the time.
Conclusion
Perhaps we didn't get into programming to work with people. Tough luck for us. Programming is all about working with people. We need to work with our business, and we need to work with each other.
Top comments (0)