Today I’ve heard yet another story about that bad project manager who was enjoying micro-management in an aspect of naming conventions. He was requiring to start interface names with I letter, he was pushing some database rules for fields naming, foreign keys naming, etc.
And developers didn’t like what he do. I think it is mostly because each developer has his own style, preferences, sensation of reasonabe and beautiful. Common code style is rather good, but there is probably some kind of competition between technically-savvy managers and developers.
But what did Rails offered to both project managers and developers? Common naming conventions. Reasonable naming conventions that simplify life, if you use them. If you don’t use them, you should do something that is not directly related to a problem you should focus on. Now project manager could save his/her time and nerves and developers could stop competing with him/her. It’s a win-win situation, I suppose.
One of my friends asked me yesterday via IM: “What if I want to let Rails path to controllers be CamelCase?” I said “What is the reason for you to want it?” He said “BecauseCustomerWantsSo”.
Most of developers are opposing micro-management, and they have reasons. But I’m rather against blindly opposing micro-management. It’s important to realize that micro-management efforts could differ.
My daily activities in Railsware include technical leadership tasks, just like code review. I review every important commit done, at least briefly. And I supply our developers with tasks/advices about how they should improve their code to make it better, easily readable, manageable, testable, etc. While sometimes I could reasonably expect counteraction to such kind of management, I experience it quite rarely. I strongly believe that this kind of “mentorship” leads us to a better quality. As far as I can understand, this way our developers could benefit by a) resulting in a cleaner and better own code b) learning some patterns they didn’t knew before c) having less time spent on testing and debugging.
Actually, what’s bad with micro-management? I have a supposition that the most bad thing with it is that manager is using a power of his/her position to press on subordinates. This sounds reasonable, at least for me. I should take it into account. I’m going to introduce something like cross-developer/cross-project code review sessions within our team.
Happy hacking!
