Respect the problem

March 01, 2020

As a teenager, coding appealed to my impatient mind as a way to build something from nothing with no specialized knowledge.

To build a treehouse, you need to learn basic physics, wood composition, joints, humidity, and permits.

To build (grow) a plant, you need to learn about biology, soil composition, weather, fertilizer, and the science of sunlight.

But to build a program, you just need to copy some sample code from a stranger online, and run a command to execute it.

Coding has a nearly instantaneous feedback loop that allows you to quickly iterate towards a solution. Starting with an empty text editor, you can progressively build programs that increase productivity, save lives, and create billions of dollars of value.

The 80 / 20 rule

Everyone knows the 80 / 20 rule, also known as the Pareto principle. It is an observation that a large portion (e.g. 80%) of results come from a small number (e.g. 20%) of causes. Common examples include 80% of global wealth being held by 20% of people, 80% of software crashes are caused by 20% of bugs, and 20% of customers being responsible for 80% of the profit of a business.

I’ve used the Pareto principle to guide most of the my life and career decisions, which has led to both successful and failed projects. It has become the path of least resistance in my brain when solving any type of problem.

Limitations of the Pareto Principle

The 80/20 Rule will help you find the useful things in your past and get more of them in the future. But if you don’t want your future to be more of your past, then you need a different approach.

James Clear

When applying the 80/20 rule to solving a problem, the goal is to develop a quick and shallow model of the problem in your mind, then dive right into building the solution. For many problems, this approach work wonderfully and you’ll be able to produce an optimal or nearly optimal solution, fast.

However, I find that as I’m exposed to more difficult problems, my shallow Pareto model of every problem is sorely lacking in necessary details. The worst part is that I often don’t realize the holes in my model until I’m at least part or most of the way into the implementation. These surprises are extremely time consuming and make it impossible to make estimates.

Best of the best

One of the masters of applying the Pareto principle is the hacker George Hotz, aka geohot. He’s most famous for being the first person to carrier unlock the original iPhone, and more recently for his amazing and entertaining coding livestreams. I watched his HackerRank warm up livestream and it has opened my eyes to both the capabilities and limitations of extreme application of the Pareto principle. Geohot submitted solutions for the first problems before I even got a chance to fully read the questions.

After being bored with the first few questions, Geohot found a more challenging problem and dove in like he had for the previous few. He quickly created a valid solution for the problem, but a few of the test cases did not finish within the maximum time limit (10 seconds with Python, 2 seconds with C).

Geohot did eventually hack his way to a solution that completed all test cases in the time limit. However, this incremental improvement process took over 5 hours, most of which was spent on finicky code optimizations (memoization & hardcoded buffers, rewriting the algorithm C, changing data structures to fit more data into the processor’s cache) rather than the novel algorithmic improvements that the problem truly required.

This isn’t a dig at Geohot. His iterative hacking approach is the fundamental style of these types of livestreams. Rather, this is just my own observation of the limits of even the brightest hackers against a medium-level problem that begs for upfront planning over frontal assault.

Respect the problem

“You have to respect your enemy. Never, ever underestimate them. The second you do, they’ll squash you. Be smart about them. Respect their abilities, even if they don’t respect yours.”

James Patterson

I’m not in this “best of the best” league of hackers and programmers. The 10x engineer is not me, at least not yet. But seeing examples of the limitations of this group helps me get a sense of my own capabilities for today and possibilities for the future.

I’ve realized that by clinging to the efficiency of the Pareto principle, I’ve surrounded myself with easy problems that only require surface-level knowledge. Occasionally, I’ll run into a problem that really deserves the respect of upfront planning and thoughtfullness, and get burned with bad estimates and even worse solutions.

My goal for 2020 is to focus on developing that respect for the problems as much as possible, and through this deliberate practice, increase the difficulty of problems that I can solve.