4 ms·

> you acknowledge that you hold a minority opinion An opinion being minority has no reflection on whether or not it is correct. See hand washing in the medical

by hmeh 3y ago

> you acknowledge that you hold a minority opinion An opinion being minority has no reflection on whether or not it is correct. See hand washing in the medical profession before it was understood, or batch sizes in the automobile industry before Toyota ate the west's lunch. > And I find it dishonest to phrase that as "The psychology portion isn't subjective". You can find it dishonest if you wish, but I'm trying to point to a body of knowledge I can't adequately convey in an article or a hackernews comment. I'm not trying to pull one over on you, I promise. As I said in another response, this is a design decision. Most design decisions are based on first principles, a-priori knowledge, expertise, a wide range of studies and observations over time, etc. If a person can't write down (convincingly) all of the tacit knowledge required to make the same decision, they are not being dishonest. I'll say it this way: We made this decision based on objective factors. I do not expect everyone to be able to see our decision or our reasons in the same objective light and I'm not going to try to convince someone that doesn't. But telling me it's purely subjective is gaslighting, and impugning my integrity over it is just rude. > You'd be surprised. No, I wouldn't. I would be surprised to see it on our team, or any other well-disciplined team. This article is a tiny (and frankly pedestrian) part of our overall development process. I'm sure you'd disagree with just about everything else that we do as well, and that's OK as well. > Oh, really? Do you have an example? Sure: mail package version is decreased from 2.8.0 to 2.7.1 This happened when we were forced to pin to an older version of the mail gem because of a regression in 2.8.0. Note that the scenario you described: "(1.1.2 can be released after 1.2.0, yes, but that's not a decrease even if something was backported)" isn't relevant to our practice. We don't maintain multiple major/minor versions at one time of any of our packages. If we did, they would be on separate branches as the version number can only exist in one place (the gemspec) and the same exact rules would apply. That is, it wouldn't be a version decrease, it would be an increase from 1.1.1 to 1.1.2 on the 1.1 branch.

knorker 3y ago
> An opinion being minority has no reflection on whether or not it is correct. I entirely agree. But if you find yourself in the minority, then I encourage you to objectively consider what's more likely: Are you right, or are most other people right? Or maybe there is no right and wrong (aside from being consistent)? Sometimes the minority is right. But usually that's not the case. > See hand washing in the medical profession before it was understood. Ooookayy. I would not compare any technical decision in this space to that. A bit grandiose. More traditionally one says "10k flies can't be wrong: poop must taste great!". > If a person can't write down (convincingly) all of the tacit knowledge required to make the same decision, they are not being dishonest. I agree. As long as they don't claim otherwise. I'm sure you're an expert, with lots of experience. Experience that creates a good judgement, and good intuition. But that also describes the majority of the experts, who, turns out, disagree with you. >> You'd be surprised. > No, I wouldn't. Then... you disagree with the "of course", you said. > mail package version is decreased from 2.8.0 to 2.7.1 What does that mean? A dependency version decrease? If this is a commit on the mail package itself, then what does it mean? I'm going to assume that's a dependency version change. "10k flies can't be wrong" is one thing, but "the majority expert opinion in my field is wrong"... is almost always wrong. Most theories are wrong, even by experts. It's not even embarrassing to be wrong. But to defend your policy on objective grounds, is like asserting Ruby should be used for all programming. It's Not Even Wrong. https://en.wikipedia.org/wiki/Not_even_wrong https://en.wikipedia.org/wiki/Not_even_wrong
- hmeh 3y ago
  > Ooookayy. I would not compare any technical decision in this space to that. A bit grandiose. One has to be able to understand an analogy for the point the person is trying to make -- it's not an equivalence. Obviously most software issues don't rise to the level of life or death. That said, let's try a few others: - Waterfall - DCOM - CORBA - Web Services - Microservices (as implemented by web developers -- per-entity web api to web api to web api cascading failure) - Monorepos (not globally, with sufficient support these can work) - Devs shouldn't write tests - Fat Model, Skinny Controller - Write tests. Not too many. Mostly integration. - Single Page Apps for all - SCRUM - Story points Most, if not all of those were embraced by "most experts", but are now demonstrated problematic or at least are knowably wrong from fundamental design principles. Note that statistically speaking, "most experts" are, at best, early majority. There aren't very many in the Innovators and Early Adopters, and crossing that chasm is rare, and hard. We have a history in our community of intransigence, repeating mistakes, and expert beginners being the most outspoken portion of our community. They are the ones that have the most to gain by blogging and self-promotion and there are significantly more of them than people who may have different things to say for good reason. Note that right now, I am speaking generally, not debating a commit message approach. > Then... you disagree with the "of course", you said. No, the "of course" was: of course no one I work with would make that mistake (more than once). It would be an extremely beginner mistake, and we would have failed as coaches on our team to not pair with a person long enough to help them understand how to write proper commit messages. > I'm going to assume that's a dependency version change. Yes, it's a pinned version for that dependency. You don't have any context on that particular commit, so it's not surprising that it's ambiguous. > Most theories are wrong, even by experts. It's not even embarrassing to be wrong. Indeed! I have been wrong many times in my career. Hell, I invented the "auto-mocking container" which, in hind sight was so stupid (and btw, my colleague you referenced warned me about it at the time -- he's always been a few steps ahead) that I never should have popularized it. Thankfully, it fell into the past along with IoC containers (for the most part). I have plenty of other stories about being wrong as well, and as I've said elsewhere, if we find a better way to write commit messages we will do that. For now, from our analysis, the way we do it is best for us -- observably (I'll say that, rather than objectively, though I do believe we were as objective as possible in our analysis). Thanks for the discussion.

by hmeh 3y ago

knorker 3y ago

> An opinion being minority has no reflection on whether or not it is correct. I entirely agree. But if you find yourself in the minority, then I encourage you to objectively consider what's more likely: Are you right, or are most other people right? Or maybe there is no right and wrong (aside from being consistent)? Sometimes the minority is right. But usually that's not the case. > See hand washing in the medical profession before it was understood. Ooookayy. I would not compare any technical decision in this space to that. A bit grandiose. More traditionally one says "10k flies can't be wrong: poop must taste great!". > If a person can't write down (convincingly) all of the tacit knowledge required to make the same decision, they are not being dishonest. I agree. As long as they don't claim otherwise. I'm sure you're an expert, with lots of experience. Experience that creates a good judgement, and good intuition. But that also describes the majority of the experts, who, turns out, disagree with you. >> You'd be surprised. > No, I wouldn't. Then... you disagree with the "of course", you said. > mail package version is decreased from 2.8.0 to 2.7.1 What does that mean? A dependency version decrease? If this is a commit on the mail package itself, then what does it mean? I'm going to assume that's a dependency version change. "10k flies can't be wrong" is one thing, but "the majority expert opinion in my field is wrong"... is almost always wrong. Most theories are wrong, even by experts. It's not even embarrassing to be wrong. But to defend your policy on objective grounds, is like asserting Ruby should be used for all programming. It's Not Even Wrong. https://en.wikipedia.org/wiki/Not_even_wrong https://en.wikipedia.org/wiki/Not_even_wrong

hmeh 3y ago
> Ooookayy. I would not compare any technical decision in this space to that. A bit grandiose. One has to be able to understand an analogy for the point the person is trying to make -- it's not an equivalence. Obviously most software issues don't rise to the level of life or death. That said, let's try a few others: - Waterfall - DCOM - CORBA - Web Services - Microservices (as implemented by web developers -- per-entity web api to web api to web api cascading failure) - Monorepos (not globally, with sufficient support these can work) - Devs shouldn't write tests - Fat Model, Skinny Controller - Write tests. Not too many. Mostly integration. - Single Page Apps for all - SCRUM - Story points Most, if not all of those were embraced by "most experts", but are now demonstrated problematic or at least are knowably wrong from fundamental design principles. Note that statistically speaking, "most experts" are, at best, early majority. There aren't very many in the Innovators and Early Adopters, and crossing that chasm is rare, and hard. We have a history in our community of intransigence, repeating mistakes, and expert beginners being the most outspoken portion of our community. They are the ones that have the most to gain by blogging and self-promotion and there are significantly more of them than people who may have different things to say for good reason. Note that right now, I am speaking generally, not debating a commit message approach. > Then... you disagree with the "of course", you said. No, the "of course" was: of course no one I work with would make that mistake (more than once). It would be an extremely beginner mistake, and we would have failed as coaches on our team to not pair with a person long enough to help them understand how to write proper commit messages. > I'm going to assume that's a dependency version change. Yes, it's a pinned version for that dependency. You don't have any context on that particular commit, so it's not surprising that it's ambiguous. > Most theories are wrong, even by experts. It's not even embarrassing to be wrong. Indeed! I have been wrong many times in my career. Hell, I invented the "auto-mocking container" which, in hind sight was so stupid (and btw, my colleague you referenced warned me about it at the time -- he's always been a few steps ahead) that I never should have popularized it. Thankfully, it fell into the past along with IoC containers (for the most part). I have plenty of other stories about being wrong as well, and as I've said elsewhere, if we find a better way to write commit messages we will do that. For now, from our analysis, the way we do it is best for us -- observably (I'll say that, rather than objectively, though I do believe we were as objective as possible in our analysis). Thanks for the discussion.