2017: 46 Essays on a Programmer's Life

From the first WeChat official-account article in 2014, in just over three years I had somehow written 386 articles, covering technology, management, startups, and some inexplicable reflections. This is the energy that small persistence unleashes: imperceptibly, the bits and pieces of advancing one pawn a day coalesce into such a wonderful result.

I often say: reading my own diary feels like conversing with my past self. The same goes for reading my own articles. This morning, while my car was being serviced at the 4S dealership, I idly flipped through my own writing and felt great—not because I think my writing is so great, but because the ideas shining through the text, mature or not, all carry my growth. With these words (and a few diary entries) as companions, my 2017 was not perfect, and quite a few plans went unfinished, but at least it left something behind.

My first article of 2017, “Policy Engine: Past and Present,” was a wake-up call—a sudden inspiration on a train plus three days of experiments laid the cornerstone for much of Tubi TV’s work that year, and also buried a few nasty pits for the team—and even Elixir 1.7—to fill (for example, this: https://github.com/elixir-lang/elixir/issues/7047). :sweat_joy: The code running in production today is very different from what that article described; a single policy compilation has gone from 10 minutes to a few seconds. But the thinking behind it is still worth a look, and the “How to Write a Parser Pleasantly” mentioned there is also worth rereading.

Elixir was a language I had been following since 2015, but along the way I only wrote small side projects. It was not until 2017, after tasting success with Policy Engine, that I began using it at scale in production. Over the year, the team accumulated a lot of experience, especially in cluster deployment / release / hot upgrade / rolling upgrade—in March 2018 I will speak at Code BEAM 2018 in San Francisco about what we learned in these areas, and I hope you’ll come.

Learning a new language is not as simple as learning its syntax. Early last year I wrote “How to Use a New Language,” sharing some of my thoughts. It applies not only to Elixir but to other languages too.

If you’re interested in Elixir / Erlang, then “Let It Crash: Because of Misunderstanding, Hence Nonsense,” “Phoenix 1.3: Toward the Right Path,” and “God Said: Let There Be a Language for the Future, and There Was Erlang” may be worth your time.

The article “How to Approach TDD the Right Way” discusses in detail some of my takeaways from using TDD, and also covers many design/arch-related thoughts.

“It’s Time to Think About How to Delete Code” is a controversial article, but it gives you a unique perspective on how to write better code. If you agree with “Begin with the end in mind,” then we should think this through carefully: Is it possible that, at the very beginning of architecture, we consider that this code may become a liability in the future, and therefore design it so that it can be easily deleted or replaced?

Last March I attended an OTP training from Erlang Solutions and wrote this: “When I Attend Training, What Am I Thinking About?” The same thing has different value in different people’s eyes; it all depends on how we discover it.

Many people write a lot of code. But the vast majority have read less code than they have written. This is a strange phenomenon—from childhood to adulthood, we have read at least hundreds of millions of characters in books, and after working for years or even more than a decade, we still haven’t read a comparable volume of code. “Why Should We Read Source Code? How to Read Source Code?” I hope it can rekindle your interest in reading excellent code.

To improve software development ability, besides reading more code, you also need to put in hard work. “There Is No Silver Bullet in Improving Code Ability” means exactly this. “Stop, Catch Your Breath, Build a Wheel” tells you that if you keep doing endless odd jobs (do chores) and cannot string them together, if you don’t occasionally do something from zero to one, you’ll fall into the trap of you think you know, but actually you don’t know that you don’t know.

Software development is an advanced pathfinding game from start to finish, testing comprehensive problem-solving ability—although all roads lead to Rome, some are smooth and unstoppable, while others are like standing on the edge of an abyss or treading on thin ice. What we seek is a compromise that is excellent in both time and space while also saving development efficiency. Compromise is not simple—Rich Hickey says you need at least two or more solutions before you can even talk about compromise—so breadth of experience is indispensable. Perhaps the following articles can help:

• The Power of bash
• On State Machines
• On Data Structures
• On Boundaries
• Thinking: Fast and Slow
• service performance 101
• Wasting Memory? What’s the Big Deal?
• Error and Exception Handling: A Brief History

If you’re tired of reading technical articles, let’s switch gears and shoot the breeze:

• A Few Stories About Interviews in the US
• My Social Sister Mei: Beauty and Model Worker
• The Growth Path of a Software Engineer
• How a Startup Should Build a Technical Team
• Why Programmers Worry About Their Future
• When Will the Good Times for Programmers End?
• Don’t Wait for Customers to Notify You of Problems

Or broaden your horizons:

• red: Not Red, Not Expert, but Sexy
• sound of silence: A Niche Black Tech for Data Transmission
• Casual Thoughts on Designing a Bitcoin Arbitrage Trading System
• alexa: The Goddess of My Dreams
• pixel 2 XL: Software Is King

Or look back at the disastrous major events of 2017, using history as a mirror:

• Lessons Learned from the GitLab Incident
• The North American Internet in Woe: S3, Which Claims 99.9% Availability, Goes Down

Or go listen to a few of my live talks on Zhihu:

Then, lie down on a beanbag sofa and think: as a programmer, what should the awesome version of yourself look like in your own eyes? If you have no clue, check out this piece, passionately recommended by Programmer Jun: “Programmer Dictionary: ‘Badass’.” Then think again.

I will be especially busy in 2018—over the past few years both input and output have been considerable, but mainly within my comfort zone. In 2018 I will step deeply into fields where I previously had only crude knowledge: ML/DL and blockchain (mainly decentralized applications based on smart contracts). I have signed up for some offline and online courses; in the first quarter I will spend about 10 hours a week in class, and probably the same amount of time consolidating what I learn. So my output of original articles will drop sharply; I’ll aim for one update every ten days, or at worst biweekly. Please forgive me.