In a software dev team, what habits make a good team player?

For example, I have learnt that you don't modify another person's code if you see something wrong with it but don't have authority to do so (regardless of how bad the flaw is), do one task at a time and don't get sidetracked into fixing something else which you weren't even asked to do, anyway.

Along these lines, are there any rules to follow? Apart from comments etc.

+1  A: 

Do all the work yourself and then let all the others take the glory for it. If it fails of course you solely are to blame. I am joking of course, but it happens a lot more often than you might think.

Seriously you can get some tips from Lifehacker Blog.

+4  A: 
  1. When checking in solutions to problems and features, there should always be a ticket number associated with the commit. If you don't have a ticket to go along with your submission you're working on something that wasn't scheduled, and might not be properly reviewed.

  2. If you see a serious problem with a team members code, in terms of functionality write a unit test, file a bug and attached the unit test to the bug report (don't check in a unit test that is failing). It's up to your lead to decide when the bug needs to be addressed.

  3. If you see a design issue with a team members code, there should be no issue mentioning it to either the team member or your lead. Be polite but people should always be open to suggestions and accept of advice (they might know it's badly done just didn't have the time to fix it). They/you file a bug/re-factor ticket and wait for it to be schedule.

Ken Struys
Yea, raising everything with the team lead seems like the right thing to do.
+4  A: 

you don't modify another person's code if you see something wrong with it but don't have authority to do so (regardless of how bad the flaw is)

That really depends on code ownership policy you agreed about. At my team we all are the owners of code no matter who initially wrote it. That gives every team member right to fix/modify/improve it. Of course if he doesn't feel he has authority to do so he can always discuss it with the original author.

As you wrote it's not always good to directly jump into a problem you found. However, it should at least go to your ticket tracking tool. Bad code has to be fixed. It'll come back to you some day.

I think most important thing in a dev team is to communicate often. Talk about design and ideas. Always improve.

Also, communicate well in your code. As the code is more often read than written it's really important to write clean code. Short, well named methods which are self-explanatory (no comments needed). You can read more about it in "Clean Code" by Robert C. Martin (


In my team, everyone is encouraged to read and modify anything. We track changes in Microsoft Team Foundation Server (a source code control system) so all modifications are traceable back to the developer who made them.

Sometimes there are "fights" or "debates" among developers about the merits of the change, but in every single case I have witnessed, the best approach wins and is what we ship.

My advice: The first few times you should "suggest" a code change to the original programmer or to the team lead. If your suggestions have merit, in time you will gain the trust of your colleagues and you will be allowed to make changes at your own discretion. And remember to be nice, because someday someone will be changing your code.

We also use TFS.
+1  A: 

My number one rule is to always assume, and act as if, any undiagnosed bug is my fault until proven otherwise.

+1  A: 
  1. Adopt the team rules. If you feel a rule is bad/wrong, discuss it with the other team members to change it. But as long as it exists, apply it.
  2. Be verbose in your commit messages.
  3. Push meaningful changes. Not too rarely. Not too often.
  4. Don't cc: your boss/manager/wife when discussing errors in your colleagues' code.
  5. Always be polite. Respect other team members.
  6. Be critic in a constructive way. Don't judge.
  7. Know your team members. Have a couple of beer with them.
  8. Don't close tickets that other people have assigned to you. Mark them as "solved", asking confirmation from the person who assigned the ticket to you.
  9. If you have a doubt, ask your team.
  10. Organize periodical internal meetings within the team.
Roberto Aloi

Don't get too attached to your work and try to help your teammates do the same - if you fall in love with your solution you will have blinders on when a better one is found. Debate, but don't take any of it personally. The goal is to produce a quality final deliverable, not enhance your ego.