The most valuable trait or habit that I’ve developed as an engineer is to “focus on the problem, not the solution.”
Sounds very counter-intuitive. Don’t we usually say the opposite?
The context here is that most people love to complain about problems and then hasten to slap solutions, as opposed to STUDYING problems and trying to investigate why they’re there in the first place — and solving the root cause.
Most engineers are guilty of this. They love to rush to coding as soon as they see a requirement, as if they’ve been bit by a rabid dog and can’t keep their hands still.
The product you end up with is a “well-made piece of crap.”
The best engineers I’ve ever worked with, and those I’ve read about in history, are more interested in solving the problem than in finding a solution.
Yes, there is a big difference between the two. You’re focusing on the right solution, not the first solution that came to mind.
The first approach takes a bit of investigation, thinking, and study — which takes humility that you don’t know everything — and also involves a time delay before you can get to implementation.
The second approach gets you going quickly, but in the long run, you end up having to throw away and redo too much work, writing off huge losses in both time and money.
Now, it’s not like you can’t succeed with “move fast and break things”; I may be wrong, but I’ve heard that companies like Facebook and Angellist famously cultivated and encouraged this kind of culture.
Unfortunately, most companies can’t afford to do so. And they don’t need to — there’s a better way, a best of both worlds.
The key to the conundrum is how well-defined the boundary conditions are.
“Let’s hack something” is a great next step for situations where the problem is quite simple or trivial, and the boundary conditions are clear.
But as soon as you come to a systems problem (such as a UX problem where even a human is involved), then you have to think about what the solution can and cannot do, which quickly eliminates many default solutions that you may have implemented in the past.
In systems engineering, we usually suggest 15% of the project timeline being spent up front on this, with the rest spent on implementation / hacking.
