6 ms·

> allows programmers, these very territorial beasts, to have their own little realms they control My 25 years of programming experience says otherwise. The onl

> allows programmers, these very territorial beasts, to have their own little realms they control My 25 years of programming experience says otherwise. The only place where this works is with good(ish) programmers who are assholes and must have their huge, fragile egos stroked or they'll throw a diva fit. I don't hire or work with those people anymore. Neither should you. Joint code ownership produces better code because everyone wrote some of it and nothing is mysterious.

humanrebar 9y ago
> Joint code ownership produces better code because everyone wrote some of it and nothing is mysterious. I don't think it's one or the other. You need people to be able to jump in and contribute and improve things. But you also need responsibility for the code as a body of work. If everyone with commit access owns the code, nobody does. As time goes on and it's a snarl of spaghetti code and slapdash design, it turns out it was nobody's job to make sure that didn't happen.
- nickbauman 9y ago
  What you said is contradictory. Jumping in and contributing and improving things happens when everyone is encouraged to change the code anytime. When individuals get territorial is when it rots because people are afraid to touch that "other person's code."
  - humanrebar 9y ago
    That could happen. But if your technical leaders are rejecting patches for ego reasons, you need to correct that regardless of how you organize your code. Worst case, some people aren't cut out for technical leadership.
Iv 9y ago
I agree that my wording maybe gave a wrong idea about the strength of the "ownership". Code has to be readable and commented and peeking into each other code is welcomed, calling for help or reinforcement on a module is recommended. "Realms" is something that is unenforced and that emerges implicitly. On the other hand, joint code ownership leads to endless discussions about proper whitespace formating, variables naming and accessors. It leads to never-enforced style rules that no one likes nor follows. > I don't hire or work with those people anymore. Neither should you. If you are unable to work with some people by refusing to use a code architecture that would allow you to use them, does that really make you a superior project manager? Don't get me wrong, different projects call for different processes. You don't code a blog framework in PHP the same way you program an embedded medical device. In some cases it is a bad idea to give free reign to individuals. I simply notice that when it comes to abstracting your code, team structure and general project context is often more important than the project's function. In my case (non critical C# project with easily compartimentalizable functions with diverse team members of different skills, different maturity levels and a propensity to argue over minor formatting details) it meant isolated modules communicating through a well-defined API. The alternative would have been to fire half the team and make a nicer code in twice the time. Not what I was hired for.
- meheleventyone 9y ago
  > On the other hand, joint code ownership leads to endless discussions about proper whitespace formating, variables naming and accessors. It leads to never-enforced style rules that no one likes nor follows. Seems less a problem with joint ownership and more a problem with poor leadership.
  - miko1293949 9y ago
    This is mind base
  - WillReplyfFood 9y ago
    Only a broken peasant, reduced to a mere Automaton, garants the quality and innovation- that this company is so proud to produce. Seriously- i hate it when Hackers try to reduce theire co-workers to machines and enforce there personal taste as "programs". If you are unable to deal with humans, to accept unimportant differences, why do you try to define the interfaces for humans on a project.
    - s73ver_ 9y ago
      I think the same thing could be said of those who refuse to follow the coding standards.
    - meheleventyone 9y ago
      The point was if you’re trying to make joint code ownership work through those things you are already doing it wrong. Want everyone to run with their own style? Fine. You need to make the style sensitive parts of the process work. Whether that’s to adopt local style or something more complex. If all you can do is not enforce some poor coding standards then you are defacto not a lead.
- boomlinde 9y ago
  > On the other hand, joint code ownership leads to endless discussions about proper whitespace formating, variables naming and accessors. That is not my experience. Sure, there will be some bikeshedding in the code reviews, but you get rid of most attack surfaces by agreeing on lint/formatting options and just delegating the task to a tool. For me, proper whitespace formatting was whatever gofmt spat out. Later clang-format with the agreed team-wide options and currently pretty-js. The team can instead focus on more important code issues like the overall structure or bugs in the reviews. > It leads to never-enforced style rules that no one likes nor follows. If no one likes, enforces or follows them, you can't really call them rules. If it is the mutual understanding that some style aspects are not relevant, what's the problem keeping it that way? There is no need to let that get in the way of enforcing some aspects of style in order to produce code that anyone in the team can easily work on. > In my case (non critical C# project with easily compartimentalizable functions with diverse team members of different skills, different maturity levels and a propensity to argue over minor formatting details) it meant isolated modules communicating through a well-defined API. IMO one of the best ways to train a new programmer is to have them work closely with more experienced people and with the same level of review scrutiny. I don't know about the project you are working on and its timeline, but in the long term I believe this pays off by turning newbies into good, independent programmers that produce readable and idiomatic code. And no one needs to argue about minor formatting details with the tooling available today. It's a self-imposed waste of time if anything.
nnq 9y ago
People need that feel of "ownership", not based on who made something, that's really bad and lead to "not touching Joe's code, no f way", and probably what you said... But there needs to be a "Joes is responsible for the well functioning of microservices X1, Y2, Z3" - even if there may be 5 other people working on these same and others. Also, people's "fragile" egos can be turned to your adavantage, as a manager or owner, but that is "black magick" and an oath I have sworn not to share its ways anymore ;) ...
- xg15 9y ago
  But there needs to be a "Joes is responsible for the well functioning of microservices X1, Y2, Z3" - even if there may be 5 other people working on these same and others. That implies that Joe has some kind of authority over the 5 other people, I hope. Otherwise that sounds like a "responsibility for blaming only" situation.
wiz21c 9y ago
Could you expand on this : >>> they'll throw a diva fit ? I'm not a native english speaker and although I get the general feeling, I don't get the exact picture this should paint in my mind... (and I bet it should be a funny one)
- colejohnson66 9y ago
  A “diva” is generally used nowadays to mean someone who complains about everything. So a diva fit would be a diva throwing a fit. Basically the adult version of a tantrum.
- mekkkkkk 9y ago
  The word 'diva' originally described headline singers of opera. The "stars" of the opera world. Nowadays the word is used to describe someone who thinks highly of themselves, and think that their own needs or wants is more important than others. "Throwing a fit" is to start a disproportionally angry argument over something. So "throwing a diva fit" is to get mad about something solely because it is not how you'd prefer it to be, regardless of what others think.
shrimpx 9y ago
There's a tension between "everyone writes some of it" and individuals having autonomy to focus and make decisions. If everybody has autonomy in a shared codebase, you end up with a heterogeneous spaghetti of unrelated design decisions and styles overlapping everywhere. To solve this, you normally end up with a hierarchy of authority, where most people have to have their work vetted by seniors. In this process, people lose autonomy and can't fully act on their own vision. The alternative is to think up new architectures and team structures that allow more people more freedom to work.
- onion2k 9y ago
  If everybody has autonomy in a shared codebase, you end up with a heterogeneous spaghetti of unrelated design decisions and styles overlapping everywhere. Being free to do things your own way often means choosing not to do something if it's going to negatively impact other people. Once you realise that you need to think about the way your decisions impact other people you quickly realise that compromising on your choices for the benefit of the wider team results in much better code.
  - speedplane 9y ago
    > Being free to do things your own way often means choosing not to do something if it's going to negatively impact other people. Once you realise that you need to think about the way your decisions impact other people you quickly realise that compromising on your choices for the benefit of the wider team results in much better code. This becomes more and more important as the team grows, as there are more feet that you can step on. Working on a large team is really different than a solo or small team. Large teams are as much about communication, mutual respect, and shared goals than writing good code. Unfortunately, communication takes time and energy, and necessarily slows down the entire process, but it's critical. The Mythical Man Month lays this out nicely. The possible lines of communication in a N person team grows quadratically at N*(N-1), which explains why large teams are often far less efficient on a per-person basis than smaller ones.
  - watwut 9y ago
    The trouble is that in closely cooperating teams where I worked, people who did what you suggest ended up in submissive position against people who just do their thing ignoring others. If I proactive think about others and you don't, you get to work however you like it oftentimes making my work more difficult - while I am more restricted and have harder time to make my ideas reality.
watwut 9y ago
There are some people who are easy to joint code with. But there are many people who are not assholes, but joint owning with them is still something uncomfortable to be avoided. Joint code ownership oftentimes means less clear structures and less predictable code, because neither is able to actually execute coherent vision.
nradov 9y ago
Yes collective code ownership generally produces the best overall outcomes. Individual developers or small agile teams need to be able to work through an entire vertical slice of the application to deliver a complete feature that has actual value to users. When you divide up the work by code module rather than by application functionality then the user's needs stop being the primary focus. But with collective code ownership it's still useful to designate a couple of developers as "stewards" for each major component. They don't own the component, but they take responsibility for training other developers on the internal design, making suggestions on refactoring, and reviewing design proposals and code diffs.

humanrebar 9y ago

> Joint code ownership produces better code because everyone wrote some of it and nothing is mysterious. I don't think it's one or the other. You need people to be able to jump in and contribute and improve things. But you also need responsibility for the code as a body of work. If everyone with commit access owns the code, nobody does. As time goes on and it's a snarl of spaghetti code and slapdash design, it turns out it was nobody's job to make sure that didn't happen.

nickbauman 9y ago
What you said is contradictory. Jumping in and contributing and improving things happens when everyone is encouraged to change the code anytime. When individuals get territorial is when it rots because people are afraid to touch that "other person's code."
- humanrebar 9y ago
  That could happen. But if your technical leaders are rejecting patches for ego reasons, you need to correct that regardless of how you organize your code. Worst case, some people aren't cut out for technical leadership.

Iv 9y ago

I agree that my wording maybe gave a wrong idea about the strength of the "ownership". Code has to be readable and commented and peeking into each other code is welcomed, calling for help or reinforcement on a module is recommended. "Realms" is something that is unenforced and that emerges implicitly. On the other hand, joint code ownership leads to endless discussions about proper whitespace formating, variables naming and accessors. It leads to never-enforced style rules that no one likes nor follows. > I don't hire or work with those people anymore. Neither should you. If you are unable to work with some people by refusing to use a code architecture that would allow you to use them, does that really make you a superior project manager? Don't get me wrong, different projects call for different processes. You don't code a blog framework in PHP the same way you program an embedded medical device. In some cases it is a bad idea to give free reign to individuals. I simply notice that when it comes to abstracting your code, team structure and general project context is often more important than the project's function. In my case (non critical C# project with easily compartimentalizable functions with diverse team members of different skills, different maturity levels and a propensity to argue over minor formatting details) it meant isolated modules communicating through a well-defined API. The alternative would have been to fire half the team and make a nicer code in twice the time. Not what I was hired for.

meheleventyone 9y ago
> On the other hand, joint code ownership leads to endless discussions about proper whitespace formating, variables naming and accessors. It leads to never-enforced style rules that no one likes nor follows. Seems less a problem with joint ownership and more a problem with poor leadership.
- miko1293949 9y ago
  This is mind base
- WillReplyfFood 9y ago
  Only a broken peasant, reduced to a mere Automaton, garants the quality and innovation- that this company is so proud to produce. Seriously- i hate it when Hackers try to reduce theire co-workers to machines and enforce there personal taste as "programs". If you are unable to deal with humans, to accept unimportant differences, why do you try to define the interfaces for humans on a project.
  - s73ver_ 9y ago
    I think the same thing could be said of those who refuse to follow the coding standards.
  - meheleventyone 9y ago
    The point was if you’re trying to make joint code ownership work through those things you are already doing it wrong. Want everyone to run with their own style? Fine. You need to make the style sensitive parts of the process work. Whether that’s to adopt local style or something more complex. If all you can do is not enforce some poor coding standards then you are defacto not a lead.
boomlinde 9y ago
> On the other hand, joint code ownership leads to endless discussions about proper whitespace formating, variables naming and accessors. That is not my experience. Sure, there will be some bikeshedding in the code reviews, but you get rid of most attack surfaces by agreeing on lint/formatting options and just delegating the task to a tool. For me, proper whitespace formatting was whatever gofmt spat out. Later clang-format with the agreed team-wide options and currently pretty-js. The team can instead focus on more important code issues like the overall structure or bugs in the reviews. > It leads to never-enforced style rules that no one likes nor follows. If no one likes, enforces or follows them, you can't really call them rules. If it is the mutual understanding that some style aspects are not relevant, what's the problem keeping it that way? There is no need to let that get in the way of enforcing some aspects of style in order to produce code that anyone in the team can easily work on. > In my case (non critical C# project with easily compartimentalizable functions with diverse team members of different skills, different maturity levels and a propensity to argue over minor formatting details) it meant isolated modules communicating through a well-defined API. IMO one of the best ways to train a new programmer is to have them work closely with more experienced people and with the same level of review scrutiny. I don't know about the project you are working on and its timeline, but in the long term I believe this pays off by turning newbies into good, independent programmers that produce readable and idiomatic code. And no one needs to argue about minor formatting details with the tooling available today. It's a self-imposed waste of time if anything.

nnq 9y ago

People need that feel of "ownership", not based on who made something, that's really bad and lead to "not touching Joe's code, no f way", and probably what you said... But there needs to be a "Joes is responsible for the well functioning of microservices X1, Y2, Z3" - even if there may be 5 other people working on these same and others. Also, people's "fragile" egos can be turned to your adavantage, as a manager or owner, but that is "black magick" and an oath I have sworn not to share its ways anymore ;) ...

xg15 9y ago
But there needs to be a "Joes is responsible for the well functioning of microservices X1, Y2, Z3" - even if there may be 5 other people working on these same and others. That implies that Joe has some kind of authority over the 5 other people, I hope. Otherwise that sounds like a "responsibility for blaming only" situation.

wiz21c 9y ago

Could you expand on this : >>> they'll throw a diva fit ? I'm not a native english speaker and although I get the general feeling, I don't get the exact picture this should paint in my mind... (and I bet it should be a funny one)

colejohnson66 9y ago
A “diva” is generally used nowadays to mean someone who complains about everything. So a diva fit would be a diva throwing a fit. Basically the adult version of a tantrum.
mekkkkkk 9y ago
The word 'diva' originally described headline singers of opera. The "stars" of the opera world. Nowadays the word is used to describe someone who thinks highly of themselves, and think that their own needs or wants is more important than others. "Throwing a fit" is to start a disproportionally angry argument over something. So "throwing a diva fit" is to get mad about something solely because it is not how you'd prefer it to be, regardless of what others think.

shrimpx 9y ago

There's a tension between "everyone writes some of it" and individuals having autonomy to focus and make decisions. If everybody has autonomy in a shared codebase, you end up with a heterogeneous spaghetti of unrelated design decisions and styles overlapping everywhere. To solve this, you normally end up with a hierarchy of authority, where most people have to have their work vetted by seniors. In this process, people lose autonomy and can't fully act on their own vision. The alternative is to think up new architectures and team structures that allow more people more freedom to work.

onion2k 9y ago
If everybody has autonomy in a shared codebase, you end up with a heterogeneous spaghetti of unrelated design decisions and styles overlapping everywhere. Being free to do things your own way often means choosing not to do something if it's going to negatively impact other people. Once you realise that you need to think about the way your decisions impact other people you quickly realise that compromising on your choices for the benefit of the wider team results in much better code.
- speedplane 9y ago
  > Being free to do things your own way often means choosing not to do something if it's going to negatively impact other people. Once you realise that you need to think about the way your decisions impact other people you quickly realise that compromising on your choices for the benefit of the wider team results in much better code. This becomes more and more important as the team grows, as there are more feet that you can step on. Working on a large team is really different than a solo or small team. Large teams are as much about communication, mutual respect, and shared goals than writing good code. Unfortunately, communication takes time and energy, and necessarily slows down the entire process, but it's critical. The Mythical Man Month lays this out nicely. The possible lines of communication in a N person team grows quadratically at N*(N-1), which explains why large teams are often far less efficient on a per-person basis than smaller ones.
- watwut 9y ago
  The trouble is that in closely cooperating teams where I worked, people who did what you suggest ended up in submissive position against people who just do their thing ignoring others. If I proactive think about others and you don't, you get to work however you like it oftentimes making my work more difficult - while I am more restricted and have harder time to make my ideas reality.

watwut 9y ago

There are some people who are easy to joint code with. But there are many people who are not assholes, but joint owning with them is still something uncomfortable to be avoided. Joint code ownership oftentimes means less clear structures and less predictable code, because neither is able to actually execute coherent vision.

nradov 9y ago

Yes collective code ownership generally produces the best overall outcomes. Individual developers or small agile teams need to be able to work through an entire vertical slice of the application to deliver a complete feature that has actual value to users. When you divide up the work by code module rather than by application functionality then the user's needs stop being the primary focus. But with collective code ownership it's still useful to designate a couple of developers as "stewards" for each major component. They don't own the component, but they take responsibility for training other developers on the internal design, making suggestions on refactoring, and reviewing design proposals and code diffs.