2 ms·

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 d

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 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.

quanticle 5y ago
I specifically take issue with this statement in the piece: 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 https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy 2: https://twitter.com/darkpatterns/status/1489901640777973768 https://twitter.com/darkpatterns/status/1489901640777973768
edmundsauto 5y ago
Fundamentally, I think many programmers forget that writing software is a human problem first, and a coding/technical problem second. When you pause an extra beat to understand how things got the way they are before opening your mouth, it optimizes for the humanness of the outcome, which is more in line with the actual challenges - the humans using and building the software.

quanticle 5y ago

I specifically take issue with this statement in the piece: 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 https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy 2: https://twitter.com/darkpatterns/status/1489901640777973768 https://twitter.com/darkpatterns/status/1489901640777973768

edmundsauto 5y ago

Fundamentally, I think many programmers forget that writing software is a human problem first, and a coding/technical problem second. When you pause an extra beat to understand how things got the way they are before opening your mouth, it optimizes for the humanness of the outcome, which is more in line with the actual challenges - the humans using and building the software.