3 ms·

I am surprised by the reactions. The author is just proposing a workflow where PRs are optional. For many years we worked without PRs at all. It bothers me tha

I am surprised by the reactions. The author is just proposing a workflow where PRs are optional. For many years we worked without PRs at all. It bothers me that it seems like developers no longer do "Continuous Integration" which IMHO is one of the most important software engineering practices. Companies do CI/CD pipelines, but that is not even close to "Continuous Integration" - Maintain a Single Source Repository. - Automate the Build - Make Your Build Self-Testing - Everyone Commits To the Mainline Every Day - Every Commit Should Build the Mainline on an Integration Machine - Fix Broken Builds Immediately - Keep the Build Fast - Test in a Clone of the Production Environment - Make it Easy for Anyone to Get the Latest Executable - Everyone can see what's happening - Automate Deployment More Specifically, most companies don't understand why this is important: "Everyone Commits To the Mainline Every Day". Also, there is too much branching going on.

alkonaut 5y ago
"Everyone commits to the mainline every day" doesn't preclude Pull Requests. It just means "don't use large multi-day pull requests" really. And that's a good idea even though I wouldn't want ALL PR's to be sub 1 day of effort.
da39a3ee 5y ago
> For many years we worked without PRs at all. And that severely reduced the amount of learning-from-others that went on in your company during that era. Discussion in the course of code reviews is the most effective way for less experienced programmers to benefit from their more experienced colleagues. And, of course, even the most experienced programmers continue to learn from their colleagues thoughts.
- corpMaverick 5y ago
  > And that severely reduced the amount of learning-from-others that went on in your company during that era. I was not talking just about my self. I was talking about the whole industry. PRs became popular when github became popular; about 10 years ago.
gocartStatue 5y ago
Love your comment. People seem to have forgotten what "Continuous Integration" stands for. I am amazed to see so much "mandatory CR is good" comments on HN. Well yes, it's fine for open source projects or immature teams working on mature projects without good delivery pipeline.

alkonaut 5y ago

"Everyone commits to the mainline every day" doesn't preclude Pull Requests. It just means "don't use large multi-day pull requests" really. And that's a good idea even though I wouldn't want ALL PR's to be sub 1 day of effort.

da39a3ee 5y ago

> For many years we worked without PRs at all. And that severely reduced the amount of learning-from-others that went on in your company during that era. Discussion in the course of code reviews is the most effective way for less experienced programmers to benefit from their more experienced colleagues. And, of course, even the most experienced programmers continue to learn from their colleagues thoughts.

corpMaverick 5y ago
> And that severely reduced the amount of learning-from-others that went on in your company during that era. I was not talking just about my self. I was talking about the whole industry. PRs became popular when github became popular; about 10 years ago.

gocartStatue 5y ago

Love your comment. People seem to have forgotten what "Continuous Integration" stands for. I am amazed to see so much "mandatory CR is good" comments on HN. Well yes, it's fine for open source projects or immature teams working on mature projects without good delivery pipeline.