But what should you do when one of guidelines are not part of your ‘believes’? For example adding a comment to each public class/interface or method.
There are developers that will NOT respect the guideline, will fight for it until the end of the world and will say NO – ‘I will never respect this guideline because is bullshit’.
This is an extremist approach and I think that this approach is not better than the one when you accept everything. In this cases the most important thing is communication. You need to understand why that guideline exist (it came from the team, architect, PM, company or client).
You should explain why the guideline is not good, but be aware, one time is not enough, because you may have people that use that guideline for 10-15 years and for them is a religion. Small steps are the best option in this cases.
But if none of the solutions works and all the team say that the guideline is good then you have two options:
Respect their decision, write code using their guideline (you didn’t lost the fight, but you need more mitigation – time is your best friend)
Leave the team and the project (the extremist developer : - ) )
The worst thing that you can do is to write code using your own guidelines. Even if you don’t like the guidelines, you should not ignore their guidelines. If you have 1 million lines of code written using a specific guideline, starting to write a part of the code with your own guidelines is a big mistake.
It is okay to write a small PoC where you can show them why that guideline is wrong, without making a push to the main repository.
In conclusion we could say that being a new member in a team can be hard, but you need to be a team player and accept other believes also.
0 comments:
Post a Comment