3 ms·

Cynicism, perhaps?

BoorishBears 5y ago
I prefer realism. I mean just read the tweet again, but ignore the zingy psuedo-snowclone X.Y.Z If someone told you "every breaking change to your API is a failure", would you give them the time of day? But repackage that frankly useless opinion in a zinger and suddenly you have people spending hundreds of comments slowly working backwards to a more nuanced commentary that no longer has anything to do with the original point... - Seriously look at their reply: > I'm watching with amusement as this tweet spreads and it turns out a decent proportion of people are finding it really offensive - feels like people are OK with learning from their mistakes but not with learning from their failures ... what? Because people don't agree with your "hot take" that breaking changes are a failure, they... are ok with making mistakes. But also not ok with failure. Pass me a little bit of whatever it took to make this seem profound? - Why do we give this kind of drivel room? Why give the time of day to an opinion so bad that you need to have a 10 level deep conversation to come up with something resembling a useful take from it? I guess because we're bored?
- simonw 5y ago
  The "I'm watching with amusement..." tweet was me. The person who posted the "FAILS.FEATURES.BUGS" was Will, who is not me. Important you don't continue to believe that Will posted the reply that you're criticizing here.
  - BoorishBears 5y ago
    My bad, Twitter's UI strikes again... but it honestly makes no difference to my point. It was an aside, neither tweet makes sense once you get past the way they're presented. The original tweet is making a point that is so plain nonsensical that the moment you actually evaluate what it says rather than getting caught up in the clever presentation you question why anyone would spare a thought on it. - I mean seriously, "major versions track how many times you've gotten the API wrong". Would you give anyone at all the time of day for such a bad take?! If I have to imagine someone who'd say this (and I honestly can't otherwise, it's such a cartoonishly bad/wrong thing to say) , it'd be a salesperson forced to play PM. Maybe right before promising a client a new version that supports a new use-case? Like a clever way to make the dev team feel bad for not foreseeing an undiscussed future need. The fact to the most reasonable hypothetical situation where someone would share an opinion this bad has so many layers of weirdness... it's saying something about the opinion. Giving a new meaning to "you can't make this stuff up"
    - simonw 5y ago
      I'll be honest: "Major versions track how many times you've gotten the API wrong" really does strike me as a very true statement. I think it's an excellent take. In my own projects I try really hard to avoid major version bumps. When I have to do them I feel bad about it - because I know that it means anyone using my libraries will have to think a lot harder about how they upgrade. You're not alone in disagreeing with me on this. I had a big back-and-forth about with a senior Apache Software Foundation contributor on Twitter this morning: https://twitter.com/myrleKrantz/status/1424006566609629184 https://twitter.com/myrleKrantz/status/1424006566609629184 I'm not saying major version bumps should be avoided at all costs - but they should be avoided at /some/ costs. We should aspire to design our APIs well enough that we don't have to later break them and force our users to upgrade. That's clearly impossible to always hold to, which is why we have major version bumps - but major version bumps should be rare and apologetic, not careless and frequent.
      - BoorishBears 5y ago
        > I'm not saying major version bumps should be avoided at all costs - but they should be avoided at /some/ costs. We should aspire to design our APIs well enough that we don't have to later break them and force our users to upgrade. That's clearly impossible to always hold to, which is why we have major version bumps - but major version bumps should be rare and apologetic, not careless and frequent. This is exactly what I'm talking about. If the tweet had said "breaking changes should not be careless and frequent", this post would not exist and those replies would not exist because... it's so painfully obvious! You really think people are arguing against that? That is simply not what the original comment says! That's not even what you said at the start of your own comment just now! It is not the same as saying "you got the API wrong"! - And I don't mean that in a semantical "haha gotcha" way, I mean they literally are two different statements and one is wrong, and one is so obvious it's literally part of the standard! I mean have you actually read the document that defines SemVer?! https://semver.org/ https://semver.org/ It literally says in 10 different ways that you should not be breaking your API often! That if you are either you need to stay below 1.0.0 or use a separate branch. - It's like by saying (or supporting) a viewpoint so extreme it's straight up wrong, you position yourself to then retroactively take an extremely moderate position in a way that makes you sound super clever... Except you needed to support/say something super unclever as a spring board. And anyone who's gone through enough if these kinds of platitudes will see that immediately and call you out on the unclever thing you said. That's why you see such strong opposition, not because a senior ASF contributor needs you of all people to tell them that major version bumps in semver, aka breaking changes, shouldn't be careless and frequent! Do you not see what you're doing as patronizing at all? Luring people in with a conversation about a downright bad take (even if it's someone else's) then browbeating them with a super obvious non-statement that would never have been worth the conversation in the first place? It's the worst form of ego-stroking if I'm being real for a second. Don't do that.

Cynicism, perhaps?

I prefer realism. I mean just read the tweet again, but ignore the zingy psuedo-snowclone X.Y.Z If someone told you "every breaking change to your API is a failure", would you give them the time of day? But repackage that frankly useless opinion in a zinger and suddenly you have people spending hundreds of comments slowly working backwards to a more nuanced commentary that no longer has anything to do with the original point... - Seriously look at their reply: > I'm watching with amusement as this tweet spreads and it turns out a decent proportion of people are finding it really offensive - feels like people are OK with learning from their mistakes but not with learning from their failures ... what? Because people don't agree with your "hot take" that breaking changes are a failure, they... are ok with making mistakes. But also not ok with failure. Pass me a little bit of whatever it took to make this seem profound? - Why do we give this kind of drivel room? Why give the time of day to an opinion so bad that you need to have a 10 level deep conversation to come up with something resembling a useful take from it? I guess because we're bored?

simonw 5y ago
The "I'm watching with amusement..." tweet was me. The person who posted the "FAILS.FEATURES.BUGS" was Will, who is not me. Important you don't continue to believe that Will posted the reply that you're criticizing here.
- BoorishBears 5y ago
  My bad, Twitter's UI strikes again... but it honestly makes no difference to my point. It was an aside, neither tweet makes sense once you get past the way they're presented. The original tweet is making a point that is so plain nonsensical that the moment you actually evaluate what it says rather than getting caught up in the clever presentation you question why anyone would spare a thought on it. - I mean seriously, "major versions track how many times you've gotten the API wrong". Would you give anyone at all the time of day for such a bad take?! If I have to imagine someone who'd say this (and I honestly can't otherwise, it's such a cartoonishly bad/wrong thing to say) , it'd be a salesperson forced to play PM. Maybe right before promising a client a new version that supports a new use-case? Like a clever way to make the dev team feel bad for not foreseeing an undiscussed future need. The fact to the most reasonable hypothetical situation where someone would share an opinion this bad has so many layers of weirdness... it's saying something about the opinion. Giving a new meaning to "you can't make this stuff up"
  - simonw 5y ago
    I'll be honest: "Major versions track how many times you've gotten the API wrong" really does strike me as a very true statement. I think it's an excellent take. In my own projects I try really hard to avoid major version bumps. When I have to do them I feel bad about it - because I know that it means anyone using my libraries will have to think a lot harder about how they upgrade. You're not alone in disagreeing with me on this. I had a big back-and-forth about with a senior Apache Software Foundation contributor on Twitter this morning: https://twitter.com/myrleKrantz/status/1424006566609629184 https://twitter.com/myrleKrantz/status/1424006566609629184 I'm not saying major version bumps should be avoided at all costs - but they should be avoided at /some/ costs. We should aspire to design our APIs well enough that we don't have to later break them and force our users to upgrade. That's clearly impossible to always hold to, which is why we have major version bumps - but major version bumps should be rare and apologetic, not careless and frequent.
    - BoorishBears 5y ago
      > I'm not saying major version bumps should be avoided at all costs - but they should be avoided at /some/ costs. We should aspire to design our APIs well enough that we don't have to later break them and force our users to upgrade. That's clearly impossible to always hold to, which is why we have major version bumps - but major version bumps should be rare and apologetic, not careless and frequent. This is exactly what I'm talking about. If the tweet had said "breaking changes should not be careless and frequent", this post would not exist and those replies would not exist because... it's so painfully obvious! You really think people are arguing against that? That is simply not what the original comment says! That's not even what you said at the start of your own comment just now! It is not the same as saying "you got the API wrong"! - And I don't mean that in a semantical "haha gotcha" way, I mean they literally are two different statements and one is wrong, and one is so obvious it's literally part of the standard! I mean have you actually read the document that defines SemVer?! https://semver.org/ https://semver.org/ It literally says in 10 different ways that you should not be breaking your API often! That if you are either you need to stay below 1.0.0 or use a separate branch. - It's like by saying (or supporting) a viewpoint so extreme it's straight up wrong, you position yourself to then retroactively take an extremely moderate position in a way that makes you sound super clever... Except you needed to support/say something super unclever as a spring board. And anyone who's gone through enough if these kinds of platitudes will see that immediately and call you out on the unclever thing you said. That's why you see such strong opposition, not because a senior ASF contributor needs you of all people to tell them that major version bumps in semver, aka breaking changes, shouldn't be careless and frequent! Do you not see what you're doing as patronizing at all? Luring people in with a conversation about a downright bad take (even if it's someone else's) then browbeating them with a super obvious non-statement that would never have been worth the conversation in the first place? It's the worst form of ego-stroking if I'm being real for a second. Don't do that.