Critical Thinking
Tags: pragmatic, programmer, learning, thinking
Published: 2019-11-04 18:01:02

---
title: Critical Thinking
published: true
description: Part of the discussion around points from The Pragmatic Programmer, 20th Anniversary Edition
tags: pragmatic,programmer,learning,thinking
cover_image: https://thepracticaldev.s3.amazonaws.com/i/qsp8qtvb10r7s99hlaug.jpg
series: pragmatic-programmer
---

In a [prior post](https://dev.to/fluffynuts/you-are-what-you-know-25hc) I discussed how we must adopt a permanent learning mindset to be the best we can be in our creative vocations. The article was sparked by a section I'd just read out of _The Pragmatic Programmer, 20th Anniversary Edition_.

Following on from there, the authors discuss critical thinking, most especially when applied to learning, but I think it applies anywhere.

## What is Critical Thinking?

> The application of logical principles, rigorous standards of evidence, 
> and careful reasoning to the analysis and discussion of claims, 
> beliefs, and issues.

As we go through life, we're going to be exposed to a lot of information. Most especially if we're looking for it!

Some of that information is going to be useful. Some of it... not so much.

The idea is that we should be able to split the wheat from the chaff -- to figure out what information is useful, and what isn't.

# How?

We need to ___ask questions___ any time we encounter new information. Most especially if that information contains phrases like "best practices", "cutting-edge" or "enterprise standard".

### 1. The "Five Whys".

This is a trick which we can apply to new information as well as customer requirements to distill down the very essence of the incoming information or request.
Ask "why?". And then, when presented with the answer, ask "why?" again. Do this five times, and you may find that you drill down to the real issue.

Someone tells you that [shiney new framework X] is the best. Ask "why?". And again, until you've gotten to the heart of it.
The customer asks for a feature. Ask "why?". And again, until you understand the real problem. 

Often the customer comes to you with what they have envisioned as the solution, but they don't necessarily have the experience or insight that you do. Asking "why?" five times can help to get to a solution which solves the problem more elegantly than the initial request. Sometimes the initial request will be dropped altogether, once an understanding of the issue is reached: the problem may be operational, not in the software.

### 2. Ask: "Who does this benefit?"

When some technologist or company tells you that some methodology or technology is "best practice", take the time to take a step back. Why are they saying this? Would it simply be in their best interests if everyone thought that their idea was a good one? How much money do they stand (directly or indirectly) to make if everyone started using their technology? Is it really a good idea? Is it sufficiently better than whatever you're currently using to offset the cost of learning and re-tooling?

Just because someone will make money if you adopt their tech, it doesn't automatically make the tech bad (eg Azure, Visual Studio, JetBrains tooling). But if someone stands to make money from the tech, they may not surface anything other than jargon to sell it.

### 3. Ask: "What's the context?"

That methodology or technology which someone is trying convince you is "best practice" may actually be beneficial, _in the correct context_. We should always ask whether the information is relevant to _our_ context. 

Do we really need webpack? Or are a few static HTML pages sufficient? It may be the "cool tech", but we're going to spend time learning and implementing it - and we'll have to keep it updated and relevant. If it _is_ the right tool for the job, then cool! Run with it. But at least think about it first.

### 4. Ask: "Where would this work?"

What are the correct circumstances and timing for this idea to work well? Don't stop with an initial answer (first-order thinking) -- ask again: what happens next? And after that?

If the tech or methodology doesn't lend itself to long-term thinking, you may sink time and effort into it that could be better spent elsewhere.

### 5. Ask: "Why is this a problem?"

Often, someone will try to win you over to their new "solution" -- but what are they actually trying to solve? Is it really a problem? And if it is -- is that problem relevant to your goals?

# "Can" vs "Must"

[The Righteous Mind, by Jonathan Haidt](https://www.audible.com/pd/The-Righteous-Mind-Audiobook/B008O8964Q) was a truly fascinating book for me. I learned a lot about human behavior and gained some insight into my own thought processes.

One of the topics covered in the book is our susceptibility to believing something because we _want to_.

The author explains that, given new information, our sub-conscious can ask one of two questions:

### 1. _Can_ I believe this?

The first is a positive leaning into believing the new information without critical thinking. We're not asking if the information is factually sound, we're asking ourselves if it's possible to believe this information without really testing it.

When someone presents us with a new dirty fact about some politician we despise, we're quick to believe it without asking that question "who benefits from me believing this if it's not true?". 

When someone presents us with some benchmark which shows that our favorite programming language or framework is the best, we're quick to believe it, without questioning the methods of the benchmark. Perhaps BrowserBench _isn't_ a good method for benchmarking devices and operating systems if Safari on an iPhone gets a higher score than Chromium on a 16-core desktop machine (this actually happened). 
Perhaps it's just a good way to compare browsers, _on the same device_ (which means that it's basically useless for any benchmark run on iOS because all browsers on iOS use the webkit renderer, and that renderer is not available for any other OS, so you can't test on other hardware).

I've seen countless people who blindly defend their choice of technology (IDE / editor, operating system, mobile phone ecosystem) without considering other facts for a moment. Newsflash: _everything_ is flawed. iOS isn't better or worse than Android. They're different. Sometimes you win in one ecosystem and sometimes you win in the other. And when and where you win will also depend on _your_ very specific needs. There's no one-size-fits-all.

### 2. _Must_ I believe this?

The second question is more resistive, one which we ask ourselves when presented with new information which _contradicts_ our current belief system or expectations.

When someone presents us with information that shows that the framework or language they prefer is better suited to our development needs, we tend to defend the tech we're using. Because that was _our_ choice and we have _reasons_. We tend to look for holes in the incoming argument so that we can feel justified staying exactly where we are.

The second kind of thinking is critical thinking -- we're examining the incoming information more critically to find a reason _not to believe_. The trick here is to remain _honest_ with yourself: examine the incoming information for pros _and_ cons. Look for the good _and_ the bad. Then weigh up all the information you have: the incoming information about the tech you're not using, and the information you have about the tech you're using. If there's a point where you can't make a comparison because you don't have enough information, _seek out that information_. Don't just say "well, I use Angular, where I can do [X]". Actively go do some research to find out if you can accomplish that in Vue or React or whatever you're evaluating.

And once you have a clear picture of the new information in the light of what you already know, make a decision as to what to do about it:

1. Perhaps the new thing isn't as good as people have been telling you. Discard it.
2. Perhaps the new thing is good, but your existing things are equally good (overall) and re-tooling isn't worth it.
3. Perhaps the new thing is _really_ good, but not good enough to force you to rewrite what you have (please don't fall into the rewrite trap! that's why Duke Nukem Forever took a decade to be released!). But you could put it on the list of things to try on the _next_ project.
4. Perhaps the new thing blows your existing tech out of the water. Great! Figure out a migration plan, and take that on bit by bit. "Eat the elephant".