W01 - Paths to Solving Complex Problems

On Friday night I was talking with Yunfei about a somewhat tricky issue on an e-commerce PC site. I remembered I had written a blog post about this before, so I opened my blog site that had been untouched for five years.

After so many years it felt both familiar and a little embarrassing. Back then I had more free time and was eager about the internet; I set up a blog in my spare time and liked to show off techniques I thought were profound but were actually just clever little tricks. Flipping through it, I joked to myself that nowadays it’s hard to settle down and write things like that — I only think about whether something can make money.

If there’s anything I can still feel a bit proud of, it’s the domain name I registered at the time. Few people know there is a .wang top-level domain, and my surname happens to be Wang. So I have a domain that exactly matches my English name — globally unique, always HTTPS, no 102 needed.

Back to the point: that tricky problem I mentioned at the start gave me some new insights.

First, what kind of problem is it? The JD desktop homepage, a classic design, hasn’t had a major iteration in three or four years. It contains many enduring elements, like the classic category selector on the left side of the screen. When your mouse hovers over a primary menu item, the adjacent area displays the secondary menu. So as you slide across the primary menu list, the secondary menu updates in real time to match the primary item under the cursor. Interestingly, when you move your mouse to a particular secondary menu, the primary items you briefly passed over do not trigger secondary switching — you can reliably select the secondary category you want.

At first glance it looks like an AI problem and is fairly complex. If you frame it as analyzing the mouse movement path in real time to infer the user’s true intention, many people would pursue that direction for a solution.

In fact, after analyzing and summarizing the requirement, it reduces to the problem of determining whether a point lies inside a triangle. A picture is worth a thousand words: when “Primary Nav 1” is selected and the mouse moves within the illustrated triangle toward a secondary menu, you can choose not to trigger linked responses for the primary items crossed over, or delay the switch.

There are many ways to determine whether a point lies inside a triangle. A classic approach uses vector cross products. Implementing basic vector operations in code is straightforward — just combinations of additions, subtractions, multiplications, and divisions.

That is the problem. Below are some new reflections. I divide the process of implementing this requirement into four stages.

First is concretizing the requirement. The requirement must be clarified and decomposed, made as concrete as possible.

Second, translate the decomposed requirements into problems — this is a process of domain modeling and formalization. In software engineering, it means mapping requirements to a computable, programmable model. In retrospect, this step is more critical than the subsequent “how to do it.” The ability to translate a requirement into “determine if a point lies inside a triangle” is a higher-order skill for an engineer.

Next comes the question of how to implement it. The prior step’s output is a model, which could be a mathematical, physical, or statistical model, and our task is to connect different disciplines and domains. For example, if you don’t know how to test whether a point is inside a triangle, consult someone strong in math. A large, complex problem may involve multiple fields, so this becomes a process of networking resources.

Finally, there is the implementation phase. Most of our time is spent on implementation and engineering work — modularization, standardization, and all the engineering practices — which is the area we’re relatively good at.