Rethinking Problem Solving: Starting with Feelings and Problems

Three months ago, I splurged on a ridiculous, and ridiculously expensive, gadget. It’s called ReMarkable, and it does one thing: take notes. I figured it would augment my current habits, not change them. Thanks to ReMarkable, I was hoping to read more articles and take better notes. My expectations shifted after my first day with […]

Three months ago, I splurged on a ridiculous, and ridiculously expensive, gadget. It’s called ReMarkable, and it does one thing: take notes. I figured it would augment my current habits, not change them. Thanks to ReMarkable, I was hoping to read more articles and take better notes. My expectations shifted after my first day with the device. Instead of taking notes with it, I started drawing on it to visualize my thoughts. In doing so, I took the first step toward changing my problem-solving methods. The Remarkable kicked off a transformation in my thinking that was a long time coming.

The Current Problem Solving Primitives

A year ago, when I started at Atomic Object, I figured the key to my success was technical. By memorizing the Formik docs and knowing React like the back of my hand, I’d win the day.

I should have known better. Here at Atomic Object, our title is, “Software Consultant and Developer” for a reason. To succeed at Atomic, you don’t need to know the flashiest new tech. Much more important is knowing when to use said tech and when not to.

This brings me to the crux of the article (and Remarkable). When we imagine problem-solving, we often think of the tools first. If we need state management, we race to the Redux docs (hopefully). If we need a package manager, we comb the Yarn docs.

Most times, our first reaction to a problem is to start typing, Googling, and stubbing out code. Yet as I’ve found countless times, these technical facts are the wrong problem-solving “primitives.”

The real primitives of problem-solving are not the tools we choose. The real primitives in the hypertechnical world of computer science are thoughts and feelings. That’s because, in the end, software is a specialized form of problem-solving. And the real challenge with problem-solving is to find the right problem and match it with the right solution.

Writing your feelings helps to find the right problem (not the most urgent one). Writing about the problem helps to find the right solution (not the first one).

Writing About Feelings

When we humans, even developers, get lost in our emotions, it’s hard to find the right problem to solve.

A grid with 4 quadrants: urgent and important, urgent and not important, not urgent and important, and neither important nor urgent.
The Decision Making Matrix from the 7 Habits of Highly Effective People by Stephen Covey.

The problem with getting lost in emotion is that we can get urgent and important flipped in our minds. By writing down our emotions, we can sort through this quandary to get to the right problem. Before we do any real problem solving, we need to get our emotions in order so we solve the right problem, not the urgent one.

Writing About the Problem

In our first step, writing our emotions, we shifted gears into our more reasoned state. Here, we have the potential to solve problems with thoughtful solutions, not knee-jerk reactions. Note that I said “potential.” Even when we are calm and more reasoned, we still have a bias to beware of.

We tend to zoom in on a solution, often the first one we think of, and lose sight of the problem. This tendency is natural (and useful). After all, when running from a tiger, it doesn’t pay to hesitate. The problem is, that when designing an architecture, it does. Our brain’s default mode is to use our intuition to jump to quick solutions.

Solutions Focus

The focus on solutions, and specifically our first solution, is natural. While this focus is natural and often useful, it can be harmful. Many of the technical problems we face daily have counterintuitive solutions. In my work, the solutions I end up with are far from the first one I considered.

What we need to effectively solve problems then, is to iterate multiple times on a single problem.

Problem Focus

To iterate effectively, we need:

  • The ability to hold multiple solutions in mind (to avoid the first solution problem)
  • The ability to clearly visualize the solutions (to compare and contrast)

Why Writing?

Job Crafting Map
A perfect example of the utility of writing about a problem to better visualize it from Elaine’s great post, Job Crafting, about how to solve career FOMO.

First, our working memory, which limits how many items we can hold in our head, is small. Most agree we can keep at most seven items in it at once. Further, it’s prone to distraction, which resets it. By putting our potential solutions on paper (or a Remarkable), we are able to hold both the problem and the potential solutions in mind.

Second, visualizing the possible solutions helps us to compare and contrast them. While computers can help with our working memory problem, most are not flexible enough to visualize problems. For now, the written medium allows us to mock out solutions to imagine how they might work.

Problem-Solving in a Nutshell

Instead of technical primitives, we need human primitives when we solve problems. Software is nothing but a specialized version of problem-solving. To do it well, we need to deal with our emotions and zoom in on the right problem. Then, we need to write about solutions to visualize all the ones we can come up with (not just the first one).

Reference

I wrote this article then realized I’d forgotten to include the inspiration for it. While much of the inspiration does come from Remarkable, I must give credit to an article I read using my Remarkable as well. Thought as a Technology by Michael Nielson inspired this article with its fascinating discussion of new primitives for the emerging field of Intellectual Augmentation, the unknown sibling to the buzzword that is Artificial Intelligence (AI).

The post Rethinking Problem Solving: Starting with Feelings and Problems appeared first on Atomic Spin.


Source: Atomic Object