8 Basic Problem Solving Techniques from “Think Like a Programmer”

In the never-ending quest to become a better Python coder, there are plenty of resources to read, digest and internalize. Too many.

Honestly, learning to code feels like trying to drink the ocean. Where do you start? And is it crazy to even try? At the end of the day, all you can do is take it one gulp at a time.

I’ve encountered many ups and downs on my journey so far. Still progressing on the python track on exercism.io, have stalled out on Automate the Boring Stuff, and have had a dozen small and big revelations in the middle of it all.

After one particular bout of frustration, I began to feel like I needed to get back to basics. How does a programmer think? And how is that different from the way I’m tackling these problems? And why is my approach sucking so bad? (It was a pretty rough day).

A quick Google search led me to just the book to solve this problem, Think Like a Programmer by V. Anton Spraul, published by the good people at No Starch Press.

In Chapter 1, Spraul lays out a handful of simple techniques for problem-solving that are worth remembering. Here’s a quick synopsis.

1. Always Have a Plan

Plans, Spraul notes, help you to develop intermediate goals, which can be important to help track progress. Without a plan, there’s only one goal: solve the problem. And when you continually fail to meet this goal, you start feeling like you suck.

Plans are useless, but planning is indispensable. The plan will change, but you can’t head into battle without one.

2. Restate the Problem

I think of this tip as: “describe the problem in your own language.” Before diving into the problem, it can be helpful to carefully consider what is being asked. What is the ultimate output needed? What data types will be necessary to get there? What are the steps or requirements that are needed to reach the ultimate goal? Restating might reveal an easier approach to the solution.

3. Divide the Problem

Breaking a problem into smaller chunks is probably familiar to many people attempting engineering tasks. After all, five smaller tasks are easier than one huge one, right?

Spraul points out that it sometimes goes even further than that. Dividing the problem can sometimes reduce the difficulty by an order of magnitude. And it often leads to code that’s more sequential, logical and easier to read.

4. Start with What You Know

After breaking up the problem into pieces, why not complete the pieces you know how to do? This builds confidence that you can tackle the rest of the problem and uses those hard-won coding skills: sorting parsing data, iterating through lists, making an API call… it’s what you signed up to do, so why not do it?

5. Reduce the Problem

This may sound like dividing the problem into chunks but it actually should come after you’ve chopped the problem up into smaller pieces.

Then, if you can’t solve a particular aspect of the problem, rewrite it and simplify it until you can. This has two benefits: sometimes it helps foster the realization that we have all the tools needed to solve the problem, and other times it helps isolate the unsolvable aspects and verbalize them, making it easier to ask for help.

6. Look for Analogies

Think back to previous problems you’ve encountered and see how the current problem is similar or different. The more problems you do, the more analogies you’ll find.

7. Experiment

Note that this is far down on Spraul’s list, and not #1. How many of us have started a programming problem by tinkering with a few functions or jumping on Stack Overflow to see how the syntax for a particular possible expression works? That’s something I’m 100% guilty of.

With Spraul’s techniques though, this should come after some serious planning and consideration. To be clear, nowhere in the book does it say you should follow these steps strictly in sequence, but Spraul does note that other techniques should be used first in the planning phases of a problem.

Is it the end of the world to tinker a bit before attempting a problem? Absolutely not.

But, as problems grow more complex, this can lead to a feeling of hopelessness like you suck at what you do. With that in mind, I’m resolving to try some of the other steps listed here before resorting to experimentation.

8. Don’t Get Frustrated

Easier said than done.

Spraul points out that frustration is a choice, often to avoid facing the actual problem, and none of us have to succumb to it if we don’t want.

By working on two problems at once, we can switch off and give the mind a rest while it ruminates on the solution (I’m a big proponent of this— as a writer, I’m a firm believer in the power of the subconscious and its ability to do work while we’re not even paying attention). And, lo and behold, having a plan and a strategy to tackle these things should help limit frustration. Pretty cool how that works out.

I’m still making my way through Think Like a Programmer, skimming it at night when I can’t sleep, and attempting to put some of the ideas to use. Overall though, this first chapter is invaluable and these tips are some I will be using from now until the last line of code I write. Hope these help you too and good luck on the journey!