Honesty

 

Book_PragProg

Page history last edited by Anonymous 3 yrs ago


Book Details

The Pragmatic Programmer: From Journeyman to Master

  • Andrew Hunt, David Thomas
  • Addison-Wesley
  • October 13, 1999

Top

 

Foreword (by Ward Cunningham)

  • So imagine that these guys are thinking this way for a few years. Pretty soon they would have a collection of solutions.

    Now imagine them using their solutions in their work for a few more years, and discarding the ones that are too hard or don't always produce results.

    Well, that approach just about defines pragmatic.

    Now imagine them taking a year or two more to write their solutions down. You might think, That information would be a gold mine. And you would be right.

  • This book is more than a collection of tips. It is a pattern language in sheep's clothing.

    I say that because each tip is drawn from experience, told as concrete advice, and related to others to form a system.

    These are the characteristics that allow us to learn and follow a pattern language. They work the same way here.

  • They make it simple, they tell a story, they use a light touch, and then they follow that up with answers to questions that will come up when you try.

    It embodies its philosophy, and it does so unpretentiously.

Top


Preface

  • This book isn't theoretical—we concentrate on practical topics, on using your experience to make more informed decisions.

    This is a book about doing.

  • 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.

  • 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.

  • 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.

 

What Makes a Pragmatic Programmer?

  • Early adopter/fast adapter

    You have an instinct for technologies and techniques, love trying things out,

    and can grasp something new quickly and integrate it with the rest of your knowledge

  • Inquisitive

    You tend to ask questions. 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. You always smell a challenge.

  • Realistic

    You try to understand the underlying nature of each problem you face.

  • 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.

  • Care About Your Craft (Tip 1)

    There is no point in developing software unless you care about doing it well.

  • Think! About Your Work (Tip 2)

    It's an ongoing critical appraisal of every decision you make, every day, and on every development. Never run on auto-pilot.

    Constantly be thinking, critiquing your work in real time.

Individual Pragmatists, Large Teams

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.

It's a Continuous Process

"Kaizen" is a Japanese term that captures the concept of continuously making many small improvements.

 

Top


Chap 1 A Pragmatic Philosophy

  • Think beyond the immediate problem, always trying to place it in its larger context, always trying to be aware of the bigger picture.

    After all, without this larger context, how can you be pragmatic? How can you make intelligent compromises and informed decisions?

The Cat Ate My Source Code

The greatest of all weaknesses is the fear of appearing weak. --- J. B. Bossuet, Politics from Holy Writ, 1709
  • Take responsibility for yourself and your actions in terms of your career advancement, your project, and your day-to-day work.
  • When you make a mistake (as we all do) or an error in judgment, admit it honestly and try to offer options.
  • Don't blame someone or something else, or make up an excuse.
  • It's your fault. Telling your boss "the cat ate my source code" just won't cut it.
  • Tip 3: Provide Options, Don't Make Lame Excuses

    Before you approach anyone to tell them why something can't be done, is late, or is broken, stop and listen to yourself.

    Instead of excuses, provide options. Don't say it can't be done; explain what can be done to salvage the situation.

 

Software Entropy

Broken Windows Theory

One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don't care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner's desire to fix it, and the sense of abandonment becomes reality.

In the original experiment leading to the "Broken Window Theory," an abandoned car sat for a week untouched.But once a single window was broken, the car was stripped and turned upside down within hours.

  • Entropy: the amount of "disorder" in a system. The laws of thermodynamics guarantee that the entropy in the universe tends toward a maximum.
  • Tip 4: Don't Live with Broken Windows

    crack down on the small stuff in order to keep out the big stuff

    Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered.

    neglect accelerates the rot faster than any other factor

Putting Out Fires

Andy's house was immaculate, beautiful, loaded with priceless antiques, objets d'art, and so on. One day, a tapestry that was hanging a little too close to his living room fireplace caught on fire. The fire department rushed in to save the day—and his house. But before they dragged their big, dirty hoses into the house, they stopped—with the fire raging—to roll out a mat between the front door and the source of the fire.

  • By contrast (another extreme)(not good either): "Putting Out Fires" story

    if you find yourself on a team and a project where the code is pristinely beautiful—cleanly written, well designed, and elegant—

       you will likely take extra special care not to mess it up, just like the firefighters.

    Even if there's a fire raging (deadline, release date, trade show demo, etc.), you don't want to be the first one to make a mess.

 

Stone Soup and Boiled Frogs

Stone Soup

The three soldiers returning home from war were hungry. But when they got the village, after many years of war, the villagers were short of food, and hoarded what they had.

Undeterred, the soldiers boiled a pot of water and carefully placed three stones into it. The amazed villagers came out to watch.

"This is stone soup," the soldiers explained. "Is that all you put in it?" asked the villagers. "Absolutely—although some say it tastes even better with a few carrots…."

A villager ran off, returning in no time with a basket of carrots from his hoard.

A couple of minutes later, the villagers again asked "Is that it?" "Well," said the soldiers, "a couple of potatoes give it body." Off ran another villager.

Over the next hour, the soldiers listed more ingredients that would enhance the soup. Each time a different villager would run off to raid their personal stores.

Eventually they had produced a large pot of steaming soup.

  • The soldiers use the villagers' curiosity to get food from them
  • more importantly, the soldiers act as a catalyst,

    bringing the village together so they can jointly produce something that they couldn't have done by themselves—a synergistic result.

  • Tip 5: Be a Catalyst for Change

    You may be in a situation where you know exactly what needs doing and how to do it.

    But everyone will guard their own resources.

    It's time to bring out the stones. Work out what you can reasonably ask for. Develop it well.

    Once you've got it, show people, and let them marvel.

    Sit back and wait for them to start asking you to add the functionality you originally wanted.

    People find it easier to join an ongoing success. Show them a glimpse of the future and you'll get them to rally around.

Boiled Frogs

If you take a frog and drop it into boiling water, it will jump straight back out again.

However, if you place the frog in a pan of cold water, then gradually heat it, the frog won't notice the slow increase in temperature and will stay put until cooked.

  • The stone soup story is also about gentle and gradual deception.

    The villagers think about the stones and forget about the rest of the world.

  • Tip 6: Remember the Big Picture

    Don't be like the frog.

    Keep an eye on the big picture. Constantly review what's happening around you, not just what you personally are doing.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Top


Tips

Tip 1: Care About Your Craft

There is no point in developing software unless you care about doing it well.

Tip 2: Think! About Your Work

It's an ongoing critical appraisal of every decision you make, every day, and on every development. Never run on auto-pilot.

Constantly be thinking, critiquing your work in real time.

Tip 3: Provide Options, Don't Make Lame Excuses

Before you approach anyone to tell them why something can't be done, is late, or is broken, stop and listen to yourself.

Instead of excuses, provide options. Don't say it can't be done; explain what can be done to salvage the situation.

Tip 4: Don't Live with Broken Windows

Crack down on the small stuff in order to keep out the big stuff

Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered.

neglect accelerates the rot faster than any other factor

Tip 5: Be a Catalyst for Change

You may be in a situation where you know exactly what needs doing and how to do it.

But everyone will guard their own resources.

It's time to bring out the stones. Work out what you can reasonably ask for. Develop it well.

Once you've got it, show people, and let them marvel.

Sit back and wait for them to start asking you to add the functionality you originally wanted.

People find it easier to join an ongoing success. Show them a glimpse of the future and you'll get them to rally around.

Tip 6: Remember the Big Picture

Keep an eye on the big picture. Constantly review what's happening around you, not just what you personally are doing.

 

 

Top

Comments (0)

You don't have permission to comment on this page.