Think Again

I went to an Agile Denver meeting in January. My friend Tricia Broderick was there. We had an interesting conversation at our table about dealing with difficult people. I'm sure you are familiar with the situation. You want to introduce a new tool or technique. Maybe that is source code control, unit testing, CI/CD, pair programming; it doesn't matter the tool or technique. There is always someone who resists it for whatever reason. Sometimes they have good reasons, sometimes it's simply inertia and resistance to change. What do you do?

My initial thoughts revolved around curiosity. Why are they resisting? Is it simply inertia or is there more there? What are they really concerned about? Have I done a good enough job selling the idea? Is the idea even appropriate?

Logic Bombing

Tricia brought up a different idea. She mentioned something called Logic Bombing, which I hadn't heard of. Logic bombing is when you just flood the other person with all the reasons why you are right and they are wrong. You see this all over the place, particularly in politics. If you have ever tried to point out to a MAGA all of Trump's moral, business, foreign policy, and economic failings, you've realized that it makes no difference. In fact, the more logic and facts you throw at them, the more entrenched they become. You are logic bombing them.

We think the more reasons we have behind our argument, the better. In reality, logic bombing doesn't work for several reasons. First, all the person has to do is find fault with one of your arguments. It doesn't even have to be that the argument is wrong, simply that you exaggerated (maybe you simply rounded up) or got a tiny detail wrong, even an inconsequential one. Once they find that, they can latch onto that and dismiss all your arguments. You are wrong about one thing, therefore, you must be wrong about everything. Also, it weakens your best arguments. You are spreading your effort, and the weaker arguments detract from the stronger ones. You are much better off focusing on fewer points and making a strong case for each one. Think quality over quantity.

I found this quite fascinating, particularly dealing with MAGA people lately. So I was intrigued to learn more about it. Tricia recommended a book called "Think Again" by Adam Grant. I immediately got a copy and read it.

Changing your Mind

The point or thesis of the book is that changing your mind is ok. In fact, we should encourage it more. He lists a couple of archetypes:

• Preachers - convinced that they are always write and always proselytizing
• Politicians - always trying to be popular instead of accurate
• Prosecutors - always trying to point out others' flaws
• Scientists - always experimenting and trying to discover the truth

The goal of the book is to get the reader to think more like a scientist and reexamine their beliefs regularly, and spend less time acting like one of the other archetypes.

I've written before on this blog about how it is ok to cringe when looking at your old code because that means you've learned something and grown since you wrote it. I've grown and learned a lot since I first started writing software. My practices now are much different from what they were when I started. I am always looking for new and better ways to do things.

Performance Culture Versus Learning Culture

The book talks quite a bit about NASA and some of the accidents they've had over the years. It makes the point that the culture there was based on performance versus learning. This caused them to miss a lot of things that might have averted some of their major disasters. I did an interview Kyle Griffen Aretae a while back, talking about optimizing for learning. Think Again reinforces that.

Talking to People You Disagree With

One point the book makes is that it is important to talk to those who disagree with you, particularly those who challenge your beliefs. That's not too hard to do in the LabVIEW Community, since there are lots of people with lots of different opinions. If you talk to them, you find out that usually there is a good reason for them doing things the way they do. Sometimes it makes you question the way you do things, which is exactly the point of the book.

Best Versus Better Practices

In my conversation with Joerg on the podcast, we talked briefly about the idea of better practices. The worst thing about best practices is that it implies there is an endpoint. Do this one thing and then everything will be fine forever and you'll never have to change the way you do things again. That's just not realistic, particularly working in the technology field where every few years, things change out from under you.

Judging Decisions

Also, throughout the book, the author talks about how we judge decisions. He comes to the same conclusion I've come to after years of rock climbing and mountaineering. You can't judge the quality of a decision based on the outcome. You can make great decisions and be unlucky or make horrible decisions and still somehow survive. You can only judge decisions based on what you knew at the time, and also the process you went through to make that decision. Did you run down every lead? Did you question your assumptions? etc.

Alignment

This book is very much aligned with how we work here at SAS Workshops and how we view software development. Software and business are both iterative processes. We are constantly experimenting, amplifying what works and getting rid of what doesn't. If you think like us, you will definitely enjoy this book.