I’ve been wanting to write about two different philosophies of getting things done for a long time. I kept going back and forth on the title – “Two Worlds, Two Philosophies” or “Two Philosophies, Two Worlds.” The former starts from results, the latter from causes. In Buddhist terms, cause is effect and effect is cause – they’re the same. But in problem-solving, we generally work from effect back to cause. Finding the root cause is the only way to truly solve a problem.

Hammers and Nails

Too often, we walk around with a hammer looking for nails. Engineers are especially guilty of this. You see a shiny new solution and immediately think: “This could solve our XXX problem.” Flutter, RN, Weex, plugin frameworks, hot-fix systems, and so on. Admittedly, these solutions do address some problems. But they also introduce a whole new set of issues. KPI-driven projects are a different story, but looking at the broader picture, these technologies are mainly a domestic Chinese enthusiasm. In Silicon Valley, it’s a completely different approach.

A colleague once asked me: “Isn’t hot-fix an essential part of mobile infrastructure?” I was exasperated. I asked back: “Can’t you build an app without hot-fix? Why do apps from Silicon Valley giants work just fine without it?” It’s the same as asking why Chinese companies obsess over 996 (the 9am-9pm, 6-days-a-week grind). Is market cap really built on 996? Meanwhile, FANMAG (Facebook, Amazon, Netflix, Microsoft, Apple, Google) doesn’t do 996, yet their market caps rank among the global top. If you think along these lines, the earlier question clearly has a different answer.

Old Problems and New Problems

Too often we only care about whether the original problem got solved. But we should also take a holistic view: did the solution introduce new problems? If you’ve merely transformed a problem from one form to another, or moved it from one place to another, you haven’t solved anything.

We don’t solve problems. We’re just problem movers.

Similarly, every sprint review the PO announces: this metric went up X points, that metric improved by Y. Everyone’s impressed – wow, what an amazing PO! But is it real? You have to look at the full picture. Were those metric improvements achieved at the expense of other metrics? If you’re just pushing down one gourd to watch another float up, you’re just a metric mover.

People vs Rules

Throughout history, the art of manipulation has been revered. Got a problem? If you know the right people, it gets handled. Because so many things are ultimately decided by individuals, a mindset forms: getting things done is all about connections. This turns people into the system’s SPOF (Single Point of Failure). The opposite philosophy is: when designing a system, eliminate SPOFs as much as possible. Even when you can’t avoid them, ensure recoverability after a single-point failure. Under this design, the role of individuals becomes less critical. As long as the rules are transparent, anyone familiar with them is interchangeable.

On a related topic – hiring. One philosophy says: hire someone whose tech stack matches, so they can start contributing immediately. The other says: hire someone who can solve problems, regardless of tech stack – what matters is their problem-solving approach. These two hiring philosophies produce two completely different interview styles. The first is the classic “interview for rocket science, hire for screw-turning.” The second focuses on discovering and solving problems. One is experience-driven, the other is thinking-driven. The result: when there’s no prior experience to reference, the experience-driven approach breaks down, while the thinking-driven approach is far more universally applicable.

Treatment vs Prevention

Problems to systems are like diseases to the human body. Do you wait until you’re sick to treat, or do you prevent illness before it strikes? From what I’ve seen, we still default to the former. In practice, the cost of prevention is far lower than the cost of treatment. Yet we usually think: “This problem hasn’t happened yet – why invest resources in it?” And then Murphy’s Law proves us wrong. So we end up with this cycle:

  1. When a problem occurs, contain the damage first
  2. Then analyze the root cause and fix it
  3. Then figure out how to prevent similar problems from recurring

But we usually only get to step 2. As for preventing recurrence, we rarely reflect on it. And so the same tragedies keep replaying.