7 ms·

Being Slow to Criticise

99 points by ColinWright 5y ago

ColinWright 5y ago
Bother ... I've not been keeping track and I've just realised I submitted this not so long ago. Apologies. I was prompted by the submission about "My seatbelt rule for judgment" here: https://news.ycombinator.com/item?id=30237457 https://news.ycombinator.com/item?id=30237457 Having realised I've returned to delete the submission, but find that I can't. /mea culpa/
- dgellow 5y ago
  It's a cool read, glad you shared it again I missed it the first time (~2 month ago from what I can see).
- ojintoad 5y ago
  ¯\_(ツ)_/¯ I wouldn't have found this otherwise and it's aligning nicely with the latest podcast from Legacy Code Rocks: https://legacycoderocks.libsyn.com/self-compassion-with-clare-sudbery https://legacycoderocks.libsyn.com/self-compassion-with-clar... I appreciate this double post!
- darksaints 5y ago
  Reposts are a good thing when done in a non-spammy way. I had never seen this before and now I have.
lmm 5y ago
So how do you avoid getting nerd-sniped when something really is just bad? There's an analogue of the Bullshit Asymmetry Principle here; any of us could slap out some code in half an hour (no doubt many of us have, myself included) and then any of us could spend days or weeks trying to understand why we did it that way. Taking the time to understand bad software is, like up-front planning, one of those things that sounds worthy and wise, but I suspect it's actually a poor use of time on the whole.
- mannykannot 5y ago
  > So how do you avoid getting nerd-sniped when something really is just bad? This is not logic, where existence of a counterexample invalidates the general argument. One reason for looking at even genuinely bad code is that it may express domain knowledge that you are currently unaware of. Jon Bentley told the story of a Bell Labs researcher who found that his fast and correct algorithm for something or other had been "fixed" and "improved" so much that it was no longer efficient (a few comments may have helped here - though not necessarily - but that is a discussion for another time.)
- awkward 5y ago
  The same way you avoid getting sucked into anything - go in knowing how much time and effort you're willing to expend and cut your losses when you hit the limit.
- michaelrpeskin 5y ago
  Sometimes, it helps to just put in the comments why you did something that you know is not optimal. Often you'll write "bad" code just because it makes sense. I had to update something last week where the requirements changed dramatically from when they were written. It's nobody's fault. When the requirements were written, we did really understand the problem. After the customer got the code in their hand, they wanted to extend it in a way that wasn't obvious to us or them. I could have done a multi-month refactoring to make it clean and pretty, but that didn't make any business sense, so I did some surgical changes. To avoid someone coming back next year and thinking WTF, I added this to the comment (most of the details left out for anonymity) //...Not how I would design it from scratch, but a nice evolutionary change. Now next year when someone else looks at it (or even next-year me), we won't waste time thinking if we should refactor it, because it's obvious that we already looked at the pros and cons and decided not to.
  - darepublic 5y ago
    If it's not you someone else may indeed want to refactor. They would like a crack at the designing from scratch
fristechill 5y ago
Especially now, jammed together as we are in the global village, I suspect criticism is something we should only use defensively. Even criticism of ideas should be restricted to ideas we don't like but can't seem to avoid. Bearing in mind that if criticisms fail then perhaps the idea is a good one after all.
trabant00 5y ago
I delivered crap multiple times during my career. Sometimes I was forced to by external factors, sometime I was not in a good mental shape, sometime there was no time to do anything more than pile some garbage on top and duct-tape it together. Sometimes I didn't even knew it at the time, I thought I was doing fine. Sometimes I delivered a good thing that aged bad and turned to garbage or the environment in which it functioned changed. So yeah, I am no longer quick to judge others by the work they did especially if I don't know the circumstances. But I am of the firm opinion that we should try to be honest and say when something is garbage. It might be justified that it is garbage and the producer might not have any fault, but it's still garbage. We might not have time to take out the garbage, we might even sweep it under the rug for a while, or even permanently. Be honest though, call it what it is. How else are we going to learn to do better or appreciate the gems by contrast?
- is_true 5y ago
  I had to write garbage a couple of times. The important thing is wrapping it very well so the client can't smell it. I usually leave comments on garbage so later when I'm doing something else I try to fix it.
roenxi 5y ago
I think it is more that software is going to be "garbage" regardless (whatever that means, if the software writer disagrees with the user about what the software should do it is unclear who has the most right to call themselves correct). A generally good software system is agnostic about the quality of its components. There are going to be bugs everywhere and it is important to guarantee outcomes. The pinnacle of this thinking is something like TCP creating a reliable connection out of fallible parts. It doesn't matter that the parts are unreliable, we get a reliable outcome because the system has realistic expectations of its components. This instance has overtones of the same thinking. Also, Chesterton's fence is often a red herring that leads to poor practices. It is appropriate to just break things that look suspicious if the risk of failure is low. When it turns out the strange construction is needed, repair the damage done and add a comment or documentation.
draw_down 5y ago
Honestly, the software probably is garbage, because more or less all of it is. We can accept this without being nasty about it. Decent or non-terrible software is the surprise and the exception, not the rule.
kache_ 5y ago
All software is incorrect in a large enough time frame
angarg12 5y ago
The Principal Engineer community in Amazon has a list of tenets. I think one of them puts it very eloquently. Respect What Came Before
- draw_down 5y ago
- liotier 5y ago
  https://www.amazon.jobs/en/landing_pages/pe-community-tenets https://www.amazon.jobs/en/landing_pages/pe-community-tenets
- Foobar8568 5y ago
  >Respect What Came Before When I was junior, I didn't respect much what came before...As I got experiences, I understood this need. I respect what came before, often people are surprised when I take that line. The only problem is when people continue to do shit (even when hand carried through everything) and still have Pikachu faces when things go wrong, well these people and projects don't deserve respect.
- nimitz12 5y ago
- andrewqu 5y ago
  Any chance you can share some of the other tenets? :P
  - rask17 5y ago
    https://www.amazon.jobs/en/landing_pages/pe-community-tenets https://www.amazon.jobs/en/landing_pages/pe-community-tenets
    - jagged-chisel 5y ago
      Can't imagine why this, a public link to precisely what the parent comment mentions, is [dead] - unless it's the complete lack of karma on the account. Vouched in the hope that it'll benefit someone.
sillyquiet 5y ago
in my opinion, this tendency to label anything less-than-ideal as 'garbage' is an outdated leftover of a time when assholish (and unrealistic) perfectionism was admired in software engineering, or at least looked up to as 'good engineering'. This binary outlook is what leads to people who don't understand the reasons behind why existing code is the way it is to criticize. Frankly, when someone does it (and I have done it, lots of times, to my chagrin now) its a pretty good marker of engineering immaturity. This is different than looking at something and identifying ways it could be better, btw. The latter is value-neutral and judgement-free.
druadh 5y ago
While I'll never "Show HN". Criticism can be delivered without it needing to feel like the gauntlet of pain
ISL 5y ago
A wise mentor once encouraged me, "Assume positive intent and ask lots of questions." That directive has served extremely well ever since.
- draw_down 5y ago
  Absolutely. And people with the best intentions can produce crap sometimes. That’s just reality. There’s a reason for that old saying about good intentions.
buttocks 5y ago
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.
- onemoresoop 5y ago
  Because you have empathy you have learned a lesson. Lots of us make that mistake and learn from it. I'm glad you came clean about it. Now don't be shy about criticizing, just be more thoughtful about it.
- bigwig8702 5y ago
- hughrr 5y ago
  I triggered Poettering once doing that. I have absolutely no guilt
  - deleted 5y ago
    [deleted]
quanticle 5y ago
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 ribbon was introduced, I saw a presentation from a Microsoft employee (I can't remember if he was a developer or a product manager) going over the extensive testing that Microsoft did with focus groups to "prove" that the new UI was superior to the previous menu-based one. I remembered being both very impressed with the ostensible rigor of the process, and disappointed with the result. All that work, all that testing to delude themselves into believing that a UI where elements moved around, and weren't in predictable locations was going to be something that users (especially experienced users) would prefer. And sure enough, even to this day, I still see users (both new and experienced) struggling with the ribbon. It sucks! And the fact that I know a lot of very smart people worked on it doesn't change that fact. In fact, it makes it worse. It would be one thing if such a horrid design were the result of a haphazard design process, implemented by incompetents. But it's not. It's the result of a lot of very smart people Goodharting themselves into believing that they've found the one weird trick to make their software both powerful and easy to use. I strongly believe, that, if in the early days of the ribbon, someone had stood up and said, "This sucks!" things might have gone in a different direction.
- highwind 5y ago
  I personally like Ribbon over rows and rows of small icons without labels. I think of Ribbons like tabs that organizes the buttons that makes sense together. But I'm not a power Office user and that's just my preference.
  - droopyEyelids 5y ago
    Would you spend a little time sharing stories about other things you prefer?
  - quanticle 5y ago
    The ribbon didn't replace rows and rows of small icons without labels. It replaced a hierarchical menu. Now, did the hierarchical menu have flaws? It did, insofar as it was rather forbidding to explore, and as a result, new users had trouble finding functionality by clicking around. That was the use case that the Ribbon sought to address. What the designers of the ribbon did not understand was that users have other ways to find functionality. They could look up functionality on the Internet. There were even physical books which told you which specific menu to click on for a particular function. What the ribbon did was instantly render all those resources useless. Moreover, by attempting to constantly surface different controls based upon the context of the current task, the ribbon made it extremely difficult to make new resources and tutorials. You could make a tutorial with screenshots, only to have users come to you with screens that look nothing like your screenshot, because they just happened to be highlighting a slightly different element.
marcosdumay 5y ago
Hum... The article puts no effort on determining how much work went into that comment's assessment and how useful it was to people looking into invest some effort on migrating and learning how to use it.
chrislan815 5y ago
Essentially give people the benefit of doubt.
dhbradshaw 5y ago
It's easy to criticize and hard to understand. Similarly, it's hard to see the cost of criticizing and it can be hard to judge the benefit of understanding. Because of this, we'll see patterns of ignorant criticism playing out again and again. Some of the people in the pattern will never know any better. Others know better but don't care. Others know better but can't pay the price to understand because it's too high. So when you find someone who actually defaults to understanding rather than criticizing you've found someone of rare value.
visviva 5y ago
I assume a clever person designed this blog. I wonder what the pressures were that made them come out with that solution. :P
- ColinWright 5y ago
  I wouldn't say I was clever, but there were, indeed, pressures that have led to the way it is, and the way it works. Instead of snarky, implied criticism like this, you could simply ask. Maybe I could then learn from you and it would get better, or maybe you could come to understand why it is as it is. But I expect you don't actually care, and just wanted to couch your criticism in what you think is a clever dig.
  - visviva 5y ago
    You're right - this just comes off as snarky criticism. That wasn't my intent. I actually don't have any strong criticism about it - I was just thrown by the quote boxes at first.
    - ColinWright 5y ago
      > ... I was just thrown by the quote boxes at first. That's interesting ... the "style" with the quote boxes was, indeed, the result of various implementation pressures when the site was first implemented. They've stuck, and my regular readers now consider it part of the "site style". It's all well overdue a complete redesign, but whenever I've explained to people how it works, and what it does, they've recoiled in horror, then gone very thoughtful, then never come back again. Addendum: You may be interested in this: https://www.solipsys.co.uk/new/HowTheFarragoWorks.html?vb09hn https://www.solipsys.co.uk/new/HowTheFarragoWorks.html?vb09h...
ColinWright 5y ago
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

99 points by ColinWright 5y ago

Bother ... I've not been keeping track and I've just realised I submitted this not so long ago. Apologies. I was prompted by the submission about "My seatbelt rule for judgment" here: https://news.ycombinator.com/item?id=30237457 https://news.ycombinator.com/item?id=30237457 Having realised I've returned to delete the submission, but find that I can't. /mea culpa/

dgellow 5y ago
It's a cool read, glad you shared it again I missed it the first time (~2 month ago from what I can see).
ojintoad 5y ago
¯\_(ツ)_/¯ I wouldn't have found this otherwise and it's aligning nicely with the latest podcast from Legacy Code Rocks: https://legacycoderocks.libsyn.com/self-compassion-with-clare-sudbery https://legacycoderocks.libsyn.com/self-compassion-with-clar... I appreciate this double post!
darksaints 5y ago
Reposts are a good thing when done in a non-spammy way. I had never seen this before and now I have.

lmm 5y ago

So how do you avoid getting nerd-sniped when something really is just bad? There's an analogue of the Bullshit Asymmetry Principle here; any of us could slap out some code in half an hour (no doubt many of us have, myself included) and then any of us could spend days or weeks trying to understand why we did it that way. Taking the time to understand bad software is, like up-front planning, one of those things that sounds worthy and wise, but I suspect it's actually a poor use of time on the whole.

mannykannot 5y ago
> So how do you avoid getting nerd-sniped when something really is just bad? This is not logic, where existence of a counterexample invalidates the general argument. One reason for looking at even genuinely bad code is that it may express domain knowledge that you are currently unaware of. Jon Bentley told the story of a Bell Labs researcher who found that his fast and correct algorithm for something or other had been "fixed" and "improved" so much that it was no longer efficient (a few comments may have helped here - though not necessarily - but that is a discussion for another time.)
awkward 5y ago
The same way you avoid getting sucked into anything - go in knowing how much time and effort you're willing to expend and cut your losses when you hit the limit.
michaelrpeskin 5y ago
Sometimes, it helps to just put in the comments why you did something that you know is not optimal. Often you'll write "bad" code just because it makes sense. I had to update something last week where the requirements changed dramatically from when they were written. It's nobody's fault. When the requirements were written, we did really understand the problem. After the customer got the code in their hand, they wanted to extend it in a way that wasn't obvious to us or them. I could have done a multi-month refactoring to make it clean and pretty, but that didn't make any business sense, so I did some surgical changes. To avoid someone coming back next year and thinking WTF, I added this to the comment (most of the details left out for anonymity) //...Not how I would design it from scratch, but a nice evolutionary change. Now next year when someone else looks at it (or even next-year me), we won't waste time thinking if we should refactor it, because it's obvious that we already looked at the pros and cons and decided not to.
- darepublic 5y ago
  If it's not you someone else may indeed want to refactor. They would like a crack at the designing from scratch

fristechill 5y ago

Especially now, jammed together as we are in the global village, I suspect criticism is something we should only use defensively. Even criticism of ideas should be restricted to ideas we don't like but can't seem to avoid. Bearing in mind that if criticisms fail then perhaps the idea is a good one after all.

trabant00 5y ago

I delivered crap multiple times during my career. Sometimes I was forced to by external factors, sometime I was not in a good mental shape, sometime there was no time to do anything more than pile some garbage on top and duct-tape it together. Sometimes I didn't even knew it at the time, I thought I was doing fine. Sometimes I delivered a good thing that aged bad and turned to garbage or the environment in which it functioned changed. So yeah, I am no longer quick to judge others by the work they did especially if I don't know the circumstances. But I am of the firm opinion that we should try to be honest and say when something is garbage. It might be justified that it is garbage and the producer might not have any fault, but it's still garbage. We might not have time to take out the garbage, we might even sweep it under the rug for a while, or even permanently. Be honest though, call it what it is. How else are we going to learn to do better or appreciate the gems by contrast?

is_true 5y ago
I had to write garbage a couple of times. The important thing is wrapping it very well so the client can't smell it. I usually leave comments on garbage so later when I'm doing something else I try to fix it.

roenxi 5y ago

I think it is more that software is going to be "garbage" regardless (whatever that means, if the software writer disagrees with the user about what the software should do it is unclear who has the most right to call themselves correct). A generally good software system is agnostic about the quality of its components. There are going to be bugs everywhere and it is important to guarantee outcomes. The pinnacle of this thinking is something like TCP creating a reliable connection out of fallible parts. It doesn't matter that the parts are unreliable, we get a reliable outcome because the system has realistic expectations of its components. This instance has overtones of the same thinking. Also, Chesterton's fence is often a red herring that leads to poor practices. It is appropriate to just break things that look suspicious if the risk of failure is low. When it turns out the strange construction is needed, repair the damage done and add a comment or documentation.

draw_down 5y ago

Honestly, the software probably is garbage, because more or less all of it is. We can accept this without being nasty about it. Decent or non-terrible software is the surprise and the exception, not the rule.

kache_ 5y ago

All software is incorrect in a large enough time frame

angarg12 5y ago

The Principal Engineer community in Amazon has a list of tenets. I think one of them puts it very eloquently. Respect What Came Before

draw_down 5y ago
liotier 5y ago
https://www.amazon.jobs/en/landing_pages/pe-community-tenets https://www.amazon.jobs/en/landing_pages/pe-community-tenets
Foobar8568 5y ago
>Respect What Came Before When I was junior, I didn't respect much what came before...As I got experiences, I understood this need. I respect what came before, often people are surprised when I take that line. The only problem is when people continue to do shit (even when hand carried through everything) and still have Pikachu faces when things go wrong, well these people and projects don't deserve respect.
nimitz12 5y ago
andrewqu 5y ago
Any chance you can share some of the other tenets? :P
- rask17 5y ago
  https://www.amazon.jobs/en/landing_pages/pe-community-tenets https://www.amazon.jobs/en/landing_pages/pe-community-tenets
  - jagged-chisel 5y ago
    Can't imagine why this, a public link to precisely what the parent comment mentions, is [dead] - unless it's the complete lack of karma on the account. Vouched in the hope that it'll benefit someone.

sillyquiet 5y ago

in my opinion, this tendency to label anything less-than-ideal as 'garbage' is an outdated leftover of a time when assholish (and unrealistic) perfectionism was admired in software engineering, or at least looked up to as 'good engineering'. This binary outlook is what leads to people who don't understand the reasons behind why existing code is the way it is to criticize. Frankly, when someone does it (and I have done it, lots of times, to my chagrin now) its a pretty good marker of engineering immaturity. This is different than looking at something and identifying ways it could be better, btw. The latter is value-neutral and judgement-free.

druadh 5y ago

While I'll never "Show HN". Criticism can be delivered without it needing to feel like the gauntlet of pain

ISL 5y ago

A wise mentor once encouraged me, "Assume positive intent and ask lots of questions." That directive has served extremely well ever since.

draw_down 5y ago
Absolutely. And people with the best intentions can produce crap sometimes. That’s just reality. There’s a reason for that old saying about good intentions.

buttocks 5y ago

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.

onemoresoop 5y ago
Because you have empathy you have learned a lesson. Lots of us make that mistake and learn from it. I'm glad you came clean about it. Now don't be shy about criticizing, just be more thoughtful about it.
bigwig8702 5y ago
hughrr 5y ago
I triggered Poettering once doing that. I have absolutely no guilt
- deleted 5y ago
  [deleted]

quanticle 5y ago

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 ribbon was introduced, I saw a presentation from a Microsoft employee (I can't remember if he was a developer or a product manager) going over the extensive testing that Microsoft did with focus groups to "prove" that the new UI was superior to the previous menu-based one. I remembered being both very impressed with the ostensible rigor of the process, and disappointed with the result. All that work, all that testing to delude themselves into believing that a UI where elements moved around, and weren't in predictable locations was going to be something that users (especially experienced users) would prefer. And sure enough, even to this day, I still see users (both new and experienced) struggling with the ribbon. It sucks! And the fact that I know a lot of very smart people worked on it doesn't change that fact. In fact, it makes it worse. It would be one thing if such a horrid design were the result of a haphazard design process, implemented by incompetents. But it's not. It's the result of a lot of very smart people Goodharting themselves into believing that they've found the one weird trick to make their software both powerful and easy to use. I strongly believe, that, if in the early days of the ribbon, someone had stood up and said, "This sucks!" things might have gone in a different direction.

highwind 5y ago
I personally like Ribbon over rows and rows of small icons without labels. I think of Ribbons like tabs that organizes the buttons that makes sense together. But I'm not a power Office user and that's just my preference.
- droopyEyelids 5y ago
  Would you spend a little time sharing stories about other things you prefer?
- quanticle 5y ago
  The ribbon didn't replace rows and rows of small icons without labels. It replaced a hierarchical menu. Now, did the hierarchical menu have flaws? It did, insofar as it was rather forbidding to explore, and as a result, new users had trouble finding functionality by clicking around. That was the use case that the Ribbon sought to address. What the designers of the ribbon did not understand was that users have other ways to find functionality. They could look up functionality on the Internet. There were even physical books which told you which specific menu to click on for a particular function. What the ribbon did was instantly render all those resources useless. Moreover, by attempting to constantly surface different controls based upon the context of the current task, the ribbon made it extremely difficult to make new resources and tutorials. You could make a tutorial with screenshots, only to have users come to you with screens that look nothing like your screenshot, because they just happened to be highlighting a slightly different element.

marcosdumay 5y ago

Hum... The article puts no effort on determining how much work went into that comment's assessment and how useful it was to people looking into invest some effort on migrating and learning how to use it.

chrislan815 5y ago

Essentially give people the benefit of doubt.

dhbradshaw 5y ago

It's easy to criticize and hard to understand. Similarly, it's hard to see the cost of criticizing and it can be hard to judge the benefit of understanding. Because of this, we'll see patterns of ignorant criticism playing out again and again. Some of the people in the pattern will never know any better. Others know better but don't care. Others know better but can't pay the price to understand because it's too high. So when you find someone who actually defaults to understanding rather than criticizing you've found someone of rare value.

visviva 5y ago

I assume a clever person designed this blog. I wonder what the pressures were that made them come out with that solution. :P

ColinWright 5y ago
I wouldn't say I was clever, but there were, indeed, pressures that have led to the way it is, and the way it works. Instead of snarky, implied criticism like this, you could simply ask. Maybe I could then learn from you and it would get better, or maybe you could come to understand why it is as it is. But I expect you don't actually care, and just wanted to couch your criticism in what you think is a clever dig.
- visviva 5y ago
  You're right - this just comes off as snarky criticism. That wasn't my intent. I actually don't have any strong criticism about it - I was just thrown by the quote boxes at first.
  - ColinWright 5y ago
    > ... I was just thrown by the quote boxes at first. That's interesting ... the "style" with the quote boxes was, indeed, the result of various implementation pressures when the site was first implemented. They've stuck, and my regular readers now consider it part of the "site style". It's all well overdue a complete redesign, but whenever I've explained to people how it works, and what it does, they've recoiled in horror, then gone very thoughtful, then never come back again. Addendum: You may be interested in this: https://www.solipsys.co.uk/new/HowTheFarragoWorks.html?vb09hn https://www.solipsys.co.uk/new/HowTheFarragoWorks.html?vb09h...

ColinWright 5y ago

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