Problem Solving - Who Why What How
Problem solving. It’s so easy to think of it as the ability to exert control over every situation. But what is it really, and how can we learn to do it better?
You start your career with the best of intentions and a shiny new, though mostly empty, toolbox. You’ve had assignments in school, you were informed what the right kinds of answers were, and here you are, ready to write magic within your public static void main(). That, of course, is where it all goes so miraculously pear-shaped.
Here’s the truth: it’s a rare situation that teaches you problem solving. After all, going through elementary school, junior high, and high school, if you found yourself on the absolute crux of a problem that was absolutely up to you to fix, it probably meant that your entire support apparatus had failed. Or, if you were facing a real challenge that required an answer that wasn’t already there for you, you were probably advanced on a super-weird hobby. Like making erotic art out of Lego.
So how do you learn it (problem-solving, not erotic Lego art)? It seems that, the longer I go in a tech career, the more I find that the difference between success and failure relies less on technical expertise and more on how you improvise or learn. Technical expertise is like height in the NBA: sure, you probably needed to be pretty tall to play, but the best players aren’t necessarily the tallest. It takes something else, and I think that every field has its “something else”.
I want to write a bit about my “something else”. I want to talk about the patterns, mindsets, and checklists that I bring to bear when I’m looking to solve a problem, or when I’m just wondering what I should be doing. I’m going to talk about a few of these in the next posts, specifically the Growth Mindset, Toolbox Management, and How to Hone your Gut. But first, I’m going to lay out the checklist I start before every project.
Who Why What How
This phrase came to me organically, but a google search shows that I’m not the first person to have thought of it. I’m not very original that way. And I’ll admit that most days, this could contract down to “Why What How” or just “What How”, but when I start any project, here are the questions I have to answer:
- Who are my stakeholders?
- Why are they involved? What are they intending to get out of this? How could they be negatively affected?
- What am I going to make? What is the scope? What are the requirements? How will it look?
- How will I make this?
This started as a programming paradigm of “What over How”, i.e. your code and efforts should reflect the problem you’re solving. Programmers, as a class, tend to be obsessed with how, but I repeated this mantra over and over, and eventually, it became a great way of judging whether or not I was doing the right thing and doing it well. It changed the way I coded, because my code became more about telling a story than just getting things done, and code like that is easier to maintain or update. Then this started expanding to everything I did at work. When it came time to prototype UX or design an API, I started with identifying who would be using it and what they would expect.
For a real example, let’s take this website. Here’s a table with each step.
| Who | Me, potential employers, blog readers |
|---|---|
| Why | I want to demonstrate my technical experience, communication skills, values, and personality because I want to get a better job with a company that shares those values and will help me grow in the next phase of my career; employers want to know if I would be a good fit for their organizations; readers want to learn about what I’m discussing |
| What | Website with e-résumé, blog, and portfolio |
| How | Find a good HTML theme online, turn it into a modular template, and use it generate pages. Then start creating blog posts and portfolio pieces. |
I think the first question of problem solving should generally be “is this the right problem to solve?” And this helps me answer that question. I’ll talk more about my problem solving approaches as time goes on, but I hope you liked this much. Thanks for reading!
