A Programmer's Guide to Productivity

Rule 1: Try Not to Do Software Development on Windows

Unless you build software exclusively with .NET, OS X or Ubuntu makes for a far better development platform. Countless excellent tools install with a single command on OS X/Ubuntu, yet on Windows can cost you an order of magnitude—or several—more time to set up. And that’s before we even mention the tools that have no Windows equivalent whatsoever.

If you don’t accept Rule 1, then just skip everything below and be on your way.

Rule 2: Use an MBP If You Can

I’ve already made the point in “Spend Money, Not Time”: if you can afford the high-spec 15”, don’t buy the low-spec 15”; if you can afford the low-spec 15”, don’t buy the 13” (a Retina/SSD version is mandatory). As a developer, you really ought to be good to your tools—after all, you spend far more time with them than with your girlfriend or wife!

If you genuinely feel an MBP is too expensive footnote:[It honestly isn’t; a 13” Hong Kong-version MBP runs about 8k], consider a thin-and-light 15” laptop loaded with Ubuntu.

The MBP’s advantage isn’t about prestige footnote:[Though sometimes prestige does put you in a good mood, which indirectly boosts productivity], but about excellent hardware plus excellent Unix-compatible software. A Retina display, extraordinary battery life (compared to a PC), and a comfortable trackpad raise your working comfort by no small margin; on the software side, powerful system features like Spotlight boost efficiency substantially. I won’t belabor this—go read MacTalk: Life Meta-Programming yourself.

Rule 3: Use a Large External Monitor

You use an MBP at work for portability—so you can develop anywhere, handle meetings, and deal with all sorts of presentation needs. But once you’re parked at your desk for hours on end, deep in concentration writing code, you’d better have a big screen.

How big? As big as your machine can drive—if you can swing 27”, don’t settle for 24”; if you can swing 24”, don’t settle for 21”; if you can swing 21”, don’t just use the laptop’s own screen. A large monitor lets you display several windows at once without constant switching. My current setup is a 15” MBP + 27” Apple Display. Once you’ve used it, you can never go back—I don’t even mind spending twelve hours a day at the office.

I usually split the screen in half: Chrome on the left, iTerm on the right. That way, while writing code in Vim, I can look up documentation at any moment. Paired with Vim hotkeys, I can use <leader>xx to open a language’s documentation in Chrome without ever touching the mouse.

Rule 4: Use Dotfiles

A programmer may spend 80% of the day dealing with the shell. A good shell (bash or zsh) plus sensible shell configuration will absolutely boost your efficiency by a large margin. I used to use mathiasbynens/dotfiles as-is; later, after I’d tweaked things enough, I simply forked my own version, tyrchen/dotfiles, and put my changes there.

You don’t need to build dotfiles from scratch—just find the most-starred one on GitHub and clone or fork it. This is what they mean by standing on the shoulders of giants. In the martial arts, opening your ren and du meridians often takes more than diligence; it takes serendipity—like Xuzhu meeting Wuyazi, or Zhang Wuji encountering the white ape. In the programming world, the Wuyazis and white apes all live on GitHub; you just have to go find them.

My own dotfiles grew out of Mathias’s. I made two main changes:

• Swapped the prompt for the dead-sexy liquidprompt
• Made Vim use Vundle and enabled a pile of my favorite plugins (more on that shortly)

Rule 5: Pick an Editor and IDE That Fits Your Hand

As a developer, you need to carefully choose an editor that fits your hand for editing code. I used Vim for several years, then switched to Emacs for over half a year—to force myself to get used to Emacs, I even aliased vim to emacs in bash. But in the end, unable to open Emacs’s ren and du meridians, I simply couldn’t resist the excellent plugins under Vim and returned to the Vim camp. So on the editor front, I can only speak to Vim, which I know better.

Setting aside the basics of Vundle, here are at least the plugins you deserve to have:

• SirVer/ultisnips: A godsend for writing and using snippets—anyone who’s used TextMate/Sublime knows. A programmer’s efficiency depends to a great extent on his snippet library. If your Python classes, HTML tags, and Erlang/Elixir OTP code are still being typed character by character, you really ought to take a good look at this plugin. Paired with honza/vim-snippets, snippets exist for most code. When you hit a boilerplate block with no predefined snippet, call :UltiSnipsEdit and define it on the spot—and you’re basically on the road to invincibility.
• scrooloose/nerdtree: Gives Vim a file tree. Combined with tpope/vim-eunuch, all your filesystem operations and display are handled inside Vim.
• sheerun/vim-polyglot: Syntax/tab support for source files in virtually every programming language. With this one plugin, you no longer need a whole suite of individual language plugins like vim-ruby, vim-go, and so on.
• Valloric/YouCompleteMe: Gives Vim autocompletion. This is basically standard equipment for an IDE, and another great boon to efficiency. With it, the need for an IDE shrinks considerably.

I won’t go through the other plugins one by one—those interested can browse them in my dotfiles.

For most programming work, a lightweight editor is fully up to the task. But some languages and frameworks carry so much boilerplate, and their project directories are so sprawling, that you have no choice but to use an IDE—many Java projects, for instance. When you must use an IDE, the IntelliJ family is a far better choice than the Eclipse family.

Of course, the core of this rule is: use an editor as much as possible, and avoid an IDE whenever you can.

Rule 6: Turn Common Tasks into Commands / Hotkeys

Top developers abroad are also masters of hotkeys. I used to hate using hotkeys, but after watching many masters’ screencasts, I noticed that whenever a task repeats a few times, they casually define a hotkey or command for it. Here I’ll explain how to do it in Vim—Emacs users can fill in the blanks themselves.

When doing TDD in Elixir, I often need to run mix test to make sure my newly written or refactored code passes the existing test cases. Do it enough times and it gets annoying, because in Vim you always have to type !mix test. At that point, I define a hotkey for it. If the hotkey is specific to the current project, I generate a .vimrc in the project root and define it there; otherwise I define it in the system .vimrc:

noremap <leader>et :!mix test<CR>

Then, whenever I need to run that command, I just type the <leader> key + ed. For Elixir, I have these definitions:

noremap <leader>ed :!mix deps.get<CR>
noremap <leader>et :!mix test<CR>
noremap <leader>ec :!mix compile<CR>

Because every language has similar dependency, test, and compile tasks, if you define them globally in your .vimrc, you can give each language a different prefix (Elixir gets e) to distinguish them. If you prefer per-project definitions, you can uniformly define <leader>t as the UT command, saving yourself a keystroke.

Rule 7: Cultivate Good Refactoring Habits

The “refactoring” here is much the same idea as refactoring in code: continuously optimizing your working environment. Rule 6 is itself a form of refactoring.

Keep asking yourself these questions:

• Have I aliased my common commands? For example: if you always type ls -l, shouldn’t you alias an ll?
• Have I written my common server info into .ssh/config? Do I log into servers with a pub/private key (no password needed)?
• For certain operations, could I define some hotkeys (say, a Google search)?
• Have I turned the repetitive work in my project into a makefile (or other task script, like rake or jake)?
• Have I defined snippets for code structures I write often?
• …

Let’s talk about snippets. I especially love Vim’s ultisnips, which lets me define snippets very conveniently per language. For example, the GenServer code I always have to write in Elixir—its rough structure is Public API + GenServer API. I can define a snippet so that typing defgen expands into the following code (and I can jump to the places I need to modify within the code):

defmodule name do
  @moduledoc """

  """
  use GenServer

  ### Public API

  def start_link do
    {:ok, server} = :gen_server.start_link __MODULE__, [], []
  end

  ### GenServer API
  def init(state) do
    {:ok, state}
  end

  def handle_call(, _from, state) do

  end

  def handle_cast(, state) do

  end
end

How much boilerplate time this saves me—and, more importantly, my train of thought never gets interrupted by writing this dull but unavoidable boilerplate.

Rule 8: Use Git to Manage Personal Files

Most developers have good habits for their code projects: managing them with git (or another SCM). But documentation outside of code is managed rather casually—no history, and prone to loss when stored only locally. I recommend putting all files under $HOME that are documents you yourself generate (excluding overly large binaries) under git management (run git init in the directory). Every article of this public account you’re reading is stored on GitHub (in a private repo). Of course, private repos on GitHub cost money—so what if you don’t want to spend and still have lots of private documents to manage? You can create a bare git project on Dropbox (or a similar cloud drive) and push your local documents up to it.

Rule 9: Watch More Screencasts from the Masters

Often we don’t get the chance to watch up close how the masters work, but watching their screencasts is a fine way to improve yourself. In this regard, enthusiasts of other languages must surely envy Ruby’s adherents—the Ruby community’s screencasts are absurdly plentiful! By subscribing to these screencasts, you can not only quickly pick up language knowledge and practical tricks, but—more importantly—learn what tools the masters use and how they write code. Back in 2011 I watched a PHP screencast in which a Frenchman demonstrated building a project with Symfony. That was my first taste of what “fingers flying” really means, and it planted the seed of snippets in me (he used TextMate). Ever since, I’ve watched all kinds of screencasts from time to time (mostly Rails), picking up new things while also learning the masters’ habits.

Rule 10: Subscribe to “The Programmer’s Life”

No explanation needed—you know what I mean. :)