The Engineer's Three Outlooks: Technology, Product, and Data

Engineers need a technology outlook, a product outlook, and a data outlook.

(1) The Technology Outlook

What is the right technology outlook?

I believe the first requirement is to be open to all kinds of technologies and to embrace them eclectically. Engineers early in their careers often fall deeply and helplessly in love with a particular technology, so much so that the moment a dissenting voice appears, they summon every ounce of their intelligence to defend their true love. This innocence and naivety is almost a necessary stage in every engineer’s growth—like a boy first smitten with Xiao Fang in the class next door, convinced that she is the only Xi Shi in the world; later, having seen a larger world and read more books, he may still love Xiao Fang deeply, but he can also appreciate the plump Yang Yuhuan and the slender Zhao Feiyan.

Being eclectic means drawing on the strengths of many schools of thought and using different tools to solve different problems.

Second is a feel for the technologies one uses and studies, and a grasp of future trends. Short-term technology trends are like dice in God’s hand—no one can predict them. Two years ago, for example, Angular had just appeared and was refreshingly new; its momentum was like the Mount Song Sect, beating Ember, beating Backbone, and looking very much poised to unify the Five Mountains Sword Sects of front-end development. Then out of nowhere came React, like Linghu Chong, with novel moves that instantly drew all the attention away. If you look at front-end development over the past two or three years, no technology has had time to warm the throne before a new one comes charging in—a scene much like the chaos of the Five Dynasties and Ten Kingdoms. Yet one broad trend is irreversible: in terms of build tooling, automation is increasing and making it ever easier to build complex large-scale systems; in terms of system organization, modularity is increasing and also making it easier to build complex large-scale systems; in terms of development efficiency, debuggers, source maps, live reloading, compile-to-JavaScript, and similar tools are likewise making it easier to build complex large-scale systems. So the broad front-end trend is to move closer to back-end development capabilities in order to build more complex systems. Grasp this through line and you can understand these trends:

• Better dependency management tools: Bower -> Browserify
• Better compilation (compile) and packaging tools: Uglify + Make / Jake -> Google Closure -> Webpack
• Better task management tools: Make / Jake -> Grunt/Gulp
• Better development tools: ? -> Webpack live reloading -> time-travelling debugger (Elm)
• More mature languages: ES3 -> ES5 -> ES6 -> ES7 -> ??
• Better suited to complex front-end projects (static typing) or to particular goals (such as game development): ES5/ES6 -> Dart, TypeScript, PureScript (Haskell), Elm (Haskell), ClojureScript (Clojure)
• Better profiling tools: manual profiling -> Google Chrome profiling tools -> ??
• Better postmortem tools (for example, memory leaks and system crashes): no way to analyze -> Google Chrome profiling tools / heapdump / mdb (Solaris) -> ??

Back end is not as chaotic as front end (after all, it has developed for decades, and what front end lacks is already relatively mature in back end), nor does it change as rapidly, but it also has several main lines of change:

• The end of Moore’s Law: scale up -> scale out (highly scalable); C10K -> C10M (high concurrency)
• The unit of computing is getting smaller: bare metal -> VM -> container -> ?
• Computing capacity is getting larger: single machine -> cluster -> computing pool (Mesos/YARN)
• More and more data needs to be analyzed: Hadoop -> Spark / Flink
• Networks are getting faster and throughput is getting larger: 10M -> 100M -> 1G -> 10G -> 100G
• The barrier to entry for AI/machine learning is getting lower: Caffe -> TensorFlow; Apache Mahout -> PredictionIO

All the changes on the back end have followed the law of computing’s development: the swallows that once nested in the halls of the Wang and Xie clans now fly into the homes of ordinary people. Microsoft’s dream was a computer in every bedroom; Sun’s dream was every home computer connected to the network; Facebook’s dream is to connect the people behind every computer. In the course of realizing these dreams, complex software is continually being organized behind simpler, easier-to-use UIs; likewise, complex technologies are continually being exposed through clearer, more usable APIs. Ten years ago, building an enterprise B/S system required a company of engineers; today, it can be conquered by fewer than five. Ten years ago, engineers were engineers and architects were architects; today, more and more software projects are less engineering projects than integration projects, and the engineer’s work is more like that of an architect: choosing suitable suppliers (third-party systems, open source or not), then combining them organically to maximum effect.

(2) The Product Outlook

Having a technology outlook is far from enough for an engineer; the product outlook is what needs to be cultivated next.

The most basic part of a product outlook is mastering product common sense or conventions. We need to observe, in daily life, the common sense and conventions that exist in products, and use an engineer’s characteristic way of thinking to ask why such common sense and conventions arise: What are their benefits? What are their drawbacks? Only then can we handle product requirements correctly and avoid producing embarrassing problems or even fatal flaws in product development.

For example, every online system has a password reset feature—let us look at what the conventions for password reset are:

• After a user sends a password reset request, the system sends a reset email to the requested email address.
• The reset email contains a one-time link that expires within a specified time; after the user clicks it, they enter the password reset page.
• After the user sets a password, they can log in with the new password.

This convention is essentially a combination of usability and security. The connections among these steps are fragile; all the steps together constitute a transaction, and the user may terminate the behavior at any step: the reset email may fail to send or the user may not receive it, the user may not click the reset link, the user may click the reset link but not set a password, and so on. Engineers are experienced with transactions: a transaction either completes entirely or rolls back to the previous state, and must never remain in an intermediate state; if rollback is difficult, then the system state should be changed all at once (atomically) only at the moment the entire transaction completes. Password reset adopts the second strategy. In addition, one-time links and expiration within a specified time are security considerations: a user may log in to email at an internet café, and the link may remain in browser history, so the impact of a leaked link needs to be minimized.

Yet someone can build even such a simple feature like this:

• After a user sends a password reset request, the system sets a random password for the account corresponding to the requested email and sends an email telling the user the random password.
• The user logs in with this random password.

Even if the product manager has a wild imagination and tries to simplify user operations by being different for its own sake, an engineer who has accumulated enough product common sense should not accept it wholesale, because there will be serious security problems: What if the email is not sent? What if user A accidentally enters user B’s email? What if a hacker resets other people’s passwords in bulk? As long as users do not act according to the product’s intentions, the product will be in a wrong intermediate state; such a product is fragile.

Engineers with a product outlook have a sharp intuition for the technical problems a product may have, and they firmly believe: technology serves the product, not the product manager.

If mastering product common sense and conventions is the cornerstone of a product outlook, then the advanced product outlook is:

• Being able to learn the ropes of product and feature design from every case worth learning from;
• For new products, being able to grasp product requirements, think about and build product prototypes from the user’s perspective and the technical dimension, and assess product-market fit through technical and non-technical means;
• For upgrades to existing products, knowing the relative importance and urgency of features—at the very least, being able to clarify their technical priorities.

Given space constraints, I will not expand on this topic.

(3) The Data Outlook

Data is a projection of the real world onto a product. A good engineer should likewise be an engineer who is sensitive to data. The Lean Startup teaches us the build-measure-learn loop, which is less a method for building products than a method for learning about everything.

Once we have built the blueprint in our minds, the most important next step is to measure.

Kelvin said: “If you cannot measure it, you cannot improve it.” So the first step in a data outlook is knowing what to measure. To know what to measure, you need to know what the most important KPI is for a given product. Let me give an example from my shallow understanding (it is awkward to use examples from my own company). Take Facebook Ads: its most core KPI should be impressions (ad displays), because its revenue is based on impressions. So impressions are the most fundamental measurement. Whether an ad’s impression has been achieved cannot be decided by Facebook alone; tracking pixels must also be sent to third-party organizations. So pixels are also a key measurement. Working backward from impressions, there is AO (ad opportunity). Facebook calculates various AOs in every timeline: suppose an AO appears every 8–12 feeds in each person’s timeline, but Facebook’s current ad inventory only contains ads targeted at 30–40-year-old highly educated, high-income men. Then a freshly graduated student’s timeline will have no ads, and that AO is an Empty AO (empty ad opportunity), which generates no revenue. Empty ad opportunities can also be used to insert in-house ads, helping to promote one’s own products or drive their growth. For example, in the screenshots I took below, the first is an in-house ads impression, and the latter two are revenue-generating impressions:

Seen this way, besides impressions and pixels, AO, Empty AO, and in-house ads are also objects to measure. So where do these AOs come from? Going one level up, there are DAU/MAU. Because according to Facebook’s business model, more daily active users/monthly active users bring more AOs, and more AOs bring more impressions.

The above is how to measure from the user dimension.

From the advertiser’s dimension, one needs to measure ad inventory, the rate at which inventory is consumed, and the rate at which inventory increases. Because no matter how many AOs there are, they are meaningless without inventory; on the other hand, if inventory is abundant but consumed very slowly, that is not good either.

Measurement is only the first step; next comes analyzing and interpreting data. The ability to analyze and interpret data is an important component of an engineer’s data outlook. The same data, in different people’s eyes, has different emphases, and the conclusions drawn may be vastly different. I will not expand on this.

What is learned after analysis and interpretation needs to be further built back into the product. In this way, technology, product, and data form an organic whole.