5 ms·

I had a boss who liked to use a similar idea, but with a twist; he'd sometimes repeat the idea back but intentionally get a key nuance wrong, with the intention

by saghm 3y ago

I had a boss who liked to use a similar idea, but with a twist; he'd sometimes repeat the idea back but intentionally get a key nuance wrong, with the intention of getting feedback on that part. If the person corrected it, he'd be much more confident in both his own and the other person's understanding of the idea. If they didn't, he'd dig in more to figure out why his original understanding was actually _not_ correct. The idea behind this was to look to _disprove_ what he thought he understood rather than to confirm it; he would only feel confident in his mental model if he couldn't disprove it after exhausting all of the ways he could think of. His strategy was pretty effective, from what I could tell; he'd often uncover subtle flaws or questionable assumptions in ideas or plans where he was not as knowledgeable in the domain as the person presenting it due to not only being willing to say something incorrect, but going out of this way to embrace it. Importantly, this was never used as a way to try to trick or test people; he would never criticize anyone for failing to correct him when he said something wrong, because the whole point of the technique was that he wasn't even sure whether he needed to be corrected or not, and he was still trying to figure it out.

obeavs 3y ago
Smart play, but hard to do in the moment. Sounds like a sharp guy.
avianlyric 3y ago
Veritasium has a great video[1] about people’s cognitive bias towards using examples that prove their mental model, rather than using examples that disprove their mental model. But if you want to actually confirm you have accurate understanding of something, testing examples that don't fit your metal model is the workable methodology (i.e. use a null hypothesis). Testing examples that do match your mental model only proves your model partially matches the actual model, but it does very little to actually identify misunderstandings, or improve your understanding. [1] https://youtu.be/vKA4w2O61Xo https://youtu.be/vKA4w2O61Xo
- jerf 3y ago
  It's a common programming error too. I often see automated test cases that only test the happy path, but you ought to test that errors error the way you expect and desire too. These tests fail the first time I run them as often as the happy path cases do.
  - Spivak 3y ago
    This to me gets to the fundamental nature of testing. If errors are part of your test suite then they're happy path too. It's just as much a part of your API surface as any other return value. But if you don't have (or want) callers that depend on your specific behavior in error situations then I wouldn't bother testing them. It's my contract that I can and will change the behavior arbitrarily and you can't be mad at me for it.
- Stratoscope 3y ago
  So many great videos on Veritasium, and that is one of my favorites. Anyone who is not familiar with the channel should check it out. Of course, there is this counterpoint... https://www.youtube.com/watch?v=cY_o4A1wzsg https://www.youtube.com/watch?v=cY_o4A1wzsg
- op00to 3y ago
  I was taught to use the null hypothesis in a US high school science lesson on the scientific method in the 90s. It never clicked to me “why” until your explanation. Funny how that stuff works.
- cxr 3y ago
  Previously: "A Quick Puzzle to Test Your Problem Solving". 2015 July 2. 288 comments. <https://www.nytimes.com/interactive/2015/07/03/upshot/a-quick-puzzle-to-test-your-problem-solving.html https://www.nytimes.com/interactive/2015/07/03/upshot/a-quic...> You'll need to paste this snippet into the JS console in your browser (or make a bookmarklet out of it and click it in order to reveal the article) because something on nytimes.com has caused it to break at some point in the last 8 years: document.querySelector(".g-result.g-noText").style.display = "block" HN comments: <https://news.ycombinator.com/item?id=9818310 https://news.ycombinator.com/item?id=9818310>
stavros 3y ago
Can you elaborate a bit? I don't understand how this is useful if, for example, someone says "we should add a nullable field and then create a migration" he'd say "you're saying we should add a non-nullable field and create a migration"? Why would someone not correct this?
- Retr0id 3y ago
  I think this approach is mainly for more complex ideas. To expand on your example, it might be something more like "our 99th percentile page loads are slow due to high widget view hydration latency. We can reduce the cost of hydration by caching greeble status in the the widget table. We should add a nullable field and then create a migration." To which, the reply might be roughly the same but ending with "We should add a nullable field to the greeble table and then create a migration." If the proposer is paying attention, they might say "no no, the new field has to go in the widget table." The goal isn't to catch someone out, but to make doubly sure you've reached a shared understanding.
  - stavros 3y ago
    Hmm, that makes more sense, but I still don't see how these factual errors could go uncorrected. I can see how this might be a measure of attention, but I don't understand the "disprove my assumptions" aspect of it.
    - Retr0id 3y ago
      If you repeat what you think is a 100% correct version of the information, and the other person nods along, you can't be very sure whether they're just passively agreeing because they zoned out or if you were actually correct. It's a bit like writing unit tests that fail, before you implement the change that'll make them pass.
      - mitthrowaway2 3y ago
        It seems you also agree with stavros that this strategy seems more like a test of attention, then?
norir 3y ago
I personally prefer a direct strategy: state that you don't understand and what your (possibly) unenlightened concerns are. Or ask something like, "that sounds good, but what are we missing that might cause someone to be paged at 3am?"
greenie_beans 3y ago
i like the repeat back but i would hate this. what if the person doesn't feel comfortable correcting them? just so many ways this could go wrong. not to mention it's dishonest and manipulative. management is already manipulative in a way, but this is crossing the line.
- StevePerkins 3y ago
  If it's a junior developer, then they really shouldn't have too much responsibility without heavy supervision anyway. If it's a senior developer, then they should feel comfortable speaking up when there's a disconnect or misunderstanding. I would argue that one trait is the overwhelming majority of what separates a senior developer from a junior one.
  - watwut 3y ago
    > If it's a senior developer, then they should feel comfortable speaking up when there's a disconnect or misunderstanding. I would argue that one trait is the overwhelming majority of what separates a senior developer from a junior one. Whether seniors feel confident to correct the manager depends primary on how manager acts when corrected. There are many managers who don't get corrected by seniors and seniors who do learn not to do that - either becabuse it is useless or will be punished. Either way, juniors do talk with management fairly often, whether they have responsibility or not.
    - TrololoTroll 3y ago
      I could not agree more Seems like it'll always be the case that people will chuck the responsibility for X towards people with the lowest capacity to actually be responsible for X People feel fine with correcting managers when managers reward being corrected instead of punishing it. That's got nothing to do with seniority levels
  - greenie_beans 3y ago
    > If it's a senior developer, then they should feel comfortable speaking up when there's a disconnect or misunderstanding. I would argue that one trait is the overwhelming majority of what separates a senior developer from a junior one. this is just idealistic and doesn't acknowledge the power dynamics in any organization, nor does it factor in peoples' individual personality traits.

by saghm 3y ago

obeavs 3y ago

Smart play, but hard to do in the moment. Sounds like a sharp guy.

avianlyric 3y ago

Veritasium has a great video[1] about people’s cognitive bias towards using examples that prove their mental model, rather than using examples that disprove their mental model. But if you want to actually confirm you have accurate understanding of something, testing examples that don't fit your metal model is the workable methodology (i.e. use a null hypothesis). Testing examples that do match your mental model only proves your model partially matches the actual model, but it does very little to actually identify misunderstandings, or improve your understanding. [1] https://youtu.be/vKA4w2O61Xo https://youtu.be/vKA4w2O61Xo

jerf 3y ago
It's a common programming error too. I often see automated test cases that only test the happy path, but you ought to test that errors error the way you expect and desire too. These tests fail the first time I run them as often as the happy path cases do.
- Spivak 3y ago
  This to me gets to the fundamental nature of testing. If errors are part of your test suite then they're happy path too. It's just as much a part of your API surface as any other return value. But if you don't have (or want) callers that depend on your specific behavior in error situations then I wouldn't bother testing them. It's my contract that I can and will change the behavior arbitrarily and you can't be mad at me for it.
Stratoscope 3y ago
So many great videos on Veritasium, and that is one of my favorites. Anyone who is not familiar with the channel should check it out. Of course, there is this counterpoint... https://www.youtube.com/watch?v=cY_o4A1wzsg https://www.youtube.com/watch?v=cY_o4A1wzsg
op00to 3y ago
I was taught to use the null hypothesis in a US high school science lesson on the scientific method in the 90s. It never clicked to me “why” until your explanation. Funny how that stuff works.
cxr 3y ago
Previously: "A Quick Puzzle to Test Your Problem Solving". 2015 July 2. 288 comments. <https://www.nytimes.com/interactive/2015/07/03/upshot/a-quick-puzzle-to-test-your-problem-solving.html https://www.nytimes.com/interactive/2015/07/03/upshot/a-quic...> You'll need to paste this snippet into the JS console in your browser (or make a bookmarklet out of it and click it in order to reveal the article) because something on nytimes.com has caused it to break at some point in the last 8 years: document.querySelector(".g-result.g-noText").style.display = "block" HN comments: <https://news.ycombinator.com/item?id=9818310 https://news.ycombinator.com/item?id=9818310>

stavros 3y ago

Can you elaborate a bit? I don't understand how this is useful if, for example, someone says "we should add a nullable field and then create a migration" he'd say "you're saying we should add a non-nullable field and create a migration"? Why would someone not correct this?

Retr0id 3y ago
I think this approach is mainly for more complex ideas. To expand on your example, it might be something more like "our 99th percentile page loads are slow due to high widget view hydration latency. We can reduce the cost of hydration by caching greeble status in the the widget table. We should add a nullable field and then create a migration." To which, the reply might be roughly the same but ending with "We should add a nullable field to the greeble table and then create a migration." If the proposer is paying attention, they might say "no no, the new field has to go in the widget table." The goal isn't to catch someone out, but to make doubly sure you've reached a shared understanding.
- stavros 3y ago
  Hmm, that makes more sense, but I still don't see how these factual errors could go uncorrected. I can see how this might be a measure of attention, but I don't understand the "disprove my assumptions" aspect of it.
  - Retr0id 3y ago
    If you repeat what you think is a 100% correct version of the information, and the other person nods along, you can't be very sure whether they're just passively agreeing because they zoned out or if you were actually correct. It's a bit like writing unit tests that fail, before you implement the change that'll make them pass.
    - mitthrowaway2 3y ago
      It seems you also agree with stavros that this strategy seems more like a test of attention, then?

norir 3y ago

I personally prefer a direct strategy: state that you don't understand and what your (possibly) unenlightened concerns are. Or ask something like, "that sounds good, but what are we missing that might cause someone to be paged at 3am?"

greenie_beans 3y ago

i like the repeat back but i would hate this. what if the person doesn't feel comfortable correcting them? just so many ways this could go wrong. not to mention it's dishonest and manipulative. management is already manipulative in a way, but this is crossing the line.

StevePerkins 3y ago
If it's a junior developer, then they really shouldn't have too much responsibility without heavy supervision anyway. If it's a senior developer, then they should feel comfortable speaking up when there's a disconnect or misunderstanding. I would argue that one trait is the overwhelming majority of what separates a senior developer from a junior one.
- watwut 3y ago
  > If it's a senior developer, then they should feel comfortable speaking up when there's a disconnect or misunderstanding. I would argue that one trait is the overwhelming majority of what separates a senior developer from a junior one. Whether seniors feel confident to correct the manager depends primary on how manager acts when corrected. There are many managers who don't get corrected by seniors and seniors who do learn not to do that - either becabuse it is useless or will be punished. Either way, juniors do talk with management fairly often, whether they have responsibility or not.
  - TrololoTroll 3y ago
    I could not agree more Seems like it'll always be the case that people will chuck the responsibility for X towards people with the lowest capacity to actually be responsible for X People feel fine with correcting managers when managers reward being corrected instead of punishing it. That's got nothing to do with seniority levels
- greenie_beans 3y ago
  > If it's a senior developer, then they should feel comfortable speaking up when there's a disconnect or misunderstanding. I would argue that one trait is the overwhelming majority of what separates a senior developer from a junior one. this is just idealistic and doesn't acknowledge the power dynamics in any organization, nor does it factor in peoples' individual personality traits.