3 ms·

One way I've seen this enforced is this: Have your "best" devs, the people who put out 2x the amount of solid, testable, well documented code as anyone else, yo

One way I've seen this enforced is this: Have your "best" devs, the people who put out 2x the amount of solid, testable, well documented code as anyone else, you know those that carry the sprint, spend half their time reviewing. Your overall sprint velocity may go down a bit, but your code quality will go up. There's a magic to slowing things down, too - require reviews on every change, require tests to run and pass, run UI tests on each PR. Let people discuss good and bad code they see. Turn every little thing people mention, (like "man, this view is difficult to reason about", "the entire xyz class is a mess", "does anyone know why we do X here?") into a Refactor issue, discuss it, plan it, do it. You can do this during a big feature sprint, you dont need to wait until your product is done (then its too late). Refactor, let people say "yes this issue isnt high prio, but its important to me". Embrace when people want to make code better.

mjr00 3y ago
> One way I've seen this enforced is this: Have your "best" devs, the people who put out 2x the amount of solid, testable, well documented code as anyone else, you know those that carry the sprint, spend half their time reviewing. Your overall sprint velocity may go down a bit, but your code quality will go up. Problem with this is your best devs will soon become your best former devs. Becoming a "mandatory reviewer" sucks. Especially at scale. You're a bottleneck, you get pressured by other devs and occasionally management to let code that you don't like through, and if things go wrong you get assigned at least partial blame for not catching it during the review process. I'm speaking from a background of seeing this implemented at a major AWS service with designated "component owners", who were 1-3 developers with a final (and mandatory) review for all code merged into subcomponents. This was for a service with 400+ developers working on it. > There's a magic to slowing things down, too - require reviews on every change, require tests to run and pass, run UI tests on each PR. Let people discuss good and bad code they see. Yeah this is the way to do it. Automate everything. Unfortunately there's no real "good code" vs "bad code" easy metric, but you should at least have automated testing, linting, compiling, etc to ensure people aren't merging total garbage to shared branches.
- bluGill 3y ago
  There are many easy to automate good code vs bad code things, and you should do that. Turn on all compiler warnings and refuse code with even one for example. Problem is this type of thing isn't sufficient. (You should write your own checks for common problems in your project that could not apply to generic compilers as well )
deleted 3y ago
[deleted]
rr808 3y ago
> you know those that carry the sprint, spend half their time reviewing Sounds like a good idea, but no one wants to do this. People would rather quit.
- lionkor 3y ago
  not sure I'd want those people on my team anyways in that case, as the shared vision should be good code, regardless of who wrote it
  - TeMPOraL 3y ago
    It's not about who owns the code. It's about writing code. Your star performers, those "people who put out 2x the amount of solid, testable, well documented code as anyone else", are likely this effective because they like the coding part. Unless they also love reviewing someone else's code, making them spend 50% time on reviews means taking away most of the nice parts of their work. Assuming they're not robots, expect motivation to suffer - and with it, the quality their future output.
- nightpool 3y ago
  Your experiences are not universal. Just because you hate doing code review doesn't mean everybody does
  - wnolens 3y ago
    They'll burn out because that ask for 50% code review time is often 100 + 50% time. In the playoffs you don't tell your star player to stop shooting and pass more. In my experience, software projects are always lead to accomplish a goal that is out of reach unless the stars bust their ass.
    - nightpool 3y ago
      "In the playoffs you don't tell your star player to stop shooting and pass more" yes, you absolutely do? if the players are making their shots but having a hard time getting open or dealing with defenders then more passing can definitely be the right solution. If your company isn't budgeting/estimating development effort appropriately, then it's going to affect a lot more things then just code reviews: writing good planning documents, adding tests, Q&A, fixing bugs, design polish, small touches, etc. are all going to suffer if the organization is broken in this way.
wredue 3y ago
The problem here is that senior devs are not immune to being hypester developers, and if you let a small group have the final say, there’s a non-zero chance you’re going to end up listening to whatever’s the current hype on medium, and your code will end up even worse.

mjr00 3y ago

> One way I've seen this enforced is this: Have your "best" devs, the people who put out 2x the amount of solid, testable, well documented code as anyone else, you know those that carry the sprint, spend half their time reviewing. Your overall sprint velocity may go down a bit, but your code quality will go up. Problem with this is your best devs will soon become your best former devs. Becoming a "mandatory reviewer" sucks. Especially at scale. You're a bottleneck, you get pressured by other devs and occasionally management to let code that you don't like through, and if things go wrong you get assigned at least partial blame for not catching it during the review process. I'm speaking from a background of seeing this implemented at a major AWS service with designated "component owners", who were 1-3 developers with a final (and mandatory) review for all code merged into subcomponents. This was for a service with 400+ developers working on it. > There's a magic to slowing things down, too - require reviews on every change, require tests to run and pass, run UI tests on each PR. Let people discuss good and bad code they see. Yeah this is the way to do it. Automate everything. Unfortunately there's no real "good code" vs "bad code" easy metric, but you should at least have automated testing, linting, compiling, etc to ensure people aren't merging total garbage to shared branches.

bluGill 3y ago
There are many easy to automate good code vs bad code things, and you should do that. Turn on all compiler warnings and refuse code with even one for example. Problem is this type of thing isn't sufficient. (You should write your own checks for common problems in your project that could not apply to generic compilers as well )

deleted 3y ago

[deleted]

rr808 3y ago

> you know those that carry the sprint, spend half their time reviewing Sounds like a good idea, but no one wants to do this. People would rather quit.

lionkor 3y ago
not sure I'd want those people on my team anyways in that case, as the shared vision should be good code, regardless of who wrote it
- TeMPOraL 3y ago
  It's not about who owns the code. It's about writing code. Your star performers, those "people who put out 2x the amount of solid, testable, well documented code as anyone else", are likely this effective because they like the coding part. Unless they also love reviewing someone else's code, making them spend 50% time on reviews means taking away most of the nice parts of their work. Assuming they're not robots, expect motivation to suffer - and with it, the quality their future output.
nightpool 3y ago
Your experiences are not universal. Just because you hate doing code review doesn't mean everybody does
- wnolens 3y ago
  They'll burn out because that ask for 50% code review time is often 100 + 50% time. In the playoffs you don't tell your star player to stop shooting and pass more. In my experience, software projects are always lead to accomplish a goal that is out of reach unless the stars bust their ass.
  - nightpool 3y ago
    "In the playoffs you don't tell your star player to stop shooting and pass more" yes, you absolutely do? if the players are making their shots but having a hard time getting open or dealing with defenders then more passing can definitely be the right solution. If your company isn't budgeting/estimating development effort appropriately, then it's going to affect a lot more things then just code reviews: writing good planning documents, adding tests, Q&A, fixing bugs, design polish, small touches, etc. are all going to suffer if the organization is broken in this way.

wredue 3y ago

The problem here is that senior devs are not immune to being hypester developers, and if you let a small group have the final say, there’s a non-zero chance you’re going to end up listening to whatever’s the current hype on medium, and your code will end up even worse.