1. 36
  1. 12

    This technique is good for making quick decisions – the “Not the hill I want to die on” method.

    I like the “switch” method a lot too – if two of my developers are having an argument over something, I simply call out a switch, and they do a good faith best argument of the other persons position. If they can’t make a coherent argument for the others persons view, they (generally) don’t actually understand it. This rather quickly leads to either (1) one person admitting they really aren’t listening or understanding the other persons point, and our policy is then you STFU until you do, or (2) one person realizing that their side of the argument is weak, and waving the surrender flag. I try to encourage disconnection from ideas after you put them out there – so as to make surrender a less painful thing, but egos are egos.

    Doesn’t always work – I have seen neither change their mind, and in a few rare cases – both change their mind, and in those cases you can ask the question “Who is willing to die on this hill?” Only once in my career have I had two people both say they would bet their job that they were right and the other guy was wrong.

    1. 3

      reminds me of the saying “you are not your thoughts”

    2. 8

      I find that young engineers tend to argue a lot more about these kinds of points than older engineers. Maybe some of that’s due to youthful passion, but I think that mostly it’s because older engineers have realised that many of these fights aren’t worth having - or in the author’s words that they only care 2/10 on the subject.

      1. 3

        Indeed!

        Age has lead me to conserve both time and energy, so rather than flail at any given target with wild abandon, I must now choose my battles carefully. I’m collaborating with a few people on a pet project, and as we’re all roughly middle-aged we tend to not sweat the details so much as keep things moving. Anything that slows us down ends up getting revised.

        1. 1

          FWIW that’s not been my experience. If anything the older engineers I’ve worked with have held more polarized views, not less.

        2. 6

          I really like the message of this post. I don’t know about you mob, but I could certainly stand to start thinking a little more about how important I really think a decision is one way or the other.

          1. 4

            I liked this article quite a bit, and as a result of reading it early this morning, used exactly the strategy described to head off an argument later this morning at work. A very good, quick sanity check when a discussion begins to tip into an argument.

            1. 4

              A couple years ago I adopted a similar position of picking my battles. It mostly came from exhausting myself in discussions with designers / product managers who acted like “everything is top priority”. So I started asking people to group their requests in high, medium and low priority, and told folks that I would work on the high priority first, the medium after that, and the low priority stuff if I get time.

              People who refused to do that were informed that if they prioritized everything as “top priority” that their requests would be completed in random order, according to my whim.