[SEQ RERUN] Hold Off On Proposing Solutions
Today’s post, Hold Off On Proposing Solutions was originally published on 17 October 2007. A summary (taken from the LW wiki):
Proposing Solutions Prematurely is dangerous, because it introduces weak conclusions in the pool of the facts you are considering, and as a result the data set you think about becomes weaker, overly tilted towards premature conclusions that are likely to be wrong, that are less representative of the phenomenon you are trying to model than the initial facts you started from, before coming up with the premature conclusions.
Discuss the post here (rather than in the comments to the original post).
This post is part of the Rerunning the Sequences series, where we’ll be going through Eliezer Yudkowsky’s old posts in order so that people who are interested can (re-)read and discuss them. The previous post was The Logical Fallacy of Generalizing from Fictional Evidence, and you can use the sequence_reruns tag or rss feed to follow the rest of the series.
Sequence reruns are a community-driven effort. You can participate by re-reading the sequence post, discussing it here, posting the next day’s sequence reruns post, or summarizing forthcoming articles on the wiki. Go here for more details, or to have meta discussions about the Rerunning the Sequences series.
Proposing solutions is so tempting, not even lukeprog can resist it on occasion.
I nearly replied to this with “We need a community norm of downvoting posts that immediately propose solutions.” But then I figured out what would be the first post that norm would be applied to.
Let’s discuss the problem of LessWrongers immediately proposing solutions. Why do people propose solutions before discussing the problem?
Sense of urgency makes it harder to apply learned-but-not-grokked heuristics like “discuss, then solve”.
They think of a possible solution immediately, and don’t want to risk forgetting it, or someone else proposing their solution and getting credit.
They expect to gain status for solving, not for proposing discussions of, problems.
They think “hold off on proposing solutions” applies to some limited domain of problems only.
This is the biggest problem of these, and needs a solution even in the cases you end up not proposing solutions since many useful solutions are forgotten this way.
So, I gotta ask. Did you intentionally, knowingly respond to “Why do people propose solutions before discussing the problem?” by proposing a bunch of solutions?
Cause I already made that joke, just sayin’.
Edit: Lemme put it this way: I propose the solution is that LWers simply don’t know how to discuss problems without proposing solutions.
Editedit: …Oh. Right. Oops.
Obvious mistake is obvious in retrospect, and frankly I should have extended a little more benefit of the doubt to Alicorn of all people. Er. Sorry?
A solution in this context refers to a proposed course of action to correct the problem. Alicorn’s answers are explanations for the problem, not solutions.
What JGWeissman and MinibearRex said. Be careful in tracking the recursion depth! Remember, there’s:
1) Prematurely proposing solutions
2) Discussing the various aspects of a problem before proposing solutions
3) Prematurely proposing solutions to the problem of 1)
4) Discussing the various aspects of the problem of 1) before proposing solutions thereto
Alicorn was on 4 (EDIT: or 2?), not 3 -- and 3 would have indeed been a bad idea.
Edit: Oops, this probably should have been posted as a direct reply to pedanterrific.
Alicorn didn’t actually propose solutions to the primary question: “What we should do in order to ensure that LWers discuss the problem thoroughly?” She proposed solutions to the sub question: “What mechanisms could cause people to propose solutions before discussing the problem?” I tend to view this process as a way of identifying the constraints on a problem before actually tackling the problem itself. If proposing constraints counts as something that we’re not allowed to do (until we establish the constraints on our constraints?), we wind up with an infinite recursion.
Because if I don’t propose my solution then someone else will propose their solution first. That not only gives them a strengthened social position but may prevent me from enforcing a solution that benefits me.
The only observation I think I can add to the previous discussion of status (although no one mentioned it in an evolutionary context), is simply the fact that commenters on LW are not having face to face conversations. Because it takes hours for someone to respond to a comment, actually discussing the problem as thoroughly as you could in five minutes of conversation would take weeks on LW! So, I think the people who actually try to consider, then solve the problem likely do it on their own, sitting in front of the computer monitor, before typing up their post.
I propose the solution is “because status”.
Contrarian!
That would ironically be a solution proposed without prior discussion.
Which is what Oscar mentions (in the immediately following sentence) that he realized.
It can be dangerous. On the other hand, like a proposed hypothesis, a proposed solution can give you a framework to help you analyze the data.
There are significant limitations on human thought. One of them is a serious limitation on how much data we can handle at one time. Having a framework to relate more information to helps manage that problem. One way to reduce the dangers of having a proposed solution is to force yourself to come up with multiple possible solutions.
This sort of iterative problem solving is how almost all real world problems of any complexity are addressed. For a practical example, when I was working for an architect, we would come up with several designs which addressed the clients goals and the physical and other resources available, then we would choose the best and refine it, adding features from other designs that worked better, with feedback from the clients and from further information about the pre-existing conditions and resource availability. There is literally no possible way to have “solved” even a moderately complex design problem other than iteratively.