In a prior post 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 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".