Hi,
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.
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.
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.
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.
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.
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 (http://www.goodreads.com/book/show/3735293-clean-code).
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.
My number one rule is to always assume, and act as if, any undiagnosed bug is my fault until proven otherwise.
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.