Problem Solving In Real Life: Part 2

Welcome back to the thrilling world of solving problems. In the first part of this journey, we toyed with a pretend pineapple finder to reveal the inner workings of what makes us great problem solvers in programming. Did you expect that? Me neither. We concluded it is not as much about pure learning, as it is about developing great habits. So… step away from the books. Let’s work on great problem solving habits.

But what are those habits? Below, I’ll highlight a habit and describe it. I will include great ways for you to start training yourself, too. In conjunction with learning, developing great habits is what will push you over the finish line to greatness.

There’s a catch, though. It turns out that these habits will not only make you a great programmer—they also make you a great person. It’s special when a professional discipline results in building your character. Did you need an extra reason to develop these habits? Whelp. There it is. In fact, it’s so easy to relate these to being a good person that I have included the correlated habit from the famous 7 Habits of Highly Effective People by Steven Covey. See the title of each habit for the tie in.

Verification: Begin with the end in mind

The first and most important habit for solving problems is to verify your assumptions. In the Covey literature: “begin with the end in mind.” That means we should not start solving problems without knowing: (a) what end result we want and (b) how to verify whether that end result is being reached. If we can’t do that, what exactly are we doing?! It’s worth spending a few moments to identify that at the start.

Programming can be mysterious. We don’t hear the inner monologue of the computer, as it’s interpreting our code and stroking its beard. It can be totally silent and opaque. We have to bring some of the inner stuff to the outer world where we can see it. That’s why Test Driven Development or Test First Development are buzz words. Because engineers before us have become great from practicing this habit—and they are now believers. In that paradigm, you write a failing test before you create a solution. If that’s not beginning with the end in mind, then I don’t know what is.

However, the way to practice this doesn’t require you to write tests. Find some way to verify what you are doing before you start. Are you relying on a variable? How do you know the variable represents the data you want? Have you checked? Did you create a function or method? Does it work? PROVE IT!

And don’t start verifying anything new unless you can verify that the thing behind has been verified. Have you verified that your verification is verifiable? Which leads to the next great habit.

Decomposition: Put first things first

So, if you’re in the business of verifying your assumptions, you better be in the business of breaking things down. For example: We can’t first verify that a building works. But we can first verify that the doors work. The elevators work. The air conditioning works. The alarm system works. And there must be an order of precedence. Like: let’s check that the floor works before we build a room on top of it. In the Covey literature: “put first things first.” That means we: (a) identify the most important problem and (b) solve that first.

In real life, there is a strong chance that problems before us will be presented like this math equation:

This is one of the driving forces behind a programming concept called Wishful Thinking. This has a positive connotation. Wishful Thinking means that you pretend to have a solution to outside problems while you target an atomic, simple problem that you must solve first. When you are done with that simple problem. You go to the next. People who practice Wishful Thinking get stuck less because they know which problems they care about, and which problems don’t matter yet. People who do not practice it don’t know which problem to attack first and think that every problem matters.

The best way to practice this skill is to change the way you look at life. We never do anything big. We just do a ton of small stuff. So, the next time you are given a problem that looks hard, realize that it might just be a composite of many simple problems. And rather than try to solve a problem, try to find an easy problem to solve. Once you can identify that simple part, solve it, and I bet you’ll know which subsequent problems need to be solved.

Once you have broken something down enough times, you’ll start to feel an itch. An itch to tell someone about it. That brings us to the next great habit.

To Teach is to Learn: Think win-win

You have been moving step by step, verifying as you go and breaking things down. Wow, you are a new and improved person and problem solver. Congratu-freaking-lations. But guess what? Nobody cares.

Just kidding, I care! For real. And so do about a hundred other people who are dying to know how the heck did you solve the problem that you just solved? When you start solving problems intentionally, you’ll start becoming better at life. But how do you know that? You might think you are becoming better, but there’s one important way to verify that, which will be tremendously helpful to the people around you. In the Covey literature: “think win-win”. That means, in this case, you: (a) have the courage to shine light on your skills and (b) you care about the progress of others. The result: you teach what you think you know, to enhance the lives of others. Often, you’ll find that the act of teaching is more instructive to you than it is to your pupil.

This skill is super important in that it departs from the self and journeys out into the people around you. It also sounds like an imperative, rather than a necessity for problem solving. And that’s true. But to the degree that it reveals problems in yourself, it’s highly important to truly making progress.

Pair programming is a key implementation of this skill. There are no two people who know all the same things and have all the same skills. There will be strengths and weaknesses shared, in different ways, by both sides of a pair. And it’s that inequality that presents the opportunity to teach the other person what you think you know. When you have the courage to open up your knowledge to the other person, which enhances their life, you also discover your flaws. They can do the same. And together, you create better software as a pair. Software that shines with both of your best thoughts. That’s how to mutually win. And if winning is wrong, then I don’t want to be right!

Get better at this skill by being in a community or by realizing the community all around you. You’ll inevitably notice that others are struggling through the steps that you already went through. Have the guts to reach backward and pull them across. Can you do it? I guarantee they’ll be grateful that you tried. And I also guarantee that you’ll get something out of it.