But whereas my intuitions for the Blunt Honesty thing is that it’s worth cultivating the skill of saying uncomfortable things in a less-blunt-way, my intuition for the “let’s try to be less weird thing” is more of a creeping sense of dread and losing something precious.
Which is what I expect the pro-blunt-honesty people to feel when anyone talks about “let’s make blunt honesty less acceptable here.”
That may be true, when you make this “less blunt honesty!” change to an existing, active community. But when you build a new place, and say “less blunt honesty here!”, the Blunt Honesty crowd feels no creeping dread, but simply shrugs and leaves.
FWIW, this didn’t feel at all like blunt honesty, just regular honesty (although I suppose if you’ve carving things along “did I bother to put a smooth-it-out-nicely filter” vs “did I say something people will be offended by”, I could see an argument for thinking more about the former)
I think, having written this post over several months with evolving views in the meantime… my strongest remaining opinion is:
If you’re going to do the blunt honesty thing, and it seems nontrivial to reword things so people will be less offended, a strong* signal of collaborative building is really important . A community where people criticize and hold each other to a high standard can produce a lot of useful, interesting things. A community where people mostly complain at each other probably will not.
(I also just realized I forgot to include “actually build a thing” along with “brainstorm solutions” and “active listening” in the “how to collaboratively build” section. This was triggered by remembering that when you criticized LW2.0 for font choice etc, you accompanied that with actually making a stylesheet that addressed the issues you mentioned while sticking to the general aesthetic LW2.0 was going for. Which I think was pretty cool)
* by “strong” I mean “strong enough that people feel that you’re fundamentally out to help”, and how much effort it takes to send that signal varies by situation.
if you’ve carving things along “did I bother to put a smooth-it-out-nicely filter”
This.
a strong* signal of collaborative building is really important
You answered that yourself in the next paragraph, in exactly the way I was going to, so I think we’re on the same page here.
My first instinct when I see something being done wrong is to say “this is bad and wrong”. My second instinct is to do it myself. This has worked out well enough for me, all things considered, but it doesn’t scale very well, and a community where the pattern is that the first instinct never gets any results and I have to fall back to the second one all the time, is a community that I quickly come to question to value of participating in. (This is similar to the thing some managers do where if you bring up a problem, you’re assigned to fix it; well, guess what—that disincentivizes bringing up problems. But a web forum is not a job, so instead of keeping quiet, people can just leave.)
(I’ve now alluded to taking my toys and going home two or three times, which puts me in danger of sounding like a histrionic whiner, so I’ll leave this topic of conversation alone now. I just want to mention, before I do, that this being Less Wrong and not some random nowhere place, I don’t actually want to want to take my toys and go home, which is, in fact, the reason I bother to complain or to make custom stylesheets or whatever.)
I very much believe “if you can’t actually trust people to take things seriously, then the system is missing a crucial layer of trust.”
The central thesis I’ve been thinking about this year is something like: “there’s a lot of kinds of trust that have to happen at once for a valuable community to work”. These include:
1. trust that people are actually trying to work together to make a good thing 2. trust that when people say they will do a thing, they will do it 3. trust that people will say (and do) things that matter, and if they’re incapable of doing so, level themselves up until they can. (i.e. if you will resolve #2 by never committing to anything… well, maybe that’s a step up but it’s not sufficient). 4. trust people to be aware/introspective enough to not fall into a lot of failure modes 5. you have to trust people at all (i.e. like, not be lying or manipulative)
And all of that trust requires both people to be willing to trust, and also to have the skills and dedication to actually be worthy of that trust.
And, along a number of axis, we are not there yet.
Re: UX/UI stuff
I’m not sure if the “take your ball and go home” thing was mostly relating to UX stuff or other less obvious-to-me things. I do want to:
a) acknowledge that the core dev team hasn’t been as communicative about that as we’d ideally have been, nor taken obvious effort to address it, so from your perspective it’d make sense if we seemed untrustworthy in that regard
b) from our perspective… there’s just a lot of stuff to do. A lot of bugs and core-site-streamlining that seem higher priority, and a lot of people bringing up additional bugs all the time, and time/effort spent on any given thing means not doing other things (this includes responding quickly/adequately to everyone bringing stuff up).
I don’t actually know what advice I’d give a manager of a team that is already strapped for time and working on the most important thing. Or rather: the advice is “put the thing in the backlog and assign it later”, but in a more volunteerish-situation where a) people disagree on what the most important thing is b) people have different skills and interests and people tend to notice things that are more relevant to them...
...I just don’t think there’s much room for improvement beyond “if you want this thing to be a higher priority, you’ll need to contribute work towards getting it done, or at least make a clear case that it is more important than the other things we’re working on instead.”
Re: Bad/Wrong
(phrasing this more bluntly than I normally would since it’s seems like that’s what you prefer)
I think there’s very much an intermediate step between “this is bad/wrong” and “do all the work yourself”, and that’s “communicate that wrongness in a way that feels helpful and collaborative.”
If it’s legitimately effortful to translate your thoughts into that form, and you don’t trust people to actually respond usefully (because they historically haven’t), I think that’s fair. But to actually get from there to “a good, functioning system”, I think it’s both necessary for the people-ignoring-you to put in that effort and for you to put more effort into translating your criticism into ones that pattern-match more to “trying to help” than “complaining/snarking/sniping”
(I personally have to remind myself that you have a track record of putting in effort and changing your mind about things when relevant, because while those things have happened over four years in a significant way, they are less frequent and salient than your average critical comment)
I think overriding the impulse to say “Bad/Wrong” and replace it with constructive substance is one of the core skills necessary for group-rationality to thrive (esp. when running on human hardware, and [possibly] even in more idealized circumstances.
Yeah—I just realized I was conflating a few different clusters of things you said at different times in different contexts in way which was both factually inaccurate as as well as uncharitable. I apologize for that.
I’m not actually sure to what extent we disagree on the object level things here—I definitely believe UX and typography are important, just lower priority than “site loads in a reasonable amount of time” and “get an integration/unit-testing framework in place to avoid mounting tech-debt”. Do you disagree with that?
It felt from the previous couple comments that you felt frustrated about some pattern of interaction but I’m not actually sure which thing you’re particularly worried about. (Also not sure if this is in the scope of things you still wanted to talk about)
I definitely believe UX and typography are important, just lower priority than “site loads in a reasonable amount of time” and “get an integration/unit-testing framework in place to avoid mounting tech-debt”. Do you disagree with that?
It’s hard to know what to say here; of course the site should load in a reasonable amount of time (this other NN Group article is particularly relevant here)… but…
One thing I could say is—of these scenarios, which is best, and which is worst:
The site loads quickly, and it’s good.
The site loads quickly, but it sucks.
The site loads slowly, but once loaded it’s good.
The site loads slowly, and once loaded, it sucks.
Clearly, #4 is worst. We’d all prefer #1. But suppose we find ourselves at #4, and further find that (by the expenditure of some unit of time/effort) we can move to #2 or to #3—we can’t jump directly to #1. (Then, perhaps, we can take another step, with more time and effort, and make it all the way to #1.)
What I am suggesting is that #3 is the superior first step compared to #2, because (in no particular order):
The aesthetic usability effect (as described in the link above) ensures that poor performance is more readily excused if the site is perceived to be appealing; the reverse is not the case
Poor performance is more readily excused as a transitional-stage effect of a beta development stage than either poor aesthetics or poor usability
A visitor who perceives using the site as having high value but also high cost may retain the mental impression of “value here, but also high cost; questionable for now whether worthwhile” and come back to it (and keep coming back to it) later; a visitor who makes the snap judgment of “little to no value here” leaves and does not return
As per this comment thread, aesthetics and usability can often be (but are not always) easier to improve than infrastructure (i.e., separately from #3 being a better place to be, it’s also easier to get to than #2)
Of course aesthetics and usability and other aspects of UX (like efficiency and effectiveness of task completion) aren’t everything that go into making a site “good” or “sucky”, so what I said above is not the whole story; content, for instance, is largely (though not nearly entirely) orthogonal to both that and to performance per se…
As for “get an integration/unit-testing framework in place to avoid mounting tech-debt”, well, there is much to be said for doing that before starting a public beta; of course there is nothing to be done about this now. (Neither is there necessarily anything to be done about various technical decisions which quite complicate certain sorts of improvement; the fact remains that they do indeed have that effect…)
The problem, as I’m sure you realize, is that I, the user of the site, cannot see your tech-debt. Oh, I may quite clearly see the effects of your tech-debt—or, at least, you say they’re effects of your tech debt; how can I know? maybe some unrelated cause is to blame; I have only your word, here, and anyway it hardly matters why problem X, Y, and Z exists—they do, and that’s that.
So then you do your thing, to avoid mounting tech-debt, and—and what? Is the site now more usable, as a result? More aesthetically pleasing? Can I navigate it more easily? Does it load quicker? Well, no, those things will come, now that you’ve solved your tech-debt problem… but they have not come yet; so from my, user’s, perspective, you’ve spent time and effort and benefited me not at all.
So perhaps you’ve made a rational decision, following a cost-benefit analysis, to delay improving the user experience now, so you can more easily improve the user experience later. Very well; but if you ask me, as a user, what priority solving your tech-debt problem has, I can only say “zero”, because that accomplishment in itself does nothing for me. Count it as a cost of doing the things that actually matter, not as itself a thing that actually matters.
Viewed that way, the choice is actually not between the options you list, but rather between “improve usability and the user experience by improving aesthetics / layout / design” and “improve usability and the user experience by improving performance”. I spoke about this choice in the first part of the post; in any case, pick one and do it. If one of those things (but not the other) requires you to fix your tech-debt first, take this cost difference into account in your decision. If both of those things require you to fix your tech-debt first, then go ahead and fix your tech-debt. If neither of those things actually require you to fix your tech-debt first, well, that too is something to factor in…
At this point we’ve already made most of the progress we wanted on the performance and testing framework and the remaining work to be done is roughly on par with the “fix the easier to fix issues”, and hashing out the remainder here feels less valuable than just doing the work. I do think a case could be made that the easier stuff was worth doing first, but we made the decision to switch when it seemed like we’d make more rapid progress on the “easier” stuff after we’d fixed some underlying issues.
I do probably agree with the implied “public beta should have waited another month or something” (though with a caveat that many of the problems didn’t become apparent until the site was actually under a real load)
It felt from the previous couple comments that you felt frustrated about some pattern of interaction but I’m not actually sure which thing you’re particularly worried about. (Also not sure if this is in the scope of things you still wanted to talk about)
Nah, I’m tired of talking about meta / social stuff, let’s leave that alone for a while.
Blunt honesty incoming:
That may be true, when you make this “less blunt honesty!” change to an existing, active community. But when you build a new place, and say “less blunt honesty here!”, the Blunt Honesty crowd feels no creeping dread, but simply shrugs and leaves.
FWIW, this didn’t feel at all like blunt honesty, just regular honesty (although I suppose if you’ve carving things along “did I bother to put a smooth-it-out-nicely filter” vs “did I say something people will be offended by”, I could see an argument for thinking more about the former)
I think, having written this post over several months with evolving views in the meantime… my strongest remaining opinion is:
If you’re going to do the blunt honesty thing, and it seems nontrivial to reword things so people will be less offended, a strong* signal of collaborative building is really important . A community where people criticize and hold each other to a high standard can produce a lot of useful, interesting things. A community where people mostly complain at each other probably will not.
(I also just realized I forgot to include “actually build a thing” along with “brainstorm solutions” and “active listening” in the “how to collaboratively build” section. This was triggered by remembering that when you criticized LW2.0 for font choice etc, you accompanied that with actually making a stylesheet that addressed the issues you mentioned while sticking to the general aesthetic LW2.0 was going for. Which I think was pretty cool)
* by “strong” I mean “strong enough that people feel that you’re fundamentally out to help”, and how much effort it takes to send that signal varies by situation.
This.
You answered that yourself in the next paragraph, in exactly the way I was going to, so I think we’re on the same page here.
My first instinct when I see something being done wrong is to say “this is bad and wrong”. My second instinct is to do it myself. This has worked out well enough for me, all things considered, but it doesn’t scale very well, and a community where the pattern is that the first instinct never gets any results and I have to fall back to the second one all the time, is a community that I quickly come to question to value of participating in. (This is similar to the thing some managers do where if you bring up a problem, you’re assigned to fix it; well, guess what—that disincentivizes bringing up problems. But a web forum is not a job, so instead of keeping quiet, people can just leave.)
(I’ve now alluded to taking my toys and going home two or three times, which puts me in danger of sounding like a histrionic whiner, so I’ll leave this topic of conversation alone now. I just want to mention, before I do, that this being Less Wrong and not some random nowhere place, I don’t actually want to want to take my toys and go home, which is, in fact, the reason I bother to complain or to make custom stylesheets or whatever.)
*nods*
I very much believe “if you can’t actually trust people to take things seriously, then the system is missing a crucial layer of trust.”
The central thesis I’ve been thinking about this year is something like: “there’s a lot of kinds of trust that have to happen at once for a valuable community to work”. These include:
1. trust that people are actually trying to work together to make a good thing
2. trust that when people say they will do a thing, they will do it
3. trust that people will say (and do) things that matter, and if they’re incapable of doing so, level themselves up until they can. (i.e. if you will resolve #2 by never committing to anything… well, maybe that’s a step up but it’s not sufficient).
4. trust people to be aware/introspective enough to not fall into a lot of failure modes
5. you have to trust people at all (i.e. like, not be lying or manipulative)
And all of that trust requires both people to be willing to trust, and also to have the skills and dedication to actually be worthy of that trust.
And, along a number of axis, we are not there yet.
Re: UX/UI stuff
I’m not sure if the “take your ball and go home” thing was mostly relating to UX stuff or other less obvious-to-me things. I do want to:
a) acknowledge that the core dev team hasn’t been as communicative about that as we’d ideally have been, nor taken obvious effort to address it, so from your perspective it’d make sense if we seemed untrustworthy in that regard
b) from our perspective… there’s just a lot of stuff to do. A lot of bugs and core-site-streamlining that seem higher priority, and a lot of people bringing up additional bugs all the time, and time/effort spent on any given thing means not doing other things (this includes responding quickly/adequately to everyone bringing stuff up).
I don’t actually know what advice I’d give a manager of a team that is already strapped for time and working on the most important thing. Or rather: the advice is “put the thing in the backlog and assign it later”, but in a more volunteerish-situation where a) people disagree on what the most important thing is b) people have different skills and interests and people tend to notice things that are more relevant to them...
...I just don’t think there’s much room for improvement beyond “if you want this thing to be a higher priority, you’ll need to contribute work towards getting it done, or at least make a clear case that it is more important than the other things we’re working on instead.”
Re: Bad/Wrong
(phrasing this more bluntly than I normally would since it’s seems like that’s what you prefer)
I think there’s very much an intermediate step between “this is bad/wrong” and “do all the work yourself”, and that’s “communicate that wrongness in a way that feels helpful and collaborative.”
If it’s legitimately effortful to translate your thoughts into that form, and you don’t trust people to actually respond usefully (because they historically haven’t), I think that’s fair. But to actually get from there to “a good, functioning system”, I think it’s both necessary for the people-ignoring-you to put in that effort and for you to put more effort into translating your criticism into ones that pattern-match more to “trying to help” than “complaining/snarking/sniping”
(I personally have to remind myself that you have a track record of putting in effort and changing your mind about things when relevant, because while those things have happened over four years in a significant way, they are less frequent and salient than your average critical comment)
I think overriding the impulse to say “Bad/Wrong” and replace it with constructive substance is one of the core skills necessary for group-rationality to thrive (esp. when running on human hardware, and [possibly] even in more idealized circumstances.
https://www.nngroup.com/articles/aesthetic-usability-effect/
https://www.nngroup.com/articles/first-impressions-human-automaticity/
https://www.nngroup.com/articles/perceived-value/
https://www.lesserwrong.com/posts/6XZLexLJgc5ShT4in/lesswrong-2-0-feature-roadmap-and-feature-suggestions/NPxRanBJhKMMc8nYb
Yeah—I just realized I was conflating a few different clusters of things you said at different times in different contexts in way which was both factually inaccurate as as well as uncharitable. I apologize for that.
I’m not actually sure to what extent we disagree on the object level things here—I definitely believe UX and typography are important, just lower priority than “site loads in a reasonable amount of time” and “get an integration/unit-testing framework in place to avoid mounting tech-debt”. Do you disagree with that?
It felt from the previous couple comments that you felt frustrated about some pattern of interaction but I’m not actually sure which thing you’re particularly worried about. (Also not sure if this is in the scope of things you still wanted to talk about)
Thank you, and apology accepted.
It’s hard to know what to say here; of course the site should load in a reasonable amount of time (this other NN Group article is particularly relevant here)… but…
One thing I could say is—of these scenarios, which is best, and which is worst:
The site loads quickly, and it’s good.
The site loads quickly, but it sucks.
The site loads slowly, but once loaded it’s good.
The site loads slowly, and once loaded, it sucks.
Clearly, #4 is worst. We’d all prefer #1. But suppose we find ourselves at #4, and further find that (by the expenditure of some unit of time/effort) we can move to #2 or to #3—we can’t jump directly to #1. (Then, perhaps, we can take another step, with more time and effort, and make it all the way to #1.)
What I am suggesting is that #3 is the superior first step compared to #2, because (in no particular order):
The aesthetic usability effect (as described in the link above) ensures that poor performance is more readily excused if the site is perceived to be appealing; the reverse is not the case
Poor performance is more readily excused as a transitional-stage effect of a beta development stage than either poor aesthetics or poor usability
A visitor who perceives using the site as having high value but also high cost may retain the mental impression of “value here, but also high cost; questionable for now whether worthwhile” and come back to it (and keep coming back to it) later; a visitor who makes the snap judgment of “little to no value here” leaves and does not return
As per this comment thread, aesthetics and usability can often be (but are not always) easier to improve than infrastructure (i.e., separately from #3 being a better place to be, it’s also easier to get to than #2)
Of course aesthetics and usability and other aspects of UX (like efficiency and effectiveness of task completion) aren’t everything that go into making a site “good” or “sucky”, so what I said above is not the whole story; content, for instance, is largely (though not nearly entirely) orthogonal to both that and to performance per se…
As for “get an integration/unit-testing framework in place to avoid mounting tech-debt”, well, there is much to be said for doing that before starting a public beta; of course there is nothing to be done about this now. (Neither is there necessarily anything to be done about various technical decisions which quite complicate certain sorts of improvement; the fact remains that they do indeed have that effect…)
The problem, as I’m sure you realize, is that I, the user of the site, cannot see your tech-debt. Oh, I may quite clearly see the effects of your tech-debt—or, at least, you say they’re effects of your tech debt; how can I know? maybe some unrelated cause is to blame; I have only your word, here, and anyway it hardly matters why problem X, Y, and Z exists—they do, and that’s that.
So then you do your thing, to avoid mounting tech-debt, and—and what? Is the site now more usable, as a result? More aesthetically pleasing? Can I navigate it more easily? Does it load quicker? Well, no, those things will come, now that you’ve solved your tech-debt problem… but they have not come yet; so from my, user’s, perspective, you’ve spent time and effort and benefited me not at all.
So perhaps you’ve made a rational decision, following a cost-benefit analysis, to delay improving the user experience now, so you can more easily improve the user experience later. Very well; but if you ask me, as a user, what priority solving your tech-debt problem has, I can only say “zero”, because that accomplishment in itself does nothing for me. Count it as a cost of doing the things that actually matter, not as itself a thing that actually matters.
Viewed that way, the choice is actually not between the options you list, but rather between “improve usability and the user experience by improving aesthetics / layout / design” and “improve usability and the user experience by improving performance”. I spoke about this choice in the first part of the post; in any case, pick one and do it. If one of those things (but not the other) requires you to fix your tech-debt first, take this cost difference into account in your decision. If both of those things require you to fix your tech-debt first, then go ahead and fix your tech-debt. If neither of those things actually require you to fix your tech-debt first, well, that too is something to factor in…
Gotcha.
At this point we’ve already made most of the progress we wanted on the performance and testing framework and the remaining work to be done is roughly on par with the “fix the easier to fix issues”, and hashing out the remainder here feels less valuable than just doing the work. I do think a case could be made that the easier stuff was worth doing first, but we made the decision to switch when it seemed like we’d make more rapid progress on the “easier” stuff after we’d fixed some underlying issues.
I do probably agree with the implied “public beta should have waited another month or something” (though with a caveat that many of the problems didn’t become apparent until the site was actually under a real load)
P.S.
Nah, I’m tired of talking about meta / social stuff, let’s leave that alone for a while.