In a recent FreeCodeCamp forum, someone asked a question about journaling:
While looking for the source for my project, I saw that some programmers or developers wrote a kind of diary to keep track of the code. I think it’s nice, but I was wondering exactly how you can structure a diary and if any of you use this to write code. Question here.
Good question. I’ve seen other people use diaries or online journals, or those things people use…writing logs or whatever. 🙂
Anyway, the only reply includes a link about using a “logbook”. On the link page, the author references George Pólya and his book How to Solve It. I had never heard of this person or his book, so I did a little research.
George Pólya, (1887 – 1985)
George Pólya was a Hungarian-born mathematician who was known for his mathematics work, as well as his work in heuristics. Heuristics is “any approach to problem solving or self-discovery that employs a practical method”.
“Examples that employ heuristics include using a rule of thumb, an educated guess, an intuitive judgment, a guesstimate, profiling, or common sense.”
He wrote a book about solving problems using common sense principles.
The George Pólya Method of Solving Problems
The Wikipedia page shows that Pólya lays out some pretty good heuristics for solving problems. Although he intended for these strategies to be used for solving math problems, I think they could be used to provide a structured method for solving almost any difficult problem.
The Pólya problem solving method involves 4 principles:
- First, you have to understand the problem.
- After understanding, make a plan.
- Carry out the plan.
- Look back on your work. How could it be better?
So how does it work?
Principle 1: Understand the Problem
Pólya based the first principle, Understand the Problem, on the idea that math students struggled to solve problems due to a lack of understanding the problem in full or in part. His technique involved coaching teachers to prompt students with the following questions:
- What are you asked to find or show?
- Can you restate the problem in your own words?
- Can you think of a picture or a diagram that might help you understand the problem?
- Is there enough information to enable you to find a solution?
- Do you understand all the words used in stating the problem?
- Do you need to ask a question to get the answer?
Essentially one should not move past principle one until a constructive answer can be given. It’s not clear from the Wikipedia entry if a constructive answer is required for each question or the entire problem.
Principle 2: Make a Plan
Basically he felt that a person gets better at selecting a good plan/strategy the more times they solve problems. Here’s a big list of strategies:
- Guess and check
- Make an orderly list
- Eliminate possibilities
- Use symmetry
- Consider special cases
- Use direct reasoning
- Solve an equation
- Look for a pattern
- Draw a picture
- Solve a simpler problem
- Use a model
- Work backward
- Use a formula
- Be creative – (“[Have] patience to wait until the bright idea appears”)
- Applying these rules to devise a plan takes your own skill and judgement – (“Always use your own brain first”)
Principle 3: Carry out the plan
Simple enough, but the main problem people have with this step is giving up too soon. For that, the Wikipedia entry says:
“In general, all you need is care and patience, given that you have the necessary skills. Persist with the plan that you have chosen. If it continues not to work, discard it and choose another.”
Principle 4: Review, Reflect and Extrapolate
Take a look at what you’ve done, and evaluate how well it worked (or didn’t), and see how you can use what you’ve discovered for future problems.
Finding the book:
If you want to find this book, I recommend trying your library. I found it by searching for "how to solve it book pdf" (Google suggested the "pdf") and I found a copy.
An earlier version of this post included an account of how I applied Polya’s technique to my portfolio changes. A follow-up post will focus on that account.
2 thoughts on “Solving Design Problems like a Mathematician”