News for hackers. Stuff that matters.
Re:Why are process gates the hellish spawn of evil you shoul... by newaccount74 on Wednesday October 19, 2022 @03:00PM (#33266448)
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.

Re:Why are process gates the hellish spawn of evil you shoul... by HeyLaughingBoy on Wednesday October 19, 2022 @05:14PM (#33268016)
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.

Re:Why are process gates the hellish spawn of evil you shoul... by avmich on Wednesday October 19, 2022 @05:24PM (#33268115)
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.

Re:Why are process gates the hellish spawn of evil you shoul... by HeyLaughingBoy on Wednesday October 19, 2022 @05:30PM (#33268164)
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.
Re:Why are process gates the hellish spawn of evil you shoul... by avmich on Wednesday October 19, 2022 @06:08PM (#33268483)
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?
Re:Why are process gates the hellish spawn of evil you shoul... by HeyLaughingBoy on Wednesday October 19, 2022 @10:04PM (#33270037)
Sure. In the codebase for an 8-bit embedded system: recursion is forbidden.
Re:Why are process gates the hellish spawn of evil you shoul... by avmich on Wednesday October 19, 2022 @10:14PM (#33270092)
Ah :) even tail recursion?
Re:Why are process gates the hellish spawn of evil you shoul... by theptip on Wednesday October 19, 2022 @06:09PM (#33268496)
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.