Solving Hard Problems

Jonathan Blow shares how his insights on solving hard problems in this clip.

In a big project, you don't have to solve every problem at once.

You'll get crushed under the load of everything you have to do and not get anything done.

It's better to have a forward moving wavefront of which problems are we tackling seriously right now vs which problems we're just doing that kinda sucks but is good enough for now.

This is okay as long as you're going back and improving the suboptimal solutions later.

If you get a rough draft of your program, you can use that to figure out how you want it to behave.

Some initial ideas you have might not be a good idea. You you can refine those ideas by having something approximating those ideas.

The faster you get to those approximation the better.

The more time you spend working in that space of your approximation to the thing you want, the more you become an expert in that specific field

And the better you get, the better your decision making about technical issues

If you make hard decisions later, they will be made better by a more skilled person and with more contextual information.

Deferring hard decisions is important for good craftsmanship in some cases

In situations when you don't know the answer, you don't have to ignore the problem, but the right way to fix it you don't know right now.

Work on other easier problems you can solve right now that has more impact on usability.