The Programmer’s Dictionary: “Awesome”
In a job posting I once published for the TubiTV China team, I wrote the basic requirements page like this:
As programmers who are already fated to spend most of our lives with code, the “small” goal of our careers is mostly to become an awesome engineer. Not everyone can be as great as Linus Torvalds, Bill Joy, Joe Armstrong, and other elders, leaving an indelible contribution in the long river of human history, but the next Linus is bound to be born from among us.
So how do we define awesome? Or, how does one become a programmer whom everyone loves, at whom flowers bloom, and whom HR wants to latch onto the moment they see them? We know that “awesomeness” can be quantified through results, but the process of approaching awesomeness step by step cannot be quantified—just as a programmer’s performance should not be measured by how many lines of code they wrote or how many PRs they shipped. Such metrics can, to some extent, define industriousness, but they cannot define excellence.
This programmer fell into deep contemplation, thinking while also wanting some quiet.
After several days of desultory thinking and countless revisions, I settled on the following points. Just as a thousand readers see a thousand Hamlets, my definition may not convince everyone, but it does, in some way, express my attitude.
My WeChat friend Zhang Mazi messaged me: “Explain it to me—what the hell is ‘surprise’? No, wait, awesomeness.”
This programmer fell into deep contemplation again, thinking until my hair turned white overnight—more Wu Zixu than Wu Zixu. Come, let’s take them one by one.
Understand why we build stuffs
Programmers are natural creators. Every day we are either creating something new or on the road to creating something new. Yet not everyone knows why we are creating a given thing, or understands the value and meaning of what they create. In his famous talk, Simon Sinek said that great leaders start with why. In today’s hypercompetitive age, users will not buy a product merely for the features it provides; they will buy a product with the same features but imbued with some meaning that resonates with them.
Likewise, programmers need to seek out such meaning. When we start a new project and write code all night without tiring, the meaning may be to learn and master some data structure or methodology; when we spend a whole day solving a tormenting bug, the meaning may be to turn a group of users furious about that bug into users who regain confidence in the product; when we ship a feature after a month, the meaning may be to increase the company’s revenue by 10% or reduce expenses by 5%.
Once we understand the meaning of what we do, we tend to be more motivated and more willing to pour in blood, toil, tears, and sweat. In fact, if you think about it carefully, in a person’s life, the things worth remembering are often tied to blood, toil, tears, and sweat. Many times we accomplish nothing not because we are incompetent, but because we have not found a meaningful thing for which we are willing to spend our passion without reservation.
Sometimes meaning is not so obvious. If you contribute code to WeChat and make life better for hundreds of millions of people, just thinking about it makes your blood boil. But if you work on a project that may not even have many users, or where you don’t even know where the users are, what is the value? What is the meaning?
Smart programmers actively seek out this meaning. They will ask their boss, their boss’s boss, or their boss’s boss’s boss, until they find it. If the boss happens to be themselves, they need to return to the original intention behind doing the thing.
Thus says this programmer: great programmers start with why.
Have a strong sense of ownership
A sense of ownership is a core component of chicken-soup self-help. I don’t need to explain this much. If you are a parent, you feel it especially deeply. Our code (or product) is like our child, requiring careful care and cultivation.
Many readers may not yet have had the experience of raising a child. Let me give an example from my own life. Recently I started taking my older daughter to learn ice skating: class on Saturday morning, practice at night.
My daughter is a girl thoroughly poisoned by Disney—especially successfully brainwashed by Frozen—and her love of ice and snow far exceeds that of ordinary people. After the half-hour morning class ended, the other kids all let out a long sigh of relief: “Mom, thank God it’s over.” My daughter, however, cried her heart out, saying she hadn’t skated enough and wanted to skate more. Because the ice rink is used for classes during the day, I can only take her to skate for an hour during the 8 p.m. practice session.
Taking a four-year-old to skate is exhausting. You have to lower your center of gravity so you can communicate with her better, and you have to protect her at all times from being knocked flying by half-skilled skaters. The veterans on the ice are not scary: they skate as they please, freely and effortlessly, and no matter how fast they go, you don’t need to worry. Beginners are even less scary: they tremble with fear, can’t build up speed, have little momentum, and are nothing to worry about. But the half-skilled ones—who have just learned the rudiments and already dare to tear across the ice, speed soaring, going straight and unable to stop, hitting anything in their path, gods and Buddhas alike—those are the most deadly.
My daughter is smart and not afraid of falling. After two times on the ice she shook off my hand and skated by herself, occasionally managing to skate more than half a lap in a row, so she counts as an entry-level half-skilled skater. As we know, when a half-skilled skater meets another half-skilled skater, it is Mars colliding with Earth. Newton’s second law tells us that when two meet on a narrow path, the one with greater momentum wins. Compared with adults, my daughter’s momentum is at best that of an asteroid in the Kuiper Belt.
So I have to follow carefully beside her, calibrating the distance just right—too close and I interfere with her; too far and I can’t protect her. When she falls, I crouch down and make a fan shape with my hands, loudly encouraging her to get up and keep going. When she skates well, I clap like a coach, giving her confidence to keep accelerating, while every hair on my body stands on end, constantly locking onto several large half-skilled skaters who might threaten her path. At the first sign of potential danger, depending on the situation, I either swiftly scoop her out of the dangerous position or step forward and use my body to block the potential collision. After an hour of this, I am more exhausted than Francesco Toldo was against the Netherlands at Euro 2000—parrying high and low, my body about to fall apart, barely keeping the little girl from harm.
Sometimes after a busy Saturday, I’m really too tired at night and don’t want to go to the ice rink to “suffer,” but one word from my daughter and I take her without a second thought. No matter how listless I was before, once I step onto the ice, the Force begins to awaken. Although my frame still looks frail next to the tall, strong people in the rink, the aura of a protective parent is no weaker than that of a rampaging Hulk.
This should concretely illustrate a sense of ownership. If developers had this attitude toward the products they build, and ops had this attitude toward the servers they manage, what obstacle could not be overcome?
Be careful not to confuse a sense of ownership with a religious mindset. A religious mindset will, for no reason, resent, refute, or even revile any criticism of the thing it protects. Toward criticism, a person with a religious mindset sees it as “blasphemy,” even when the criticism is well-founded. A sense of ownership, by contrast, often means loving deeply and therefore reproving sternly: correct the fault if you have it, and take it as a caution if you do not—just as truly qualified parents treat their children.
Really finish stuff
The degree to which one finishes what one starts is one of the necessary conditions for excellence. A true fierce general begins with the end in mind and will not stop until the goal is reached.
Why use “really” here—or even “genuinely”?
Many times, is what we define as “done” really done? For a feature, is code complete “done”? Is bug-free “done”? Is caller-friendly (say, code with comprehensive documentation) “done”? Is deployed to production “done”?
This series of questions can go on and on. On different occasions, whether something is done has different definitions; put your hand on the Analects and search your conscience.
As someone with an extreme fondness for chestnuts, let me give you another chestnut.
For example, suppose we run an experiment. Is it done when the code is written? Obviously not. Since it is an experiment, we need to learn from it the difference in behavior between the experiment group and the control group, and explain that behavioral difference as objectively as possible—until we understand the gap between that difference and our expectations and know how we can do better next time. Only then is it truly done.
Yes, now it is very clear: any “completion” that cannot feed back into the feedback loop is not really finish.
Why am I so obsessed with build-measure-learn? The end of coding is only the beginning; what we learned is the end of one loop.
deliver with full fledged solutions
To be honest, it is not hard for a programmer to solve a problem. What is hard is a full fledged solution. These days, whenever a new framework comes out, it ships with a todo app example; I believe the coders in attendance have all written one.
Writing a todo app is too damn easy. With some frameworks, you can get everything from backend to frontend done in under a hundred lines.
But that is not a productized thing, not a full fledged solution. When a user uses your app in the browser and types ten characters, and—biu—Chrome crashes, what then? Lost is lost? You have to at least periodically save to local storage so that the user’s loss is minimized.
Then you need to store the data in a database, and the database needs backups.
To deploy this service, you need deployment scripts. Deployment scripts cannot only consider deploy; they also need to consider provision. After all, you are running a business worth hundreds of thousands per second, and you need to keep adding servers.
You need a monitoring system to know the service status at all times. Otherwise, when the boss asks, “Xiao Yuan, how many todos did users create in the past hour?” or “What’s the current concurrency per second?”, you can’t very well say, “Sorry, I don’t know.”
You need an alerting system so that when a black swan event occurs or a serious bug—the dreaded “Eighth Prince”—crashes the party, you know at the first moment, instead of eating hot pot and singing songs while your boss suddenly calls: “Xiao Yuan, the server has been down for an hour, what the hell are you doing?”
full fledged solution. If you still haven’t figured it out, look at the image at the top.
zero tolerance to shit in products
Awesome programmers cannot tolerate grit in their eyes and will not muddle through.
A colleague of mine was debugging a bug until past midnight a few days ago. When I talked with him about it, his attitude was: if I can’t fix it, I can’t sleep soundly.
Andy Grove said that only the paranoid survive. In the world of programmers, the growth curve of the paranoid is more graceful. Life is a stack of problems, one after another; awesomeness is simmered out of layer upon layer of sweat.
zero tolerance to recurring tasks and bugs
Awesome programmers do not do repetitive work—not because they disdain it, but because they find ways to reduce or even eliminate repetition.
Code duplication is solved by refactoring. Best of all, avoid duplication at the moment you write the code.
Code boilerplate is solved by snippets. While writing code, maintain and update your snippets at the same time. Atom, Vim, and Emacs all have good snippet tools.
Recurring bugs are caught by test cases. When a bug appears that was not caught, that is a perfect opportunity to add a test case. A couple of days ago I wrote about TDD, but only discussed features, not bugs. The TDD way to fix bugs is to first reproduce the bug with as general a test case as possible, then write code to fix it. This ensures that bugs of the same kind will not recur.
Recurring tasks are handled by tools like Makefiles, scripts, and cron jobs.
All of the above not only reduces various manual errors at work but also saves you a great deal of time. What is the most precious thing in the twenty-first century? Talent! And as one of the key talents—the coder—what is most precious? Time!
What do awesome programmers do with the time they save? Read, learn, and write code, of course. How else are they supposed to tear down the road to awesomeness? ^_^ (Just kidding.)
Being experts but open minded
Awesome programmers’ tech stacks can change as needed. They keep an open mind about technology and do not have near-religious fanaticism about the technology they have mastered, as if only what they use is the best and most awesome in the world. Instead, they compare the pros and cons of various technologies and their use cases, and use the right technology in the right place.
No need to explain this; everyone understands. I once wrote an article called “programmer’s dilemma,” discussing the bad consequences of becoming an expert and then resting on one’s laurels.
Always make your team a better team
The last point, and a particularly important one: awesome programmers make the people around them better. If you have done all the previous points, your awesomeness is a loneliness all your own; only by doing this one are you recognized by everyone as awesome—do not say the road ahead has no kindred spirit; who in the world does not know you?
You can help the team in many ways: design discussions, interface reviews, code walkthroughs, knowledge sharing, writing articles, hands-on mentoring, and so on, so that people on the team can grow. In this process, you will find that your seemingly “selfless” labor is not wasted. While you help others succeed, you are also succeeding yourself; while you help others improve, you are also constantly improving.
Recently I have been giving the team Elixir training: English training with the SF team during the day, Chinese training with the Beijing team at night. Although I repeat the same content twice, each time I discover many places where I only half understand (know what I don’t know). I have now taught it three times and invested nearly ten hours. The team has certainly learned a lot of new knowledge and skills, and I have gained a great deal myself.
If the previous items are still goals I am pursuing, on this one I am already close to graduating.
