Quote:Original post by Shannon Barber
Another thing is not to press them too hard to develop code your way. People can be much more productive working the way they like to.
In general you are right. But if I am working in a team, I expect some rules that every one has to follow:
- comments to every method (just what the method is doing, so that I can use it)
- names of variables and constant should represent the meaning (and not names like a, b, c, a1, a2, a3)
- no uncommented magic numbers or better no magic numbers at all
- sticking to the technical specification and not using your own
- working on the tasks you agreed to work on
With those I would be already pretty lucky.
Quote:Original post by Shannon Barber
Build prototype/research builds is not a horrible idea either. We routinely do this to experiment with new things. What's important is that he integrates the fruits of that work into the main project. Particularily if he is not accustom to using source control, or not a decent source control tool like subversion, then creating seperate projects to try things could be a good habit he learned in that environment. Give him time to change. Some time later on show him how to make use of the source control tool to create a sandbox branch and how to use the diff to revert changes etc...
I also agree that research builds are a good thing. But in my case my co-worker DID already research on the feature I asked him to implement into the main project. But he was working the whole time on another feature what was absolutely not his task.
Beside that he was shown before how to use our source control tool.
All in all it would be not that bad if he would work on the task we need at the moment and not searching on his own for tasks that seems interesting to him and what we might need in 6 months. Fact is that he's not getting his work done he was assigned to (and which he agreed to).
