61–70 of 76 posts
I recently had a small rant on Twitter about a certain web technology; I used the word "crap." One of the main authors of the tech spotted my post and replied saying my rant was offensive and that they had worked hard and done the best they could. It had been a long time since I felt that much shame in myself. It could have been me pouring myself into something and then the other guy calls it crap.
I triggered Poettering once doing that. I have absolutely no guilt
I assume a clever person designed this blog. I wonder what the pressures were that made them come out with that solution. :P
But I expect you don't actually care, and just wanted to couch your criticism in what you think is a clever dig.
> Being slow to criticize, is being slow to correct. Is being slow to make you better.
I disagree. Being overly fast to criticize is to risk missing the underlying causes, the underlying reasons, and the opportunity both to learn and to make the right changes.
> This is not the first time I hear this argument. My opinion: complete and utter BS.
Then we disagree.
> If I have made bad software, please, let me know AS FAST AS POSSIBLE. Criticize me FAST! Let me fail fast!
If you are there to be asked then I will not simply criticize you, I will ask you why you did it that way. It may be that what you have done is poor, or badly coded, but it may be that there are things you know that I don't know, and it's an opportunity for me to learn from you.
If you then don't have a good reason then we have both learned, and the code will be better. But if you do have a good reason then I have learned, and we can possibly work together to improve things within the restrictions that I had not initially seen.
> This is just apology for mediocre SW.
I think you have missed the point.
Earlier quoted context omitted.
Sometimes people come to the correct conclusion without knowing how. And sometimes people come to the wrong conclusion with a painfully detailed process that really just led them astray. So maybe gut-level reactions shouldn't always be dismissed, and detailed reactions shouldn't always be held above gut level ones.
Okay, but why trust a stranger's gut reaction over your own? When you post your gut reaction, you are the stranger on the Internet. It doesn't matter who you are in real life.
It's not just software, either! There's a common social phenomenon known as the "broken-stair" problem, where you have a toxic, abusive person in a community, and everyone in the community has just gotten used to that person's behavior and normalized it. Sometimes it takes an outsider to notice that this toxic person is a net harm to the community.
Earlier quoted context omitted.
[flagged]
> Oh look, a big angry reaction to a simple assertion that you should try to look at code and criticisms about code objectively. Oh look, an emotional (childishly sarcastic, in this case) reaction demonstrating that offense is, well, an emotional, not logical, reaction. Which was my point. Thank you for playing along. In case you still don't get it, there's a distinction between honest-but-rude and honest-but-nice. M…
There's a difference between being slow to criticize and completely withholding criticism. I agree that software is written by smart people, working under constraints. But so what? If it sucks, it sucks, and we should call it out as such! How will we ever improve anything if we can't highlight what's wrong with the current solution? My go-to example in this regard is the Microsoft Office ribbon. I remember, when the…
I think there's two important aspects of this article: 1) Assume the people who wrote the code aren't stupid. 2) Be nice to developers Point #1 is valid, because yes a lot of times intention is difficult to suss out and the guy who wrote it might have known something you didn't, or maybe the circumstances were different when it was written. Point #2 is just wrong, it goes against the entire principle of Egoless Progr…
Someone sent a comment via the form on the page, but didn't provide a valid email return address. What they said is echoed by other comments on this page and deserves a reply, so I'll reply here. People may, no doubt will, disagree with me and agree with them, but there is a discussion to be had. > Being slow to criticize, is being slow to correct. Is being slow to make you better. I disagree. Being overly fast to cr…
So often there are reasons for things to be the way they are.
This seems like a motte-and-bailey [1] argument. Of course there's a reason for way that things are the way they are. There's always a reason. It doesn't mean that the reason is good.
Let's take, for example, the dark patterns on the Adobe website [2]. Do I need to have the "full context" behind Adobe's product engineering to know that burying a hefty cancellation fee in the fine print for what appears to be month-to-month pricing is awful? No! We can, and should call that decision out, even if we aren't certain of the full process that led up to it.
In addition, I disagree with the broader point that one must have a full understanding of a system in order to disagree with it. I'm not a great cook. But I can sure tell when food tastes bad! Do I lose my ability to say, "Hey, this dish tastes bad," if I can't cook the dish myself? Do I lose the ability to say, "Hey, this car sucks," if I'm not a SAE-certified auto mechanic? Do I need to have a deep understanding of automotive supply chains in order to say that burying the controls for the heated seats two levels deep inside a touchscreen menu is a stupid idea?
No, of course not. While having a full understanding of the constraints behind a system may be helpful, in practice we can and must pass judgement on systems without having that understanding. There simply isn't enough time to learn everything about everything, so sometimes what you have do is say, "Eh this sucks," and move on.
1: https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy
2: https://twitter.com/darkpatterns/status/1489901640777973768
Someone sent a comment via the form on the page, but didn't provide a valid email return address. What they said is echoed by other comments on this page and deserves a reply, so I'll reply here. People may, no doubt will, disagree with me and agree with them, but there is a discussion to be had. > Being slow to criticize, is being slow to correct. Is being slow to make you better. I disagree. Being overly fast to cr…
Earlier quoted context omitted.
I generally agree with the points you are trying to make but > Declaring an existing solution sucks is not sufficient to improve it. Have you ever received poor App Store reviews? In my experience a drop in ratings (for example) can drive a whole lot work. Sure it can help to understand constraints, context, etc but even anecdotal feedback can be helpful.
Fair. Feedback that something sucks can perhaps incentivize an investigation into why. And that investigation might turn up ways that it can be improved. But I think people generally overestimate the positive value of just declaring something bad. All the real work lies in figuring out why and how to make it better.