Teamwork for developers

Quite often in the web industry a single programmer will work alone on a project for the duration of that project, especially in smaller web development companies. This is all well and fine; most developers are happy to work alone and get things done.

However, there will come a time when developers will need to work on larger projects which involve other developers, all working cooperatively to finish the project in a reasonable amount of time. Quite often when this happens there is a lot of friction among the developers as style, technique, knowledge and work ethics clash, resulting in reduced productivity and a generally lower sense of morale.

This blog post is just a collection of tips to help developers who are working on a team project (or are going to be soon) and is meant as a set of guidelines or thought points to help prompt a better team environment.

I'll try not to be ranty and self-righteous. No promises.

1. All team members are created equal.

 

Overstating your own importance in on a team project can quickly lead to issues with the other developers, equally so with understating other developers contributions. While there may be a technical lead on the project (the go-to guy for large technical decisions), they do not, and should not, overshadow the other developers. You're all in it together and as such should be seen equal contributors.

Fostering an environment of inequality only results in resentment in all directions which only serves to reduce the teams productivity.

Keep in mind, this is even more important when there is a large skill disparity between team members because the lesser skilled developers will have the confidence to bring ideas and changes to the team which may actually be valuable.

2. Communication

 

Communication is vital. This should not come as a surprise to anyone working in any kind of team environment, but it's critical to be able to know what to communicate and how to do it.

Decisions which impact the team should always be communicated to the entire team before the decision is made. This gives each member the chance to raise concerns and iron out any potential issues. Decisions like "I'm going to use C# 4.5" or "Unit testing ahoy!" need discussion before the decision. Don't assume you know best for your team, even if you actually do.

If you spot something that another team member has coded and it's just not right then I believe that there is a socially acceptable way to make everyone aware of the problem and (hopefully) not make the same error in the future:

• Make sure you understand the code and it's requirements
• Work out what the 'right' way should be, understand WHY it's the right way with technical justifications (no "just cause" excuses)
• Draft an email only to the team developers (do not copy in producers, management, etc) with an objective explanation of the problem and the solution. Do not personalise the offending code writer, just present it as a better way to write that piece of code.
• Fix the code yourself. (This is optional, and may not even be possible in some cases, but is recommended)

 

Positive feedback between team members can form a loop of improvement where all team members learn and get better over time with discussion and implementation of better and better ideas. Negative feedback loops are possible, and are to be avoided at all costs for obvious reasons.

3. Play to your strengths, but have an understudy

 

Naturally, certain team members will be stronger in certain areas than other team members. It happens all the time and is the sum result of the individual experience. So by all means let people do what they're good at, but not to the extent where they are the only thing that knows what's going on with that particular area. There should always be another team member who understands enough about the area that they can pick up the pieces in the event of the primary team member being uncontactable. Give some smaller tasks in that area to the 'understudy' so that familiarisation is maintained, as we all know, you only really learn something by doing it.

4. Common sense in a team environment

 

Common sense in a team environment comes down to not blocking the teams progress. Don't check in broken code and don't unneccessarily refactor other peoples code away without first doing your due diligence (understand the code, talk to the team member responsible to understand the context).

If you cause another developer on your team to not be able to work then at the very least you should feel bad, but ideally you will do everything in your means to get the other developer up and running as quick as possible. It's your responsibility for stopping their work therefore it's your responsibility to get them running again. Flippant responses such as "Just install X, then Y" or "Oh you're doing it wrong" are unacceptable.

5. There's no I in Team (yes I really did just say that)

 

If you're working on a project with a team of developers then you should understand that you should function as a team. If one developer is struggling and it's coming up to 5pm, offer to help out, sit with them and assist in diagnosis and resolution. Leaving your team mates because 5:01pm just rolled around is generally unacceptable and will only increase tension among team members because you appear unhelpful and unsupportive of the team. If you do that, don't be surprised if they leave you behind when you're having problems later on down the line.

In essence, leave no man behind.

6. Technical no-no's

 

• Don't do partial checkins
• If there are unit tests in your project, run them all before checking in. Do not break the build.
• Don't change foundational technology or structure without discussion (communication!)
• Don't add technological requirements to the project without discussion
• Anything which blocks other developers. Nothing you do should ever stop other developers from working.

 

7. Don't get protective.

 

Don't get protective over code you write. Once you write code and check it in to source control, it's no longer 'your' code, it's the teams. Any team member has the right to change any of the teams code. If another developer changes it then it was (probably) for a reason. You should look at the changes and understand them before questioning why the code was changed, and under NO circumstances should you arbitrarily change it back without the aforementioned understanding.

Protecting an idea or technique is okay, provided that there are demonstratable positive benefits.

 

In conclusion, think of the team, don't trip anyone else up, don't make anyones life difficult, leave no man behind.