Consider your appetite for disagreements

post by Adam Zerner (adamzerner) · 2022-10-08T23:25:44.096Z · LW · GW · 18 comments

Contents

  Poker
  Basketball
  Code review
  Appetite
None
18 comments

Poker

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.

Basketball

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.

Code review

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 [LW · GW] that likely won't need to be opened much, if at all. And the differences in performance are even more negligible.

Appetite

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.

18 comments

Comments sorted by top scores.