Coding Driven Leadership

> Collective Ownership : It’s not about you, its always about the team.

When people say "Collective Ownership", they usually mean no one person is directly responsible for a body of code - and that is supposed to be a good thing. When you walk into a shop with this philosophy and have a question about the code you will find that you usually get the answer "I don't know ask Jake" and then Jake says "I don't know ask Jane", Jane then sends you to Bill who may have touched the relevant code at some point. Basically "Collective Ownership" can result in lack of responsibility and messy code that nobody really understands.

I want to take more aim at this "Collective Code Ownership" myth. The concept overlooks the immense amount of job satisfaction one gets from being responsible for a body of code and feeling like you have some responsibility. Handing out responsibility doesn't remove the need for code reviews or bar others from examining and learning different parts of the code. So called "collective ownership" simply gives low-level engineering management more power by keeping developers weak and replaceable but makes for messy code. It makes for messy code because developers don't take a holistic view of what they are doing they just strive to rapidly complete little tasks that are thrown in front of them that management can understand and use to maintain a feeling of control. In short "yes!", it is about you, your growth, and your job satisfaction. I've worked as a consultant in many code shops - when I walk into a shop and the manager introduces Alice "who does our kernel code", and then Bill who "Manages our API code", and Mike "Who is generally responsible for integrations and works on our front end code with Alice" I generally see more happy developers and less turnover.

I also don't believe very much in Pair Programming. Again, all the research I've read supporting the practice is questionable. I've pair programmed at length and watched others do it. Generally it only works for the most trivial of tasks - which means that why use it at all. I do think superiors get a great deal of satisfaction pairing with their subordinates, I'm not so sure about the other way around.