
Coding Driven Leadership - shyamvala
https://www.shyamvala.com/blog/coding-driven-leadership
======
externalreality
> 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.

