The 2016 Programmer's Life Medley

December is the busiest month at tubitv. Advertisers still have budget to burn, and they come charging into the holiday market waving their checkbooks. And our lovely users? This is the one chance they get all year — half-coaxed, half-willing, they take a week or two off to eat, drink, play, and be merry. The beautiful people, of course, are off in Hawaii, Cancún, or Aspen whiling away the hours with nature. The rest of us mostly stay home — and watch! TV! When it comes to Americans’ love of television, it reaches a frankly absurd pitch — according to Nielsen, the average person watches 4.3 hours a day. So you can imagine how a video streaming service like ours welcomes the Christmas season — and how it dreads it: please, Bodhisattva, bless us, whatever you do, don’t let the service go down…

While writing this piece I glanced at GitHub: in December I somehow opened 35 pull requests and reviewed 38. Over the few days off for New Year’s, I filed 3 more, adding 3,800 lines and deleting 1,400.

So the medley I’d planned to write at the end of last month got pushed back, and pushed back again, until now.

(I)

My output in 2016 was lower than in 2015, but the quality climbed steadily (humblebrag). I’ve been writing on this account for nearly three years, and the media library now holds 340 posts. If in 2014 I wrote mostly to hit a quota, and in 2015 to cater to readers’ tastes, then in 2016 I wrote mostly for myself — or rather, as a Pensieve for my thoughts. For me, the best option is when helping myself also helps others. That’s exactly why I’m such an advocate of learning by teaching.

First, the metaphysical stuff: “Software Development Patterns You Should Avoid,” “Technical Debt,” “On Object-Oriented Programming,” “My Thoughts on Engineering and Management,” and “Software Ruminations: Code and Data” — these essays address software development, design, and management from 30,000 feet, and they’re worth reading whether you’re new to the trade or a veteran.

But the metaphysical must eventually land. As a programmer, the first thing you trip over is naming. This is the ultimate question; those who figure it out can move on to researching:

Who am I? Where did I come from, and where will I go when I die? Why must I appear in this world, and what does my appearance mean to it? Did the world choose me, or did I choose the world? Is there a necessary connection between me and the universe? Does the universe have an end? Does time have a length? Where did the past vanish to, and where does the future stop? Is the question I ask at this moment still the question you heard a moment ago?

Back to the point.

We say a name reflects the person. Don’t underestimate naming — bad naming leads to bad code. The first post on my account to break ten thousand reads (sweat): “Naming Code: A Monk Knocks at the Moonlit Gate” is about exactly this. I think many readers felt that pang of recognition, which is why they pushed it and recommended it in their Moments.

Beyond naming, the other thing every programmer bumps into sooner or later is refactoring. I’ve prepared two for you: “The Way of Code Refactoring” and “Refactoring: Writing Decent Code.” I hope they spark something.

As your programming chops grow, the next things to cultivate are the ability to abstract and the ability to metaprogram. And of course, asynchronous processing (“The Mind Game of Asynchronous Processing”) gets more attention every year.

(II)

If you had to split programmers into two camps by force, you could say: those who can write code and those who can’t. Or you could say: those who call APIs and those who write them — the UI folks call the SDK and then call the APIs the backend hands them; the systems folks wrap API around API until they slap a REST skin on it and ship it. Broadly speaking, every programmer both writes APIs and calls them. Every function you write is an API.

Writing APIs — REST APIs in particular — has become a major part of a programmer’s job. So I put together a combo platter detailing my own approach to APIs: “APIs, Take Them, No Thanks Needed.” The big API event of 2016 was GraphQL finally reaching production-ready: “GraphQL.” So does that mean REST APIs might be obsolete? Not within a few years, I think. What will actually happen is REST and GraphQL coexisting. GraphQL becomes the outward-facing window wrapped around REST APIs. A single GraphQL API’s data sources may come from several REST APIs. The two complement each other.

(III)

Professor Randy Pausch, whom I admire most of all, said:

“Fundamentals, fundamentals, fundamentals. You’ve got to get the fundamentals down because otherwise the fancy stuff isn’t going to work.”

I agree with this absolutely, positively, and with total certainty. On the fundamentals front, I’ve carefully simmered up “Concurrency,” “Compilation and Execution,” “The Beauty of Pipes,” and “ZeroMQ.” ZeroMQ looks like a specific application, but the way it thinks about building messaging systems — pub/sub, router/dealer, and so on — is something you absolutely must master. Also, it’s 2017 already; if you still can’t explain at-least-once versus at-most-once message delivery, go back and read it again.

In this profession, the thing to fear isn’t growing old and losing your looks — it’s aging before your time. Technology never holds its value; the knowledge behind the technology is the real fountain of youth. When you set out to learn something new, how should you go about it? I hope “How to Learn a New Technology” helps. Over the past year, many friends have messaged me asking how to learn some technology or other — especially now that Phoenix is catching fire in the community, with lots of people thinking about dropping the half-learned Rails or Django in their hands to pick up Phoenix. So I wrote “Rails, Django, Phoenix: You’re Wrong” to explain why the web framework shouldn’t be the center of your learning, or even of your product development. To borrow the old formula — “Chinese learning as the essence, Western learning for application” — I’d say “ideas as the essence, frameworks for application.” Don’t put the cart before the horse and get lost in the vast sea of frameworks, unable to climb out.

(IV)

Once you’ve written enough code, pay attention to building your own LEGO bricks. This is the biggest difference between a veteran and a novice. Why can a veteran knock out the same feature in no time flat? Because a veteran is assembling bricks, while a novice has no bricks at hand and can’t find any, so he has no choice but to keep reinventing wheels.

The old saying goes: walk often by the river and your shoes will get wet. As one of the few professionals in this civilized age who walk on the blade’s edge, there’s a hurdle no programmer can avoid: bringing the system down. Have you ever deleted a production database? Read this: “System Crashes: How Strong a Heart You Need.” Correct it if you have the fault; guard against it if you don’t.

If the previous post scared you, I’ve got a few steaming bowls of chicken soup in various flavors for your quiet enjoyment:

• Old Soldiers Never Die
• How to Become an A-Player?
• That Wall of Sighs

Think the earlier posts were too heavy, too thick with technical jargon? Come, come — we’ve done the highbrow “Spring Snow”; now for the lowbrow:

• The Programmer and the Hand-Pulled Noodles
• A Casual Chat on an Engineer’s Worldview
• Spring Break Is Every Dad’s Nightmare

If you’re interested in new products, 2016 will disappoint you — I only wrote two posts related to new products: “Hololens” and “Pay As You Go.”

(V)

Beyond the death of ZeroMQ’s author, the other big event in the 2016 tech world, as far as I’m concerned, was the demise of RethinkDB. I quite liked its technology and the Horizon project built around it, and I even wrote a post — “Backend for Dummies (RethinkDB…)” — to cheer it on. What a shame. Once again, technology lost to the market; the idealistic geek lost to the worldly.

At the end of the year came AWS re:Invent. I wrote three posts, all worth reading: “AWS.” Unfortunately, time didn’t permit me to write more. Watch the videos on YouTube yourselves.

New year — thinking about switching jobs? “On System Design Interviews” helps you figure out how to handle a system design interview, and “Turn Left, Turn Right” is a naked plug for recruiting at tubitv. Yes, we’re once again hiring engineers in China (Beijing), mainly Node.js backend and web frontend; Erlang / Elixir / Scala experience a plus. I’ll write a detailed post soon.

Last but not least, the series everyone loves, young and old alike — The Remains of the Day: 1, 2, 3.

Happy New Year, everyone!