I enjoyed this post but the first example is probably too long and technical for anyone not familiar with poker.
I actually liked the first example being unfamiliar with poker — it was highlighting form not the content.
Person who doesn't know squat about poker here. The first example was clear: they disagreed about whether to fold or call, and it was right on the edge. Especially since where the other player was from was relevant.
It was long for someone who doesn't know poker though.
Thank you for this comment and to others who replied to it. It was something that I was uncertain about and seems like a thing that can help me as a writer if I get better at it, so it's great to get some data points of feedback here.
Here's how I see it. I've got a high context example that is really fitting for the post. It is in theory possible for someone without the context to read through that example, ignore the parts they don't have the context for, and pick up on the large point. I also suppose that it's possible for those without the context to enjoy the dialogue of the high context parts, even if they don't quite understand it.
On the other hand, err, maybe not. Maybe it makes it hard for those without the context to pick up on the main point and to enjoy the dialogue, and the vast majority of readers won't be able to do so,
But in that case, what is the better alternative? The obvious answer there is to use examples that a larger percentage of the audience has the context for. But finding these examples is hard. And I think they're more "forced" compared to examples like the poker one that you actually have personal experience with. I think this "forced"-ness usually ends up showing.
The other thing that I see from Scott Alexander a lot (and now John Wentsworth) is to use like 3-8 examples in total in the post, any of which might be high context, but the hope is that even if a given reader struggles with a couple of examples, they will understand the rest, and understanding the rest would be sufficient. I think I could have done a better job of that here.
Those are the approaches that come to my mind. I'd love to hear if others have further ideas or thoughts/comments/advice.
I think the poker example is OK, and paragraphs like
“The second decision point was when the flop was dealt and you faced a bet. This time you decided to fold. Maybe that wasn't the best play though. Maybe you should have called. Maybe you should have raised. Again, the goal of hand review is to figure this out.”
made sense to me. But the terminology in the dialogue was very tough: button, Rainbow, LAGgy, bdfs, AX, nut flush, nitty - I understood none of these. (I’ve played poker now and then, but never studied it). So keeping the example but translating it a bit further to more widely-used language (if possible) might be good.
But the terminology in the dialogue was very tough: button, Rainbow, LAGgy, bdfs, AX, nut flush, nitty - I understood none of these. (I’ve played poker now and then, but never studied it). So keeping the example but translating it a bit further to more widely-used language (if possible) might be good.
Hm yeah, maybe this exchange was pushing things too much. I'm not sure though.
I thought that even if you don't know the terms, it's clear that they are passionately discussing whether it should have been a call or a fold. I felt like this was sort of important actually. To give the reader a more concrete sense of the sort of disagreement I'm envisioning. And what it looks like at an emotional level. And just how easy it can be to get a sort of "tunnel vision" and get sucked into disagreements like that. I figured that those things would shine through to readers even when the reader doesn't know the poker terminology.
But now I'm feeling more skeptical. Now I'm thinking that it might or might not shine through, depending on the reader and the level of effort the reader feels like applying. It definitely would have been better to choose an example that is more relatable.
I skipped through 90% of the text of this example without it detracting much from the main point of the post. I think it would be better with much less text and with translation of the jargon used.
I personally thought it was slightly distracting. I found myself thinking a lot about the terms (like whether I should know the words already), amd after comcluding no, I barely paid attention to the rest od the dialogue and missed almost all of the nuance. I think hyper specific content works only when it makes sense to the audience or if the lack of understanding is part of the point.
I also suppose that it's possible for those without the context to enjoy the dialogue of the high context parts, even if they don't quite understand it.
That's pretty much where I'm at on it. Although, I have played enough poker that I know all the vocabulary, just not any strategy -- I know what the button is but I don't remember how its location affects strategy, I don't know what a highjack is, but I know the words "flush", "offsuit", "big blind", "preflop", "rainbow" (had to think about it), "fold", etc. etc.
But it's maybe telling that I have played this game, and I found your example flavorful but mostly skimmed and didn't try to follow it. For someone who has never played I think it's just word salad, and probably fails to convey flavor or really anything at all.
EDIT to add: Perhaps to some degree a case of https://xkcd.com/2501/ ?
I enjoyed the overall article, but if it hadn't been curated I probably would have given up at the poker example. (Because I doubt an article where deep familiarity with poker was necessary would have been curated, and so I felt fine skipping over the word salad and looking for the general idea.) The basketball one was easy to understand albeit not really engaging for me, and the code review one felt familiar and easy. It's hard (maybe impossible) to come up with examples that will speak to everyone, so I think having several examples is a good strategy. My only note would be to try to start with whichever example you think will be more engaging for the readers you want to attract. Of the three, I would say that is probably the Basketball one, because it’s the least technical, but this is just a guess. Alternatively, start with some kind of introductory sentence that lets the reader know that what follow are examples of a common theme.
Thank you for that feedback, I appreciate it and find it useful. Given the feedback in the comments, I now feel pretty strongly that the way I wrote that poker section was a mistake. I'm really happy that I learned this lesson though.
Yeah that also makes sense about leading with the example that is most likely to be engaging to readers. Here I feel like that'd probably be the programming example actually, but maybe not since basketball is simple enough to make sense to anyone.
I also agree with the introductory sentence being a good idea. I think I just overlooked that, actually.
Re your second point (score rather than ranking basketball players), Neel Nanda has the same advice which I've found fairly helpful for all kinds of assessment tasks: https://www.neelnanda.io/blog/48-rating
It makes me much more excited for eg 5-star voting instead of approval or especially ranked choice voting.
Just a comment on the code review - whenever I have a disagreement which ultimately I wouldn't want to hold back the merge on, I'll both mark it as a nit, and approve the pull request anyway. If they fix it great, if they don't it doesn't matter, and if they disagree we can have a long chat about that if we want but it's not holding up the merge. Generally I'll do this more with developers I trust not to introduce a new bug fixing the nit, and less with newer less experienced developers.
I tend to get into pointless internet arguments where both parties end up agreeing but in a bitter angry way somehow so I needed to hear this.
As someone that frequently has work reviewed by crossfunctional groups prior to implementation, I only object to change requests that I feel will make the product significantly worse. There's simply too much value lost in debating nitpicks.
I think that is a fine but suboptimal approach. Suppose that the team has a disagreement in a change request but agrees that it is worth an appetite of 10 minutes of discussion. In that case, it is worth having a quick discussion. The problem is when when the discussion goes (way) beyond that, but setting an appetite should hopefully prevent that problem from happening.
In practice it could be difficult to stick to such an appetite even if it's agreed that that is the appetite, so I think the risk of not sticking to it is something that should be factored in.
I also think that the value to such objections is usually mostly about learning for the future. Ie. you may object to some implementation that has a minor immediate affect on the product, but the implementer learns from this and it prevents them from making the mistake over and over again in the future. I think this can be worthwhile even for nitpicks. Ie if a two minute exchange leads to a minor improvement in the implementers code style over the course of the next two years.
Curated. I think this is a generally useful group rationality life lesson, and I know a couple people who've already found themselves directly inspired by this post to take more productive actions in real life.
There was a time about five years ago where I was trying to get good at poker. If you want to get good at poker, one thing you have to do is review hands. Preferably with other people.
For example, suppose you have ace king offsuit on the button. Someone in the highjack opens to 3 big blinds preflop. You call. Everyone else folds. The flop is dealt. It's a rainbow Q75. You don't have any flush draws. You missed. Your opponent bets. You fold. They take the pot and you move to the next hand.
Once you finish your session, it'd be good to come back and review this hand. Again, preferably with another person. To do this, you would review each decision point in the hand. Here, there were two decision points.
The first was when you faced a 3BB open from HJ preflop with AKo. In the hand, you decided to call. However, this of course wasn't your only option. You had two others: you could have folded, and you could have raised. Actually, you could have raised to various sizes. You could have raised small to 8BB, medium to 10BB, or big to 12BB. Or hell, you could have just shoved 200BB! But that's not really a realistic option, nor is folding. So in practice your decision was between calling and raising to various realistic sizes.
Maybe your decision to call was bad. Maybe it was only slightly suboptimal. Maybe it was correct. It is your and your study partners job to figure this out while reviewing hands so that you can improve your game and make better decisions moving forward.
The second decision point was when the flop was dealt and you faced a bet. This time you decided to fold. Maybe that wasn't the best play though. Maybe you should have called. Maybe you should have raised. Again, the goal of hand review is to figure this out.
So far this all just sounds very calm and logical, right? Well, in practice hand review often gets a bit more passionate. It might look something like this (let's assume that someone folds to a big turn bet in a different hand).
Dude, that is a CALL. V's got all of the AX plus the nut flush draws and bdfds. It's too nitty to fold that.
Nah man, I feel good about a fold there. I don't give em the weaker AX hands or the bdfds. Maybe. Idk. Once you remove those hands it becomes a fold though.
I can see that with the weaker AX hands. But the bdfds, they're betting there. It's in their range bro.
I mean, that's assuming they're LAGgy enough. This was an unknown 40 year old so we don't have a history on him, but an unknown 40 year old at Red Rock isn't very LAGgy.
You and your Red Rock. They don't play real poker there. At the Nugget that's a call all day!
Meh, I guess I'd be ok with a call at the Nugget. Not too excited about it though.
I'd be excited about it. They've got the bdfds bro. And I'm pretty confident V is gonna show up with them here at least like 70% of the time.
You're 70% confident in that? How come?
...
This sort of back and forth can go on for hours. And in this particular example, I think that is a bad thing.
Because of the passion? No, not because of the passion. Expression of passion during argument has it's place in life. The problem I have here is that the two poker players are spending a lot of time arguing about something that they basically agree on.
Huh? They agree? One is arguing for a call, the other is arguing for a fold. How is that agreement?
Well, they basically agree. If you read between the lines, the first player thinks that it is just barely a call, and the second player thinks that it is just barely a fold. They agree that the expected values of each option are very similar. It's just a few combinations of hands that they disagree on, namely the weak AX hands and the handful fo backdoor straight draws (bdfds). Think about it as a spectrum instead of a binary agree/disagree type of thing.
This example is actually heavily based off of myself and a friend of mine who I used to review hands with. We would get into arguments like these all the time. We'd end up deep in some terrible rabbit holes, wasting lots of time on incredibly small disagreements.
Eventually we figured it out though. We learned to say "Hey, we are actually very close to agreement here and this isn't a productive thing to debate. Let's move on." This was cool because it led to us spending time on more productive disagreements, like whether or not to call that flop bet with AK in the first example.
My favorite podcast is Thinking Basketball. If anyone wants to submit a motion with the council to revoke my nerd license, I'll understand.
Anyway, the most recent series of episodes on Thinking Basketball has been about who the top 40 players of all time are. This, as you might imagine, is a very contentious subject.
To address this contention preemptively, the host of the podcast likes to point out that we should think about ranges instead of exact spots. For example -- I'm making this up because I don't remember exactly where he put him -- but maybe he penciled in Karl Malone as the 15th best player of all time. You can't really say that 15 is the exact spot with more than a very small amount of confidence. You can, however, say with a solid amount of confidence that Malone is somewhere between, say, the 9th and 21st best player. In other words, you can be confident about the right ballpark, but not the exact spot.
This doesn't stop people from getting upset though. "How can you have Malone at 15 and Kobe at 18?!" Or "How do you have Larry in the top 10 instead of Magic?!" People will argue until they're blue in the face about these sorts of things.
I think that this is similar to the poker example. People see it as binary: you take Larry over Magic, I take Magic over Larry, thus we disagree. Reality is a spectrum though. And once you understand that, you realize that you are actually very close to each other on that spectrum. So close, yet so far.
Programmers do something called code review. It's pretty similar to how poker players review hands, actually. Before merging your code, you submit it for other programmers to provide feedback on, and the other programmers point things out that they think you could improve on.
Like the first two examples, people often run into the situation where they disagree on what would be the best approach, but agree that it is a very close call.
For example, suppose Alice submits code that uses forEach to iterate over a list of names and determine the number of people whose name starts with "A". During code review, Bob proposes that she use reduce instead, because it is shorter, more declarative, and removes the need to track and mutate state.
Throughout the week they go back and forth on this point, discussing it asynchronously in GitHub. They each probably end up spending something like half a workday on it in total. Eventually Alice gives up, thinks that reduce is fine, and implements it using reduce instead.
Until Carol steps in and recommends filter followed by a .length. Carol says that this is simpler while still providing the advantages that reduce brings. Bob disagrees and thinks that reduce is more semantically correct. They discuss this throughout the following week while Alice sits there impatiently, waiting to get her code merged.
It doesn't come up explicitly in their conversation, but Alice, Bob and Carol agree that it ultimately doesn't really matter. This is just one function in one file in one module of a large codebase. It's not a large function or complicated task. Each of the approaches is perfectly fine. The differences in how clear or understandable they are are negligible. Plus, it'll end up being a box that likely won't need to be opened much, if at all. And the differences in performance are even more negligible.
I've been following the company Basecamp for a while. I think that they come out with a lot of cool and useful ideas. One of my favorite ones is the idea of an appetite.
They use it in the context of product development. Say you want to build a sign up form. Typically, the way most companies work, what'll happen is you'll decide ahead of time how the sign up form will look, what bells and whistles it'll have, etc. Then you'll decide on some sort of due date. And then you'll work to get it released by the due date.
Instead of this, Basecamp proposes defining your appetite upfront. Maybe your appetite for a sign up form is two weeks: it's just not important enough to be pushing 4+ weeks on, but it is important enough where you don't want to just push something quick and dirty out after three days. Two weeks is a good sweet spot.
So then, the product and design people give a rough idea of how the functionality could work and what the UI could look like, but from there it's up to the programmers. If they have time they'll get it all done. If not, they'll use their judgment to cut some non-essential things out.
I may have butchered that description of appetites a bit, but it should be roughly correct.
Anyway, I think that this idea of appetites should be applied to disagreements. Consider your appetite for these disagreements. Decide how much time it's worth discussing whether you should re-implement the function using reduce instead of forEach. Whether Magic should be in the top 10 instead of Larry. Whether it is a call or a fold.
I don't want to be so negative though, complaining about this one very specific failure mode where two people get tunnel vision on the binary perspective instead of seeing things as a spectrum, and thus lose sight of the fact they basically agree with one another. That is just one failure mode, and conflating that with the idea of appetites for disagreements would do that idea a disservice.
It is also important to identify the things that are truly important and communicate that you have a large appetite for discussing them. And there's a lot of other things that can be said about this idea of appetites, but I'd like to end things here. At least for now.