5 ms·

I wish I would have read that 5 years ago. I tried to fix poor coding practices with mandatory review steps, and it just slowed down development and didn't fix

I wish I would have read that 5 years ago. I tried to fix poor coding practices with mandatory review steps, and it just slowed down development and didn't fix anything. For example, we often forgot to backport fixes. So I added a question to the PR template: "Does this PR need to be backported?" I thought if people saw that question they would stop and think about it, and wouldn't forget backporting bugfixes. It turns out they just always typed "No". I just added friction and the problem persisted. When people don't care, you can't fix the problem with process, because they'll just mindlessly follow the process and make the same mistakes that the process was supposed to prevent in the first place.

HeyLaughingBoy 4y ago
People won't do any more work than they have to. If you need the PR to be backported, don't ask a question. Say "step 5. Backport this PR" Don't offer an easy out. Then if they don't you can ding them for not following the process. You can fix problems with process, but all that does is set a minimum floor of quality, it doesn't guarantee anything higher than that. In your example, I'd have standards for coding practices, and reviews to be sure that they're met, and merges aren't allowed unless the reviewers all approve.
- avmich 4y ago
  The first thing I write in a coding guideline, "This is a set of suggestions, not hard and fast rules." So in practice it's harder to figure out if the code is good enough from this standpoint. What is working, I think, is to have everybody agreed about 1) what actually needs to be done - a good understanding of details of the project - and 2) how it needs to be done - on high level, and on the low level some variations shouldn't matter too much.
  - HeyLaughingBoy 4y ago
    I prefer a coding standards document that is divided up into hard and fast rules and guidelines and clearly states which is which. Otherwise, reviews can quickly degrade into arguments.
    - avmich 4y ago
      Can you give an example of hard and fast rule regarding coding standards? I'd assume people who learned programming by books - and even those who learned otherwise - wouldn't name variables after rock stars, but something not too obvious?
      - HeyLaughingBoy 4y ago
        Sure. In the codebase for an 8-bit embedded system: recursion is forbidden.
        avmich 4y ago
        Ah :) even tail recursion?
theptip 4y ago
This is a tough problem to solve. One approach I’ve had success with for this kind of “diffuse accountability” problem is to make this a rotating role that one person does. Eg if you have a release per week, have a BuildMaster hat and part of the job is figuring out which things to backport. The hat rotates so people take turns thinking about the thing a lot, instead of everyone having to spend a couple cycles on it. If someone is wearing the hat and messes up then that is a more focused performance problem you can pinpoint and remedy. Of course this doesn’t always work for every problem, just an idea that may work for some instances of this kind.

HeyLaughingBoy 4y ago

People won't do any more work than they have to. If you need the PR to be backported, don't ask a question. Say "step 5. Backport this PR" Don't offer an easy out. Then if they don't you can ding them for not following the process. You can fix problems with process, but all that does is set a minimum floor of quality, it doesn't guarantee anything higher than that. In your example, I'd have standards for coding practices, and reviews to be sure that they're met, and merges aren't allowed unless the reviewers all approve.

avmich 4y ago
The first thing I write in a coding guideline, "This is a set of suggestions, not hard and fast rules." So in practice it's harder to figure out if the code is good enough from this standpoint. What is working, I think, is to have everybody agreed about 1) what actually needs to be done - a good understanding of details of the project - and 2) how it needs to be done - on high level, and on the low level some variations shouldn't matter too much.
- HeyLaughingBoy 4y ago
  I prefer a coding standards document that is divided up into hard and fast rules and guidelines and clearly states which is which. Otherwise, reviews can quickly degrade into arguments.
  - avmich 4y ago
    Can you give an example of hard and fast rule regarding coding standards? I'd assume people who learned programming by books - and even those who learned otherwise - wouldn't name variables after rock stars, but something not too obvious?
    - HeyLaughingBoy 4y ago
      Sure. In the codebase for an 8-bit embedded system: recursion is forbidden.
      - avmich 4y ago
        Ah :) even tail recursion?

theptip 4y ago

This is a tough problem to solve. One approach I’ve had success with for this kind of “diffuse accountability” problem is to make this a rotating role that one person does. Eg if you have a release per week, have a BuildMaster hat and part of the job is figuring out which things to backport. The hat rotates so people take turns thinking about the thing a lot, instead of everyone having to spend a couple cycles on it. If someone is wearing the hat and messes up then that is a more focused performance problem you can pinpoint and remedy. Of course this doesn’t always work for every problem, just an idea that may work for some instances of this kind.