The Technologist's Vision
For me, weekends are far busier than weekdays. Taking my child to classes, reading, and playing are mandatory courses. That is also why on weekends I sometimes publish articles earlier than on weekdays. A friend once reminded me that the news says it is useless to send such a young child to various early-education classes; it only brings unnecessary pressure. I don’t think so. I believe whether a course is useful depends on whether the child likes it; adults don’t get the final say. As far as I’m concerned, I can only provide various opportunities and necessary guidance—if she doesn’t like something, I won’t force her. Why should I trust experts who have nothing to do with me, and condemn all early education without even trying it? The result of my music class is that my daughter now starts dancing rhythmically as soon as she hears music. Once we went to Chaoyang Joy City, where a cosmetics counter had hired a beautiful woman to play the violin. As soon as she heard the melodious violin, she danced joyfully in my arms, so I followed the sound, found the place, put her down near the cosmetics counter, and let her dance. So the little one danced for a long time in front of everyone to the melody, and even the violinist was moved and specially played Jingle Bells to add to the fun.
Recently I’ve been doing a rather infuriating ‘reinventing the wheel’ job. To explain this better without revealing details, I’ll put it vaguely: I’m working on some very basic component at the system layer. This is a typical feature that we could complete using existing implementations (including very mature open-source projects), and there is no need to write it from scratch. However, the project’s technical lead pointed out many shortcomings in existing implementations—too complex, not matching the project’s specific needs—so we have to rewrite it ourselves from scratch.
On this issue, my view has always been clear: as long as the existing mature implementation does not have an essential, unusable problem, we should not rewrite it. Although a few hundred lines of code are no big deal during development, what about testing? Maintenance? Future extension? A few hundred lines of code may be a week’s work (actually more than a few hundred lines; I’ve worked on it part-time for more than a few weeks), but the workload it brings later is far from simple.
Unfortunately, I don’t get to decide. I strongly opposed it, but I couldn’t influence the other side, so I had to withdraw my opposition and obediently follow the established route. Actually, from a personal perspective, rewriting such code is very good for improving my abilities, but for the project, it truly has little benefit; instead, it spends time and resources where they shouldn’t be spent.
Although this issue is only a technical one, at a deeper level it is a matter of vision. Technical people are often prone to immersing themselves in details and unable to extricate themselves—we are too familiar with and too passionate about what we do and the tools we use, while neglecting the larger world. In addition, technical people overestimate their own abilities and ignore the consequences of the big picture—we are too confident (arrogant) about our abilities and our control of progress, so much so that we delay projects.
Compared with internet people, this limitation of vision is much more likely to occur among telecom people. I think there are the following reasons:
(1) Telecom people are in a closed ecosystem, while internet people are in an open ecosystem.
In the telecom world, much of the intellectual property used across the ecosystem has to be purchased, whereas in the internet world, the entire ecosystem is built on open source and open intellectual property. In a closed ecosystem, people’s thinking also easily becomes closed. When you use ‘closedness’ to build a moat and protect your castle, then, apart from your own little plot, you rarely care about the outside world. For example, after doing FreeBSD for a long time, we don’t even know that there are so many fresh tools under Linux systems and so many advanced features in the kernel. In contrast, in the internet world, openness has created a situation where a hundred flowers bloom; everyone goes into battle bare-chested and competes openly. As a result, you must constantly pay attention to the latest and best technologies, so that once there is a need, you can verify it as soon as possible.
(2) Doing telecom is large-scale group warfare; doing internet is the ‘decapitation strike’ of special forces.
Of course, this is not absolute; it is only generally speaking. In telecom, it is rare for a project to be done by just a few people—at least dozens—while an internet project can start with just a few people. When you have only very limited resources, you will try as much as possible to ‘stand on the shoulders of giants,’ integrate every resource you can, and use your best steel on the blade; but when you have many resources available, without a clear understanding, you may well integrate resources into unnecessary scenarios.
The problem of vision, if it only occurs at the execution level, is not a big deal; but if it occurs at the decision-making level, it will have a serious impact on the project. The way we think about products now is very different from ten years ago; in many cases, what is being contested is the ability to integrate (open-source) resources. If Instagram and WhatsApp had not integrated various existing resources and had done everything themselves from the start, they would certainly not have been able to quickly develop products for market validation.
