Solve Hard Problems

In the past decade of working in software I've noticed a reluctance to work on valuable problems because of a bias toward working on the easily scalable ones. I don't think this is a trend, really, but more something I've seen as a pattern throughout my career.

As engineers we like to clean up the messy world that surrounds us. If you can abstract a problem, and synthesize it into your “clean” model of the world, you think you’ve won. You think you’ve solved this problem once, gotten a 1000x multiple on your engineering time, and will never have to revisit it again.

You can see this when engineers decide on a problem they’d like to solve for a new tech startup. Especially in Silicon Valley, where there are droves of trivial problems getting a solution. But, you can also see it every day inside almost every tech company on earth. A customer has a problem to solve, and engineers insist that it can’t be solved, isn’t worth solving, or that the customer should change their business processes and then it wouldn’t be a problem.

The fact is, when engineers synthesize problems their customers face into our “clean” model of the world, we’re not creating value. We’re just selfishly making things easier on ourselves. One thing I hear way too often when working with other engineers is that we “spend way too much time dealing with customer X”. That’s the wrong attitude.

But the mess is needed. The mess is valuable. Complexity is the essense of software and we can’t make it go away. I'd like to make the argument that we shouldn’t try. Paul Graham wrote a great essay on this called Do Things That Don’t Scale. For an engineer, that can be read as blasphemy. But he has a great point.

Startups take off because the founders make them take off. There may be a handful that just grew by themselves, but usually it takes some sort of push to get them going. A good metaphor would be the cranks that car engines had before they got electric starters. Once the engine was going, it would keep going, but there was a separate and laborious process to get it going.

You show me a perfectly scalable software product from day 1, and I’ll show you a worthless one.

Use Your Big Problem Mindset

My favorite problems to solve are the big ones, with seemingly impossible design constraints. I think all good engineers are like this.

How do you build a space company from scratch without a government budget?

Find a way to make the rocket reusable.

How do you build cars which the masses can afford?

Find a way to build them efficiently: The assembly line.

The list can go on and on. These are the most fun problems, but we let our our engineering biases get in the way of creating value. Instead of embracing the design constraints our customers are giving us, we push back against them in the name of scalability.

Space X had to do “consulting” work for the government in order to fund development of their scalable solution to affordable space flight. Henry Ford had to convince industry titans that he wasn't crazy to think it was possible to build 100 cars in a day.

Look at the problems around you holistically. Embrace the design constraints you’re given. Without constraints, a problem is trivial and not valuable to anyone.

Listen to your customers. They’re telling you how to create value. Combine their constraints with the constraints of your business, then constrain the problem even further to find a way to get a multiple return on your engineering time.

Solve those problems. That’s how you’ll find meaning in your work.