This book will help you become a better programmer.
It doesn't matter whether you are a lone developer, a member of
a large project team, or a consultant working with many clients at
once. This book will help you, as an individual, to do better work.
This book isn't theoreticalwe concentrate on practical topics, on
using your experience to make more informed decisions. The word
pragmatic comes from the Latin
pragmaticus"skilled in business"which itself is derived
from a Greek word meaning "to do." This is a book about doing.
Programming is a craft. At its simplest, it comes down to
getting a computer to do what you want it to do (or what your user
wants it to do). As a programmer, you are part listener, part
advisor, part interpreter, and part dictator. You try to capture
elusive requirements and find a way of expressing them so that a
mere machine can do them justice. You try to document your work so
that others can understand it, and you try to engineer your work so
that others can build on it. What's more, you try to do all this
against the relentless ticking of the project clock. You work small
miracles every day.
It's a difficult job.
There are many people offering you help. Tool vendors tout the
miracles their products perform. Methodology gurus promise that
their techniques guarantee results. Everyone claims that their
programming language is the best, and every operating system is the
answer to all conceivable ills.
Of course, none of this is true. There are no easy answers.
There is no such thing as a best solution, be it a tool, a
language, or an operating system. There can only be systems that
are more appropriate in a particular set of circumstances.
This is where pragmatism comes in. You shouldn't be wedded to
any particular technology, but have a broad enough background and
experience base to allow you to choose good solutions in particular
situations. Your background stems from an understanding of the
basic principles of computer science, and your experience comes
from a wide range of practical projects. Theory and practice
combine to make you strong.
You adjust your approach to suit the current circumstances and
environment. You judge the relative importance of all the factors
affecting a project and use your experience to produce appropriate
solutions. And you do this continuously as the work progresses.
Pragmatic Programmers get the job done, and do it well.
Who Should Read This Book?
This book is aimed at people who want to become more effective
and more productive programmers. Perhaps you feel frustrated that
you don't seem to be achieving your potential. Perhaps you look at
colleagues who seem to be using tools to make themselves more
productive than you. Maybe your current job uses older
technologies, and you want to know how newer ideas can be applied
to what you do.
We don't pretend to have all (or even most) of the answers, nor
are all of our ideas applicable in all situations. All we can say
is that if you follow our approach, you'll gain experience rapidly,
your productivity will increase, and you'll have a better
understanding of the entire development process. And you'll write
better software.
What Makes a Pragmatic Programmer?
Each developer is unique, with individual strengths and
weaknesses, preferences and dislikes. Over time, each will craft
his or her own personal environment. That environment will reflect
the programmer's individuality just as forcefully as his or her
hobbies, clothing, or haircut. However, if you're a Pragmatic
Programmer, you'll share many of the following characteristics:
- Early adopter/fast adapter. You have an
instinct for technologies and techniques, and you love trying
things out. When given something new, you can grasp it quickly and
integrate it with the rest of your knowledge. Your confidence is
born of experience.
- Inquisitive. You tend to ask questions.
That's neathow did you do that? Did you have problems with that
library? What's this BeOS I've heard about? How are symbolic links
implemented? You are a pack rat for little facts, each of
which may affect some decision years from now.
- Critical thinker. You rarely take things as
given without first getting the facts. When colleagues say "because
that's the way it's done," or a vendor promises the solution to all
your problems, you smell a challenge.
- Realistic. You try to understand the
underlying nature of each problem you face. This realism gives you
a good feel for how difficult things are, and how long things will
take. Understanding for yourself that a process should be
difficult or will take a while to complete gives you the
stamina to keep at it.
- Jack of all trades. You try hard to be
familiar with a broad range of technologies and environments, and
you work to keep abreast of new developments. Although your current
job may require you to be a specialist, you will always be able to
move on to new areas and new challenges.
We've left the most basic characteristics until last. All
Pragmatic Programmers share them. They're basic enough to state as
tips:
Care About Your Craft
We feel that there is no point in developing software unless you
care about doing it well.
Think! About Your Work
In order to be a Pragmatic Programmer, we're challenging you to
think about what you're doing while you're doing it. This isn't a
onetime audit of current practicesit's an ongoing critical
appraisal of every decision you make, every day, and on every
development. Never run on autopilot. Constantly be thinking,
critiquing your work in real time. The old IBM corporate motto,
THINK!, is the Pragmatic Programmer's mantra.
If this sounds like hard work to you, then you're exhibiting the
realistic characteristic. This is going to take up some of
your valuable timetime that is probably already under tremendous
pressure. The reward is a more active involvement with a job you
love, a feeling of mastery over an increasing range of subjects,
and pleasure in a feeling of continuous improvement. Over the long
term, your time investment will be repaid as you and your team
become more efficient, write code that's easier to maintain, and
spend less time in meetings.
Individual Pragmatists, Large Teams
Some people feel that there is no room for individuality on
large teams or complex projects. "Software construction is an
engineering discipline," they say, "that breaks down if individual
team members make decisions for themselves."
We disagree.
The construction of software should be an engineering
discipline. However, this doesn't preclude individual
craftsmanship. Think about the large cathedrals built in Europe
during the Middle Ages. Each took thousands of personyears of
effort, spread over many decades. Lessons learned were passed down
to the next set of builders, who advanced the state of structural
engineering with their accomplishments. But the carpenters,
stonecutters, carvers, and glass workers were all craftspeople,
interpreting the engineering requirements to produce a whole that
transcended the purely mechanical side of the construction. It was
their belief in their individual contributions that sustained the
projects:
We who cut mere stones must always be envisioning
cathedrals.
Quarry worker's creed
Within the overall structure of a project there is always room
for individuality and craftsmanship. This is particularly true
given the current state of software engineering. One hundred years
from now, our engineering may seem as archaic as the techniques
used by medieval cathedral builders seem to today's civil
engineers, while our craftsmanship will still be honored.
It's a Continuous Process
A tourist visiting England's Eton College asked the
gardener how he got the lawns so perfect. "That's easy," he
replied, "You just brush off the dew every morning, mow them every
other day, and roll them once a week."
"Is that all?" asked the tourist.
"Absolutely," replied the gardener. "Do that for 500 years
and you'll have a nice lawn, too."
Great lawns need small amounts of daily care, and so do great
programmers. Management consultants like to drop the word
kaizen in conversations. "Kaizen" is a Japanese term that
captures the concept of continuously making many small
improvements. It was considered to be one of the main reasons for
the dramatic gains in productivity and quality in Japanese
manufacturing and was widely copied throughout the world. Kaizen
applies to individuals, too. Every day, work to refine the skills
you have and to add new tools to your repertoire. Unlike the Eton
lawns, you'll start seeing results in a matter of days. Over the
years, you'll be amazed at how your experience has blossomed and
your skills have grown.
How the Book Is Organized
This book is written as a collection of short sections. Each
section is selfcontained, and addresses a particular topic. You'll
find numerous cross references, which help put each topic in
context. Feel free to read the sections in any orderthis isn't a
book you need to read fronttoback.
Occasionally you'll come across a box labeled Tip nn (such as
Tip 1, "Care About Your Craft" on xix). As well as emphasizing
points in the text, we feel the tips have a life of their ownwe
live by them daily. You'll find a summary of all the tips on a
pullout card inside the back cover.
Appendix A contains a set of resources: the book's bibliography,
a list of URLs to Web resources, and a list of recommended
periodicals, books, and professional organizations. Throughout the
book you'll find references to the bibliography and to the list of
URLs.
We've included exercises and challenges where appropriate.
Exercises normally have relatively straightforward answers, while
the challenges are more openended. To give you an idea of our
thinking, we've included our answers to the exercises in Appendix
B, but very few have a single correct solution. The
challenges might form the basis of group discussions or essay work
in advanced programming courses.
020161622XP04062001