The Productive Programmer

Chapter 1. Introduction

Productivity is defined as the amount of useful work performed over time. Someone who is more productive performs more effective work in a given time interval than someone less productive. This book is all about how to become more productive as you go about the tasks required to develop software. It is language and operating system agnostic: I provide tips in a variety of languages, and across three major operating systems: Windows (in various flavors), Mac OS X, and *-nix (Unix and Linux alternatives).

This book is about individual programmer productivity, not group productivity. To that end, I don’t talk about methodology (well, maybe a little here and there, but always on the periphery). I also don’t discuss productivity gains that affect the whole team. My mission is to allow individual programmers the tools and philosophies to get more useful work done per unit of time.

Why a Book on Programmer Productivity?

I work for ThoughtWorks, an international consulting company of about 1,000 employees spread across 6 countries. Because we are traveling consultants (especially in the U.S.), we are a demographically very young company. It came to pass at one of our company outings (where beverages were served) that I starting chatting with one of the People people. She asked me how old I was and I told her. Then, she gave me an off-handed compliment(?): “Wow, you’re old enough to add diversity to the company!” That sparked some thoughts. I’ve been developing software for many years (cue the maudlin “Back in my day, we had kerosene-powered computers…”). During that time, I’ve observed an interesting phenomenon: developers are getting less efficient, not more. Back in ancient times (a couple of decades in computer time), running a computer was a difficult job, much less programming the thing. You had to be a really clever developer to get anything useful from the beastly machine. This crucible forged Really Smart Guys who developed all sorts of efficient ways to interact with the intractable computers of their age.

Slowly, due to the hard work of programmers, computers became easier to use. This innovation was really to stop users from complaining so much. The Really Smart Guys congratulated themselves (as all programmers do when they can get a user to pipe down). Then a funny thing happened: a whole generation of developers came along who no longer needed clever tricks and devious intelligence to get computers to do what they wanted. The developers, like the end users, basked in the easier-to-use computers. So, what’s wrong with that? After all, productivity is a good thing, right?

It depends. What is productive for a user (nice graphical user interface, mice, pull-down menus, etc.) can actually be a hindrance to someone trying to get the best performance from a computer. “Easy to use” and “efficient” overlap infrequently. Developers who grew up using graphical user interfaces (OK, I’ll just go ahead and say it: Windows) don’t know many of the cool, efficient tricks of the trade of the Really Smart Guys of yesteryear. Developers today are not running their computers, they are walking them. I’m going to try to fix that.

Address Completion in Browsers

Here’s a quick example: how many web sites do you visit in a day? Most of them start with “www.” and end with “.com”. A little-known shortcut exists for all modern browsers: address completion. Address completion uses a hotkey combination to automatically add “www.” to the beginning and “.com” to the end of the string you type in the browser’s address bar. Different browsers support slightly different syntax. (Note that this is different from letting the browser automatically supply the prefix and suffix. All the modern browsers do that too.) The difference is one of efficiency. To autocomplete the prefix and suffix, the browser goes out to the network and looks for a site with the “bare” name. If it doesn’t find one, it tries it with the prefix and suffix, entailing another trip out to the network. With a fast connection, you may not even notice the lag, but you’re slowing down the whole Internet with all those false hits!

Internet Explorer

Internet Explorer (IE) makes it easier to type in addresses that contain standard prefixes and suffixes. Use the keys Ctrl-Enter to add “www.” to the front of an address and “.com” to the end.

Firefox

The same Internet Explorer shortcut works for the Windows version of Firefox as well. For Macintosh, Apple-Enter does the same thing. Firefox goes one better: for all the platforms it supports, Alt-Enter places a “.org” at the end.

Firefox has other handy shortcut keys that no one seems to leverage. To go directly to a tab, you can use Ctrl + <TAB-NUMBER> in Windows or Apple + <TAB-NUMBER> in OS X.

OK, this shortcut is worth a measly eight keystrokes per web page. But think of the number of web pages you visit every day, and those eight characters per page start to add up. This is an example of the principle of acceleration, defined in Chapter 2.

But saving eight keystrokes per web page isn’t the point of this example. I conducted an informal poll of all the developers I know and learned that less than 20 percent of them knew this shortcut. These folks are hardcore computer experts, yet they weren’t taking advantage of even the simplest productivity gains. My mission is to rectify that.

What This Book Is About

The Productive Programmer is divided into two parts. The first discusses the mechanics of productivity, and the tools and their uses that make you more productive as you go through the physical activities of developing software. The second part discusses the practice of productivity, and how you can leverage your knowledge and the knowledge of others to produce better software more quickly. In both sections, you will likely run into some things you already know, as well as things you have never thought of before.

Part I: Mechanics (The Productivity Principles)

You can treat this book as a recipe book for command-line and other productivity tips and still reap benefits. But if you understand why something increases productivity, you can recognize it all around you. Creating patterns to describe something creates nomenclature: once you have a name for something, it’s easier to recognize when you see it again. One of the goals of this book is to define a set of productivity principles to help you define your own productivity techniques. Like all patterns, it becomes easier to identify them once they have names. Knowing why something speeds you up allows you to more quickly identify other things that will help you work faster.

This is not just a book on how to use computers more effectively (although that is a side effect). It is focused on programmer productivity. To this end, I don’t cover many things that are obvious to casual or even power users (although, as the exception that proves the rule, the earlier section Address Completion in Browsers” does show an obvious tip). Programmers represent a unique subsection of computer users. We should be able to bend computers to our will more effectively than anyone else because we understand the most about how they really work. Mostly, this book is about things you can do with and to a computer to make your job easier, faster, and more efficient. However, I also discuss some low-hanging fruit that can make you more productive.

Part I covers every productivity tip I could invent, harvest, bully out of my friends, or read about. Originally, I aimed to create the world’s most awesome collection of productivity recipes. I don’t know if that happened, but you will still find a pretty impressive collection of recipes here.

As I started collating all these cool productivity tips, I noticed patterns emerging. Looking over these techniques, I started formulating categories of productivity for programmers. Eventually, I created the Principles of Programmer Productivity because, frankly, I couldn’t think of a more pretentious name. These principles are acceleration, focus, automation, and canonicality. They describe the practices that allow programmers to become more productive.

Chapter 2, Acceleration, describes becoming more productive by speeding something up. Obviously, if one person is faster at a particular task, that person is more productive at that task than someone who goes more slowly doing the same thing. Great examples of the acceleration principle are the numerous keyboard shortcuts that appear throughout the book. Acceleration encompasses things like launching applications, managing clipboards, and searching and navigation.

Chapter 3, Focus, describes how to achieve the state of super-productivity, using both tools and environmental factors. It discusses ways to reduce the clutter of your environment (both physical and virtual), how to search efficiently, and how to avoid distractions.

Getting the computer to perform extra work for you obviously makes you more productive. Chapter 4, Automation, describes coercing your computer to do more work for you. Many of the tasks you perform every day can (and should) be automated. This chapter has examples and strategies to put your computer to work.

Canonicality is really just a fancy term for the application of the DRY (Don’t Repeat Yourself) principle, first espoused in The Pragmatic Programmer (Addison-Wesley) by Andy Hunt and Dave Thomas. The DRY principle advises programmers to find places where information is duplicated and create a single source for this information. The Pragmatic Programmer eloquently describes this principle, and in Chapter 5, Canonicality, I show concrete examples of applying it.

Part II: Practice (Philosophy)

I’ve worked as a consultant for most of my many seasoned years as a developer. Consultants have advantages over developers who work on the same code base year after year. We get to see lots of different projects and lots of different approaches. Of course, we see our share of train wrecks as well (rarely do consultants get called in to “fix” healthy projects). We get to see the broad spectrum of software development: building things from the start, advising in the middle, and rescuing what’s badly broken. Over time, even the least observant person can get a feel for what works and what doesn’t.

Part II is the distillation of the things I’ve seen that either make developers more productive or detract from their productivity. I’ve bundled them together in a more or less random order (although you may be surprised by how often the same ideas come up in different guises). This isn’t meant to be the ultimate compendium of things that make developers productive; rather, it is the list of things I’ve observed, which is just a small subset of the possibilities.

Where to Go Now?

The two parts of this book stand alone, so you can read them in any order; however, Part II is a tad more narrative, and unexpected connections may pop up. Still, most of the material in it is nonsequential: you can read it in any order you like.

One note of warning. If you aren’t comfortable with basic command-line stuff (pipes, redirection, etc.), you should make a quick visit to Appendix A. It covers getting an environment set up that is suitable for using many of the tricks and techniques discussed in Part I. It’s pretty painless, I promise.