[travisjungroth]

I have a few variants of problem solving methodologies for different situations. They are incredibly similar to this post. They are also incredibly similar to the process in How to Solve It[0].

I intended to memorize the one-page summary to How to Solve It last year. I generally don't get past the first few sentences because I find them so relevant. It's like a mantra in my mind. "Understanding the Problem. First. You have to understand the problem."

[0]Summary: https://www.math.utah.edu/~alfeld/math/polya.html

[hinkley]

I sometimes state this as, “ask ‘why’ one more time than you think is reasonable. Otherwise known as “Ask ‘why’ until you get tired of it, then ask one more time.”

If you don’t understand the problem you’re fixing symptoms.

[travisjungroth]

The "Why?" questions are a bit different. Usually they take you to another problem versus telling you about the problem at hand. In its worst form, because it's such a simple technique, you can get quite lazy about it.

If you start with "The website is slow.", the Why? questions might take you to "Why is speed important to our users?"

Maybe before you jump off the original problem so quick, it's good to understand it. "Who said that? Are they talking about latency or speed? Is it the time to the beginning of the response or the completion or something in between? What browser and internet were they on? How fast is the website?"

[patrck]

It's good to practice the different situations.

I spend most my time `duck-talking` with a TeX doc that alternates between annotated questions and answers from some REPL. When I go AFK and have a problem, I try to punt because otherwise I am much more likely to make a mistake. :/