7 Reasons Why You Should Tackle Hard Problems Last

it seems like pretty legitimate advice, and many of the reasons for saying so make sense, at least at a surface level.

the reasoning usually revolves around the idea that by tackling the hard problems first you can eliminate your biggest risk early and everything will be smooth sailing from there.

when you really think about the reasoning for solving hard problems first though, most of it is not actually reasoning, but based of off one emotion… fear.

we tend to think it is best to solve hard problems first, because we are thinking about eliminating our fear, not because we are thinking about what approach has the highest chance of success or is the most optimal.

i call this fdd , or fear driven development .

and when i think about it that way, i find myself hard pressed to find a real good reason for tackling hard problems first besides being able to abort early.  which, in some cases might be good, but i’d rather focus on success.

here are 7 reasons why it might be a good idea to tackle the hard problems last instead of first.

1. solving easy problems first gives you momentum

when a large ball starts rolling down a hill, it picks up speed rapidly and that large ball can bust through many barriers that it couldn’t before, simply because of one thing it has after rolling down a hill that it didn’t have before—momentum.

on the converse, trying to push a heavy ball up a hill is pretty hard.  and if there are barriers on the way to the top of the hill, not only do you have to fight gravity, but you have to be able to push extra hard to get through those barriers.

life is hard enough, why make it harder?

i recently received an email from a developer that was concerned that his team wasn’t gelling and that they didn’t have the expertise in the technology needed to solve the complicated problem ahead of them.

they were going to start the project by trying to integrate this fairly complex technology and he was afraid that it would cause them a large delay before they would be able to get version 1 out.

my advice?

start with your simple problems; get working software out there as soon as possible. not only will the team gel much more easily as they are having success and making real progress, but that momentum will help them when it is time to solve the more difficult problem.

even if they have to throw the first version away, when they get to the hard problem, the momentum alone will make them much more likely to reach success in the end.

i could give 100 examples of how solving easy problems to gain momentum can benefit you, but you probably already know intrinsically that this is true.

long story short, get a running start before taking a big leap.

2. avoid solving the wrong problem

there are few things worse than spending weeks or months solving a difficult problem, only to find out in the end that you actually solved the wrong problem.

the big problem with solving the hard problems first is that the hard problems usually require a large amount of context in order to fully understand them.

it is very hard to get the right context for a hard problem when we take it out of its natural order of progression and artificially cut it to the front of the line.

you’d probably like to start a college class by taking the final exam first, so you don’t have to worry about it, but the problem with doing so is that you’ll lack the context and information to understand the questions and to know the answers.

when we try to tackle problems out of order to avoid leaving the hard problems to the end, we end up losing all of the learning and context that would help us to solve the hard problems at the end and we are much much more likely to end up solving the wrong problem, which is a complete waste of time.

3. someone else may solve the problem for you

sometimes procrastination is a good thing.

sometimes, when you purposely push off solving a hard problem till the end, you end up finding that someone else already solved your problem.

i was working on a pluralsight video last week, using camtasia 8 for editing, and i found that one of the video segments i was tried to load up was crashing the application every time.

i spent a few minutes trying to troubleshoot it, but nothing i was trying was working, so i had to make a decision.

i had 3 choices:

1. keep trying to solve this hard problem before moving on.
2. go on and do other videos and send off a support request to see if they could handle it.
3. make a new project and re-edit all the clips.

choices 1 and 3 involved tackling a hard problem right then and there.

choice 2 was to tackle easy problems and see if support could solve my hard problem for me, and if not, i would solve it at the end.

i ended up choosing option 2 and it paid off.  it turned out camtasia support was able to solve my problem.  by the time i needed the project to complete my course, they had solved my hard problem for me and i didn’t waste any time upfront trying to tackle it myself.

now it could have worked out differently; i might have had to solve the problem myself at the end, but instead of assuming i would have to and wasting perhaps a day or 2, trying to solve the problem myself, i pushed it off and kept working on easy problems and i gave someone else a chance to solve my hard problem for me.

it doesn’t happen all the time, but many times if we push off the hard problems we face, we find that by the time we get to them, someone else has already solved the problem for us.

4. your own subconscious mind may solve the problem

when i said someone else might solve the problem for you, that someone else might actually by you—at least your subconscious mind.

have you ever had the experience of thinking about a problem and not being able to figure it out, but then you wake up the next morning and suddenly have the answer?

it seems that our subconscious mind is more powerful than we are aware of.

in many cases, if we know of the hard problem we need to solve and have thought about it a little bit, our subconscious mind will start working on the solution , even though we are not aware.

obviously this isn’t going to work all the time, and your subconscious mind isn’t going to write a bunch of code for you, but in many cases there is at least some benefit to throwing the problem off to our internal “worker thread.”

5. you are more committed to solving the hard problem when you risk everything you do so far

one benefit to saving the hard problem for last is that you have some extra motivation in the form of loss aversion.

it has been demonstrated in several experiments that people tend to try to avoid losses versus acquiring gains .

we can use this knowledge to our advantage by doing the easy work first and letting our loss aversion help motivate us to solve the harder problems, because we don’t want to lose all the work we put into a project so far.

by starting with easy problem, we put some “skin in the game.”

if we try to solve the hard problems first, we have nothing to lose, so we are much more likely to give up.

6. hard problems are often easy problems bundled together

i’ve talked many times about breaking things down and trying to keep things as simple as possible .

and it turns out that many hard problems (not all) are decomposable into many small easy problems.

if you strive to never solve hard problems and to always push them off, you may actually find out that you never have to solve hard problems.

many times we can chip away at hard problems, by taking bits of them off a little at a time and solving those easier problems.  eventually, you may find that you’ve reached the tootsie roll center of your hard problem lollipop and it is filled with chocolate candy!

now, some problems aren’t very easily decomposable, but a good majority of problems are.  once you develop the skills to chip off bits of hard problems into smaller easy problems, the world looks like a much more conquerable place.

so, saving hard problems for last and breaking off little pieces of them as you go, can be a good strategy to help you to wear down your opponent before you have to face him.

7. some hard problems are never truly solved

one of the big problems with tackling the hard problems first is that they tend to fill up as much time as you’ll give them.

if i give you an easy problem, like write a function to reverse a string, there isn’t much to think about.  you can solve it a number of different ways and there isn’t a huge difference in the efficiency of the different methods of solving it.  it is pretty unlikely you’ll spend weeks revamping your solution and thinking that it’s not quite right.

but, if i give you a problem like, create an in-memory database, not only is it a hard problem, but it has a huge number of possible solutions and can be optimized from now until the end of time.  you could spend 2 weeks working on that task or 2 years.

the problem is that many hard problems don’t have a good scope to them when they are solved in isolation.

if you design an engine for a car that isn’t built yet, you won’t know when you are done.

but if you design an engine for a car and you know how much it weighs and know what kind of transmission it will use and what kind of fuel efficiency it needs to have, you can have a much clearer understanding of when your engine design is done.

if you save the hard problems for last, the scope of those hard problems will be much more defined , which will keep you from wasting valuable time over solving a problem or, like i mentioned earlier, solving the wrong problem altogether.

if you like this post don’t forget to follow @jsonmez or subscribe to my rss feed .