PR
ODUCTIVITY IS DEFINED AS THE AMOUNT OF USEFUL WORK PERFOR MED 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.
2
C HA PT ER 1 : I NT RO DU CT IO N