On Work: The Digital China Chapter

My career isn’t especially long, but it isn’t short either — eleven years of working life, just past thirty. Writing an article like this is honestly awkward. Set aside the two years of founding a startup, and I have only nine years of experience inside companies; and more awkward still, in those nine years I’ve worked at just two companies, both in the same industry — which seems rare in the fast-changing world of IT. So what I have to say may not resonate with everyone.

For ease of exposition, I’ll follow a timeline. This installment covers my time at Digital China Networks.

In “On College” I mentioned that after my bachelor’s degree I joined Digital China Networks (DCN). DCN’s predecessor was Lenovo Networks, born out of the Chinese Academy of Sciences, with a dense R&D pedigree. Relative to the Digital China family, DCN was like a little brother still in startup mode. In 2003 Mr. Guo (Guo Wei) was full of ambition and ready to stretch his limbs — the “brotherhood pact” with Lenovo had expired, and he could hardly wait to charge into the PC market; at the same time, coveting the emerging mobile market, he dabbled in handsets too. The result was fighting on multiple fronts and retreating on all of them, with enormous losses — on the financials, provisions of over a hundred million Hong Kong dollars were booked for the handset business alone (credit for that also goes to the strategy McKinsey had prescribed). “Provisioning” — such a lofty word — is something I picked up then. Digital China’s overall climate was poor, but DCN’s microclimate was excellent; in proper “Lenovo style” it was called a second-stage rocket. Compared with the company’s main business — distribution, the cash cow — DCN represented Digital China’s future, so the atmosphere was relatively relaxed. The HR sisters and programmer brothers I dealt with were all very nice.

Barely had I joined, still muddled, when I was rounded up for a week-long “mold-fitting training” — Lenovo’s classic corporate-culture training, heavy with chicken soup and positive energy. These days people are so put off by the overdose of chicken soup that they turn pale at the word “soup” and avoid it like the plague. In truth, as long as you listen with your brain engaged, chicken soup is pretty good; after a week I felt I’d gained a great deal. To do well in a company you need to accept its culture and carry a sense of honor in your work. Many of President Liu’s (Liu Chuanzhi’s) sayings — “A company is a mold; once you arrive, you must fit yourself into our mold,” “Running a company is running people,” “Lay a layer of earth, tamp it down, then lay another layer” — I agree with all of them. My biggest gain from that training was meeting a group of talented men and women, full of scholarly ardor and boundless spirit. Over eleven years, through all the shifts and storms, we still care for one another and stand by each other heart and soul.

When the training ended, I threw myself into work, brimming with energy. DCN was then pushing routers and switches; I was assigned to the router group, mainly to take over OSPFv2 (a routing protocol) from an engineer named xiahm who was about to leave. And he, by natural course, became my mentor. He helped me enormously. Though I’d accumulated plenty of development experience in school, I had never really touched a protocol (the TCP/IP I’d poked at through sockets didn’t count), nor read the Linux kernel, so faced with a router system assembled from Linux plus gated (an open-source routing-protocol platform) I was completely in the dark. xiahm was diligent and conscientious, leading me into the field hand in hand.

Life always holds many “firsts” you can’t forget — your first mentor, your first line of code running in a commercial system. When I submitted code for the first time to fix a bug and wrote my name in the comment, the excitement was beyond words.

A month later I received my first probationary salary — after tax, a bit under 2,500 yuan. Measured against the tidy monthly income from a side project I was still working on, it was negligible. But the side project could give me money, not room to grow. Building a person and building a company are much alike: do you sacrifice growth for high returns, or sacrifice returns for high growth? Each has its trade-offs. Different stages of life call for different choices, and those choices are deeply personal.

Back then a three-bedroom in Huilongguan rented for 1,800, and I shared it with two colleagues, zhangchi and chenyj. zhangchi was in the hardware department; chenyj and I were both software. chenyj and I often discussed software problems, so we talked more. He kept urging me to spend 50,000 yuan on a slot for an affordable-housing unit in Huilongguan and then take out a mortgage. I thought 2,600 yuan per square meter for a godforsaken place like Huilongguan was highway robbery, and flatly refused. Looking back, I was a frog in a well with a pitifully narrow worldview — I had eyes only for the bright lights of the Asian Games Village and looked down on Huilongguan’s barrenness. A year later I turned down my girlfriend’s proposal to buy a 100-square-meter flat in Tiantongyuan for 500k on almost identical grounds — stubborn and narrow-minded; laughable, lamentable, infuriating.

zhangchi and chenyj were both hard-working, promising young men, and they influenced me a great deal. The three of us rarely used the TV in the living room — except for weekend matches. zhangchi was an Arsenal fan, chenyj a die-hard Manchester United supporter; that was the era when the two Premier League giants were locked in a death grip, and at every match the two of them would cheerfully trade snide remarks about each other’s team. Beyond that, each holed up in his own little room studying hard — one preparing for IELTS, the other plotting a move to Australia. This left me, who came home every day to play games and read novels in my little nest, rather uneasy; I always felt a sense of sin playing StarCraft 1v7 with “show me the money” on. Eventually I uninstalled the only game on my laptop and threw myself into reading. Mencius’s mother choosing her neighbors has real wisdom to it: the friends around you define you to some degree.

Speaking of friends, I must mention those I met in the mold-fitting training. Back then we got together whenever we had time; a group of young people on outings, at karaoke, on the ball court — and beyond that, talking about our work. Every one of them was driven, striving away in a strange city, and that always spurred me on. If success is defined by personal achievement or social standing, then my friends all count as successes — quite a few are doing better than I am today. Time is a butcher’s knife, and also a touchstone: the gap between people at graduation is not large, and our schools were not markedly better or worse, yet ten years is enough to pull two people apart to an unbridgeable distance.

Two or three months into the job I was already a seasoned hand on the team. The National Day holiday arrived, and with nothing to do I decided to translate RFC 2328 (OSPFv2). It wasn’t a whim — at work, apart from dealing with Linux, I was forever wrestling with that long English document. Protocols are picky about wording: MUST, SHOULD, and MAY have strict definitions. To determine whether some small behavior conformed to the spec, I had to read a long passage of prose refined down to dryness and chew it over carefully. My English reading was still poor then; I’d read RFC 2328 two or three times cover to cover and always forgot the front by the time I reached the back, so whenever a problem came up I had to reopen it and read again. Unable to bear it any longer, I decided to spend the holiday reading and translating at once, practicing as I went. After three or four days of nearly round-the-clock work, I’d translated the document’s core. So much so that I later became the person on the team with the clearest grasp of OSPF; reading the OSPF-related code in gated was like lines of code jostling one another to explain their lineage to me — suddenly much easier. (A pity that the internet was underdeveloped then and UGC wasn’t fashionable; that translation only circulated inside the team, and today I can’t even find a copy of it myself.)

In 2004 I became a core member of the team, and my salary doubled. DCN was then negotiating a partnership with ipinfusion to adopt their commercial codebase ZebOS across the board (a commercial routing-protocol platform similar to gated, including OSPF, BGP, RIP and full IPv6 support, derived from the open-source Zebra). Because my spoken English was tolerable (really just thick skin and the nerve to speak up), the team put me forward as its representative to learn from, communicate with, and coordinate with ipinfusion’s engineers. ipinfusion took the partnership very seriously; the founder (and CTO) Ishiguro came in person to demonstrate and teach us ZebOS. Ishi is a Japanese-American with a slightly stiff accent, but his English was far easier on the ear than the “standard” Japanese English that turns “computer” into “konpyūta.” This was my first encounter with a legendary figure of the industry (Ishi is also the founder of Zebra), and I was nervous and thrilled. While explaining code logic, Ishi used a 17-inch MacBook (a PowerBook back then) for various demos, which amazed me and made me envious; but the most stunning moment came when we reported a BGP bug to him — the man conjured two more Macs out of his bag, wired them into a simple network topology, and started debugging. His hands flew, fingertips hammering the keyboard, the cursor darting across the screens, and in no time he turned around and, ignoring my idol-worshipping pig-face, said mildly, “OK, done.” Only later did I learn that there is an editor called vim, an operating system called Mac OS (today’s OS X), and a state of work called flow.

During that stretch I learned things unusually fast; every cell in my body seemed mobilized. I let no detail slip; whenever I had a question I seized the chance to ask Ishi. It was partly thanks to this that I was soon able to back-port netlink (a mechanism for kernel–user-space communication under Linux) from the 2.2 kernel to the 2.0 kernel DCN was then using, and make it work perfectly with ZebOS.

If Ishi showed me what a “master” looks like, then suzg, the leader of the driver group at the company, taught me to broaden my horizons and embrace a bigger world. The path in datacom products is actually narrow; the company’s achievement is the ceiling of your personal achievement. Someone of my mediocre talents could hardly build a product single-handedly, so as a career moves forward you either rely on deep system-level understanding to make a forceful pivot, or you stay in this circle forever — there seemed no other way. suzg was different: in his spare time he tinkered with all sorts of new technology. When Wikipedia became popular, he set up an internal KB (knowledge base) with MediaWiki, with a board for each group, so that R&D knowledge could be shared across the whole company. I was a heavy Wikipedia user then (in 2004 it hadn’t been blocked yet), and when I saw the system he’d built I was stunned — knocking out something like that in his spare time, to the benefit of the entire company, was remarkable. Under suzg’s guidance I quickly figured out the whole LAMP/WAMP stack behind MediaWiki and discovered how much open-source software existed in the PHP world (very different from .NET), and I began tinkering with all kinds of open-source internet software on my own machine.

Since then I’ve been hooked on raising productivity through tools. MediaWiki was a fine example. Previously, internal documentation was shared via email plus file servers — inefficient, and finding anything was a pain. A collaboration tool like MediaWiki instantly made the sharing system of a development team of dozens far more efficient, and more importantly, we gradually built up a knowledge base that accumulated. That is the power of tools.

In 2004 DCN began pushing daily integration (it hadn’t yet reached the heights of continuous integration). Before every commit, developers had to run a test suite provided by the test group — a painful process:

1. First, borrow a test environment from someone who has the equipment (test or dev)

2. Build the target system image on your own machine

3. Load the image onto the test device

4. Run the test suite

I was having a ball learning PHP at the time and figured this could be automated, so I asked my boss for a PC and three devices and built a test environment. The PC ran a web service I wrote; the basic idea was that the user submits an image, a job is created, and the web service takes care of the rest. As I went along I ran into PHP’s limits (my prejudice at the time) — fine for websites, but strained for backend services. So, on suzg’s recommendation, I learned Python — because writing such a system in C would burn a great many brain cells. Thus the automated test platform took shape:

1. Users visit a URL to submit the image to be tested, creating a job — implemented with WAMP.

2. A Python service polls the MySQL database when idle, finds unprocessed tasks (I didn’t know about message queues then), then uses pyserial and secureCRT’s Python interface to connect to the device under test, upload the image, and invoke the test scripts.

This ugly, relatively simple tool, which didn’t take much effort, improved the team’s efficiency. And it was this little thing that first earned me a nomination for that year’s Digital China “Golden Horse Award” for top-ten technology achievements, and then the award itself — within a company that included DCN, DCS and many other subsidiaries, with at least several hundred, if not a thousand, R&D people, winning such a relatively “rare” award was truly fortunate.

Of course, what won me the award wasn’t just this “off-task” tool, but also a series of product features I developed: OSPF2/3 (mainly maintenance), IGMPv3, SNTP, the netlink back-port, and so on. Do well what you’re supposed to do, and only then will your boss give you more room to play; only then will you have the chance to go “off-task,” and only then will you earn greater recognition.

Paul Graham says in Hackers & Painters that good work combines “measurability” and “leverage.” In a “small” team like DCN, individual contributions were relatively easy to measure (writing IGMPv3 myself, for instance — good or bad, I bore it alone), while tools like the automated test platform had leverage, because they affected the productivity of the entire development team of dozens — if each person gains ten minutes a day (the actual time for the whole flow was far more than that), the aggregate efficiency gain is considerable. I think I benefited from both.

The greatest benefit of the Golden Horse Award was a free trip to Europe in 2005. A trip to Europe costs at least ten thousand yuan, which is nothing today, but for me then, earning only five or six thousand a month, it was like a gift from heaven. At twenty-three, I held my first passport and stepped out of the country for the first time. At the Trevi Fountain in Rome I made a wish: within three years, I would return to this place. Two years later, the wish came true. But that’s a story for later. Life is like that: when you want something badly enough, no matter how hard it is, you will find a way to get it.

2005 was a turning point for me. Encouraged by my girlfriend, I enrolled in a part-time master’s program in IT project management at Beihang University — a field I was genuinely interested in. The curriculum was intense: in the first year, classes ran 6:30–9:30 p.m. Monday through Thursday every week, plus both weekend days every other week; and outrageously, the May Day and National Day holidays that year, plus an extra full week of leave, were consumed by five or six courses taught in concentrated blocks by professors from the United States. Classes ate nearly all my spare time, yet I discovered to my delight that the harder you push yourself, the more time you seem to have. Because of classes I couldn’t work overtime every day (overtime in an IT company is nearly inevitable), which annoyed my boss — but I finished my work more efficiently and dissolved the annoyance into nothing; the heavy coursework instead pushed me to manage my time better. While slogging through the PMBOK, I also read more books on management, especially project management. For a whole year, from March 2005 to March 2006, I lived with unusual fullness.

Many people treat a part-time master’s as a way to bag a credential, but mine was driven purely by interest — I felt that if I kept at this line of work I would eventually lead a team and lead a project, so preparing theoretically before practice is better than cramming at the last minute or being thrown in at the deep end. So I read a good deal in that area and eventually found and enrolled in Beihang’s program. Many student readers ask me whether to go to graduate school or start working after the bachelor’s; I always advise: if you can find a good job, work first — discover your interests and shortcomings on the job, and then pursue a part-time master’s with that interest in hand. That is more meaningful. Also, studying on your own hard-earned money feels very different from studying on your parents’ money; money earned through sweat is cherished more. One man’s opinion, for reference only.

In the second half of 2005, work grew easier and easier for me, becoming almost repetitive labor, while friends at IBM and Oracle kept telling me about — and showing me — the benefits of foreign companies. Foreign firms were at their peak then, not the generally sluggish state they’re in now; IBM, Microsoft, HP, even Motorola were the stage every engineer dreamed of. My industry background and language background (C) made such software companies hard to enter, so I set my sights on Cisco and Juniper in the same industry. Cisco had no R&D in Beijing then, so Juniper became almost the only choice. Ordinarily, a small bachelor’s like me — no top-tier school pedigree, only two years of experience — wouldn’t catch Juniper’s eye. But Juniper’s China R&D center had just been established and was hungry for talent, and my former colleague yangkai had just moved to Juniper as a QA and was willing to refer me, so my resume made its way to the hiring manager, shalang. shalang was looking for someone to do test automation, was intrigued by the automation platform on my resume, and set up an interview.

The interview went ideally. shalang saw some potential in me and didn’t quibble over my years of experience or my degree; he gave me an offer, and my scope of work would involve firewall development rather than tooling, which delighted me. I’ve always positioned myself as a software engineer; building tools is a side gig for me, and I’ve always believed that unless you work on the front line you can’t taste the sweet and the bitter, and therefore can’t build effective tools. So to do development at a foreign firm like Juniper — and on firewall products protecting the networks of household-name enterprises (AT&T, NTT, BOA, China Mobile, the big five banks) — made me enormously proud at the time. Without exaggeration, joining Juniper completely changed my career and the trajectory of my life.

Joining Juniper at that particular moment in 2005 brought me another unexpected gain: unconventional room to grow. If this article has a takeaway for you, let it be this: if you have the choice, join a smaller company that is on the rise and growing fast. The examples I know are Huawei before 2001, and Baidu from 2004 to 2006. Of course, hindsight is easy, but standing inside the whirlpool of history it’s hard to judge whether a smaller company has a chance to survive (3721, for instance, was better known than Baidu in 2003 and 2004), so this choice carries somewhat more risk. For the risk-averse, we can derive from it a lower-risk, higher-reward variant: if you have the choice, join a recently established domestic branch of a foreign company that has already succeeded (or initially succeeded) in other markets. Juniper from 2004 to mid-2006 is the archetype. When I joined, the ScreenOS team had just over ten people — few people, lots to do, high visibility, a fine fit for “measurability” and “leverage”; as long as you work hard enough and are good enough, you will stand out. And Juniper was already relatively mature in the global market, so the risk of collapse was nearly zero. After the second half of 2006, the team’s skeleton had basically taken shape, and later joiners had to work much harder for a chance to stand out. Of course, I didn’t understand this “law” of the workplace from the start; it took two years steeped in Juniper to slowly discover it. If you ask me which foreign companies fit this law this year, I’d say at least Airbnb and LinkedIn.

After receiving the Juniper offer, on September 26, 2005, I officially reported for duty at Juniper.