How to Solve Any Problem

I find most people fail at solving a problem because they first do not understand how to fundamentally solve any problem.

This is a copy/paste from the original source where I found it. I did not want to lose the content as it looks like that site has been abandoned.

How To Solve It is a short volume by mathematician George Polya describing various methods of problem solving. The book has achieved classic status in its field because of its considerable influence.

In reading Polya’s book, I found distinct parallels to popular self development resources throughout history. Although the book outlines techniques used in mathematical problem solving, the same formulas can be applied to the practice of goal setting.

How To Solve It suggests the following steps when solving a problem:

  1. Understand the goal.
  2. Devise a plan.
  3. Carry out the plan.
  4. Look back on your work.

A more definitive description of each of the above techniques follows:


This principle is often neglected as being cliché and obvious. Yet individuals remain stifled with their efforts to achieve goals, simply because they don’t understand them. To remedy this oversight, Polya taught teachers how to prompt each student with appropriate questions dependent on their desired outcome:

  • What are you seeking to complete?
  • Can you state the goal in your own words?
  • Can you think of a picture or a diagram that might help you understand the goal?
  • Is there enough information to enable you to find an outcome?

The teacher is to select appropriate questions to ascertain if the student understands the goal at their core, and continues until the individual can respond with something focused and constructive.


Polya mentions that there are many reasonable ways to achieve goals. You will find it to be increasingly easy as you progress and learn how to overcome different limitations. A partial list of strategies include:

  • Guess and then check.
  • Make an orderly list.
  • Use symmetry. [Mimic success.]
  • Consider special cases.
  • Use direct reasoning.
  • Look for a pattern.
  • Draw a picture.
  • Solve a simpler problem. [Work on menial but relevant tasks.]
  • Use a model. [Implement available resources.]
  • Work backward.
  • Be creative.
  • Use your head.


This step is usually easier than devising the plan itself. In general, all you need are the following strategies in achieving your goals:

  • Care and patience.
  • Faith 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.
  • Don’t be misled. [This is simply how shit is done.]


Polya mentions that much can be gained by taking the time to reflect and look back at what you have done. What worked? What didn’t?

Doing this will enable you to predict which strategy to use to solve future problems. If all else fails and you cannot achieve the proposed goal, try to solve first some related goals. Can you imagine a more accessible related achievement? Make it happen.

You Do Not Understand Agile

Agile is not a proper noun. Agile is not a person, place, or thing. You do not do agile. You are agile.

What Is It?

My simple explanation of agile is: You have a vision of what you want to accomplish and the ability to make decisions. Assemble a group of smart, dedicated, and capable people to start figuring out how to do it and validate your assumptions and outputs along the way.

It’s as simple as that. That is agility. The understanding and acceptance that you will not know everything in advance but as long as you have a team of capable people with a set of top level goals and a single voice that can make decisions, you’ll figured out the rest as you go.

But What About Enterprise?!?!

When you throw the word “enterprise” in the mix, everyone loses their mind. “What about portfolio management?” “What about the PMO?” “How much will this cost?”. “We need a 6 month roadmap!” “WE NEED KPIs!!!”

The basic tenet of agility does not care about any of those questions. That’s all corporate generated noise and a relics from the contractor control model days from yesteryear. The primary goal is to add value as quick as possible and to incorporate learnings from fast feedback cycles.

The enterprise has caused all of their own problems and has institutionalized practices that make themselves slow. This short video Coordination Chaos does a great job illustrating how we inventively get ourselves into that mess.

Keep Calm, Agile On

There are no magic bullets. All you can do is recognize what the top level goals of being agile are ask yourself “am what I doing consistent with agility?”. If the answer is no, rethink your approach. If you continue to take small steps in the right direction, you’ll eventually get there.

Code Coverage vs Test Coverage

When organizations mandate “code coverage” numbers, like 95%, they’re barking up the wrong tree. Just because a line of code has been touched during testing, doesn’t mean it’s been tested; you’re only fooling yourself. Every time I tell someone the last product I created had 93% test coverage, they say “wow, that’s great!”. Then my follow up statement is “Yeah, it sounds great, but bugs still crept into covered areas”.
Continue reading “Code Coverage vs Test Coverage”

I was wrong about tracking actual hours in Scrum

I once made a statement about closing out project management tickets that went something like “The actual hours a story / task took are the only metrics that matter”. At the time, we had a ton hoops to jump through to close a story out due to our tooling choices. We ignored most of them, but the actual hours field was something I told the team I valued. My thinking at the time was this would definitively show us if we’re coming up with accurate estimates and if we missed our estimates, where did we spend that time. This would give us solid data points to use across sprints and act as a spring board for future planning sessions. In reality it ends up being fruitless and does little to build a better team.
I generally follow Scrum when leading agile teams, but I’m not prescriptive about it in any way. “Whatever works for the team” is another sound byte you’ll routinely hear me say and along those lines is where I had my epiphany. Just like being agile is about enabling the team, estimation and time in Scrum is all about the sprint. “How many stories can get done this sprint” is the real question around how long something will take. That’s it. It’s a scheduling exercise to maximize effective use of fixed time. It’s just an estimate! Where that time went during the story / task completion is immaterial for planning. Sure, it makes for a good conversation during the retrospective and leads to a fancy spreadsheet some dude in khakis can email around, but tracking actual hours in Scrum does little improve the estimation process of the team and certainly doesn’t increase the teams productivity. If neither of those things are happening as a result of tracking actuals, then I submit it is a pointless venture.

Which Ruby Iibrary for a Static Website

I’ve been toying with the idea of taking on side projects, specifically helping people bring their web application ideas to market in the form of a minimal viable product. I have become very efficient at taking white board concepts and turning them into working software in a short amount of time. Production quality at that, not just prototypes or throwaway code. I’ve talked to a lot of people with good ideas that have similar problems, “I could get this going if I could only code!” Well, I think I can make that happen. First stop is standing up a static website for marketing.
Continue reading “Which Ruby Iibrary for a Static Website”

MadCow 5×5 Week 3 In Review


I keep having to have the realization, epiphany, or whatever you want to call it that I’m only in it for strength, not size / mass. The only thing I should care about during this 12 week MadCow 5×5 program are numbers, specifically the numbers in my spreadsheet that put me at an estimated 1000lbs+ total. Continue reading “MadCow 5×5 Week 3 In Review”

Switching to a week in review format

I jumped the gun a bit with that last post. For a 12 week program that has 3 workouts a week, that would be 36 entries, way too many. Once a week is fine, basically a “week in review” of my progress. These posts are for myself really, a way to force me to reflect on my goals, my progress, and serve as a basic gut check. What’s special about this mesocycle is the calculated total at the end is 1000+ lbs, which I’ve been saying for a while is my target, but I’ve had a few set backs and lost focus more times than I would like to admit.

MadCow 5×5 Week 2, Workout A

I’m still not 100% and coming off a head cold. Regardless, I felt pretty strong. It was my first time working out in a sweatshirt and realized real quick why you have to had your hood up…you can’t squat with it down! I made all of my lifts without a problem, nothing really too eventful other than my return to the basement and trying to figure out the accessory exercises.  Continue reading “MadCow 5×5 Week 2, Workout A”

Where to Find the Best Ruby Libraries

I’ve been looking to update my full Ruby development stack and see what all the cool kids are using. I love when Rails Rumble wraps up and they break down what everyone used, it’s one of those dog food moments for the community. While it’s a great yearly pulse, it’s not a full look into the community offering to figure out what the best ruby libraries are. Ruby Rumble is a 48 hour competition, a MVP race if you will. Chances are there are many facets of development that go untouched in an MVP so their associated libraries go unaccounted for. At this point, people are interested in the fastest development library, not necessarily the best long term decision. So where can you go to see what’s hot, popular, or the most active? I know of two such places. Continue reading “Where to Find the Best Ruby Libraries” replacement looks great

I was really upset when went offline, it was something I ended up using regularly. Before that site, I really didn’t understand what a “DJ” was, I thought it was just some guy that hit the play button. But the more I used the site, the more I started to understand a good DJ can feel out the vibe in a room and decide where to take it through music. It was quite the epiphany when I put that together. When that went offline, I thought that experience was gone. Then I find plug.djContinue reading “ replacement looks great”