3 ms·
I feel their "responsibility" and "trust" argument is maybe a little oversold here, but their final paragraph is right on the money. I would argue a better tit
by keithnz 5y ago
I feel their "responsibility" and "trust" argument is maybe a little oversold here, but their final paragraph is right on the money.
I would argue a better title is "No rules/process by default". Which doesn't mean you go wild, having a strategy to develop software is very important, but strategies need to be customized. It means you apply just enough and constantly adapt so you have just enough of whatever you need to make sure development works smoothly. People will say PRs improve communication, can help prevent problems, help understand what changes are going into the code base etc, but all of those things can be done in many different ways, and depending on the group of people, there can be more effective ways of achieving that. So adopt what you need ( which may be PRs, or some variation ). But whatever you do, don't go overboard with justification.
The dangers with overselling and defending your justification for doing or not doing something can be a problem. It also can mean you don't adapt quickly to change. By overly emphasizing your approach being about "responsibility" and "trust" you kind of make out that PRs are about a lack of trust and responsibility, which is incorrect and may prevent you from adapting because you have misattributed a quality to a practice/process. This often happens when people go from A (problematic) -> B ( much better). They attribute too much weight to what makes B better than A when they may need to change those things to go to C (even better). In my 40 odd years of observing software development, this is really common, especially for many devs with around 5-10 years experience (including myself). You find much better ways of doing things, and you start becoming advocates for those things. In reality, you always need to be adapting and questioning and always deconstructing and reconstructing your strategies about how to do software.