The Two Kinds Of Technology Thinkers
Edward de Bono had his “Six Types of Thinking” hats to describe the different kinds of thinking that go into solving problems. Those are great, but there are two kinds of thinking happens on every technology team that are far more important: Platonic thinking and Pragmatic thinking.
Although most folks use both types of thinking, people have a favorite they rely on when problem-solving. It’s important to know what your “default setting” is. It’s also important to call out and identify each type of thinking as it’s used. Both types have both huge benefits and huge drawbacks.
Platonic thinkers like to think of things in the abstract, in their pure form. They’re conceptual thinkers and work with the pure and generic form of things, the way they should be. Once they oriented themselves in the abstract, they take what they’ve learned and try to make it work with real things.
Pragmatic thinkers may never orient themselves. In fact, some resist the idea that orienting yourself against abstractions is even a laudable goal. Instead, they think of things in the concrete, cause and effect. If under these circumstances I do this one thing? This other thing seems to happen a lot. I don’t know why. I probably don’t even have time to figure it out. I can use that implied causal relationship to make the other thing happen. Now I can move to the next problem.
Ever get excited about a new software platform, download and install it, only to have popular things work without a hitch and oddball things totally flake out? If so, you’ve been a victim of Platonic thinking. The general idea was good. The concepts are in place to do a great number of useful things. It’s just the actual application of those cool ideas was limited to things the developers thought were most important. What you have is a beautiful system of organization that looks like it might work but not all the little pieces required to prove that it actually does work.
Ever work with a piece of code that’s been around so long that nobody knows exactly what it does? Somebody asks for something trivial, like a new field on a report, and the team estimates it might take six months. Six months! What you have is a bunch of little pieces that all work separately that aren’t organized into anything that’s easy to understand and maintain.
You find this kind of thinking everywhere, not just in tech teams. Pick up some political essays about any random topic from any year in past. Some essays will argue platonically: these are our values, these are the reasons for these things existing, these reasons come together in this way to create/limit another high-level concept. Some essays will argue pragmatically: We do this certain set of things because they fix these other things. No, they are inconsistent with one another, but they’ve been working up until now. Sometimes we’re not even sure why they work, but they do.
There is no right or wrong way of thinking. It’s important to be able to use both of them seamlessly when working with systems of any complexity. As an example, in TDD and OO code, we first start with a pragmatic question: what’s the smallest thing that we want this thing to do? Then we write a test. Then we make the test pass. Finally we refactor, making sure everything is in the right place. We’ve started pragmatically and moved to platonic thinking once we’ve established value.
Oddly enough, there are all sorts of problems trying to do it backwards, starting with platonic ideas of what your code “should” look like, what the pure and perfect form is, then moving to the nuts and bolts of things. Back when I first started OO I managed to do it several times, but more often than not working from platonic to pragmatic ends up with architecture astronaut syndrome and software that promises everything for everybody and ends up doing almost nothing for a very few people.
I’m no master of functional programming, but I suspect in true functional programming this pattern might be reversed. First we ask the platonic question, what’s the smallest/simplest structure/types that support the next thing we want to do? Then we ask the pragmatic question, how can I make that work without increasing code paths? (Run from the ZOMBIES!). Finally we get extremely pragmatic by covering our code paths with tests.
We get the word platonic from the Greek philosopher Plato. Plato believed in a universal set of truths. There is a chair. There is another chair. There exists a universal idea of “chair” that all chairs reflect. It is this universal set of ideas where truth lies. Everything else, all that we see, are merely shadows of that universal truth.
Plato’s top student, Aristotle, disagreed. He was more concerned with things in the real world, watching them, understanding them, creating catalogs of what he saw. He was more concerned with understanding each thing he experienced than speculating on what the universal pure form of something might be. And if he kept organizing his thoughts as worked, didn’t he end up in basically the same place Plato was, only he gets there from the bottom-up instead of the top-down?
So when you have these conversations, you are not the first. You are not alone. This conflict has been going on since the dawn of recorded history. I’ve always said that creating technology is applied philosophy. You walk into a new domain. You have to understand it and the people who live there. You have to take that understanding and create a workable and provable set of hypotheses that drive out an executable theory of operations to deliver real value. Then you code it and begin the science of “making and keeping users happy” that’s different for every domain/product pairing.
When creating a new science, both kinds of thinking are critical. Don’t get stuck in a rut — and always remember the weakness of whichever one you’re currently using.
Hi, I’m Daniel Markham. I wrote a book called Info-Ops that talks about how to have conversations and organize what we’re doing so that we build the right thing without a lot of the usual BS. As it turns out, looking at what we do from an information standpoint tells us a lot more than simply talking about what activities people do every day or how various tools are configured or used.
June 13, 2018