5 ms·

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

by 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.

by Iv 9y ago

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.