The Pragmatic Programmer

About the Book and the Authors

Dave Thomas

• Was at the age of 43 when writing the first edition of "The Pragmatic Programmer" (born 1956, release 1999)
• Image
• Thomas coined the phrases 'Code Kata' (codekarta.com or Coding Dojo) and 'DRY' (Don't Repeat Yourself)
• He was an original signatory and author of The Manifesto for Agile Software Development
• Webpage: pragdave.me

Andy Hunt

• Published more than 12 books (many together with Dave)
• Image
• On of the 17 original authors of the Agile Manifesto
• Webpage: toolshed.com

The Pragmatic Programmer

• #1 in Software Design & Engineering
  
• #3 in Software Testing
  
• #4 in Software Development (Books)
  

• Was written 1999, and a second edition release 2019 as 20th anniversary, with major revisions and new material which reflects new technology and other changes in the software engineering industry over the last twenty years
• The book does not present a systematic theory, but rather a collection of tips to improve the development process in a pragmatic way
• The main qualities of what the authors refer to as a pragmatic programmer are being
  • an early adopter,
  • to have fast adaptation,
  • inquisitiveness and critical thinking,
  • realism, and
  • being a jack-of-all-trades (What is a jack-of-all-trades?)
• Popular Highlights in this book
  • Don’t leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired.
  • Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
  • "Kaizen" is a Japanese term that captures the concept of continuously making many small improvements.

Foreword (page -11)

• Written by founder and CEO of CodeNewbie

Preface to the Second Edition (page -8)

• You can read the book with random access, but also from the beginning to the end
• A summary of all tips is located on a pull-out card inside the back cover
• There are exercises (straightforward answers - located in the appendix) and challenges (open-ended - basis for group discussions)
• Feedback and corrections appreciated (ppbook@pragprog.com)

From the Preface to the First Edition (page -4)

• The word pragmatic comes from the Latin word pragmaticus (means "skilled in business"). This comes from the Greek word πραγματικός (means "fit for use").
• Care About Your Craft! (tip 1) - it makes no sense to develop SW without caring about doing it well.
• Think! About Your Work (tip 2) - never run on auto-pilot
• Like when building cathedrals hundreds years ago, building software leaves space for individual craftsmanship
• It's a continuous process - like "Kaizen" in Japan, we should improve/maintain our code (and our skills) every day.

CHAPTER 1 - A Pragmatic Philosophy

It's Your Life (page 2)

• It is your live. You own it. You run it. You create it.
• Many developers are frustrated (stagnating, technology has passed them by, under appreciated, underpaid, team is toxic) → Why can't you change it?
• The most important tip in the book: You Have Agency (tip 3; agency = "a thing or person that acts to produce a particular result"; Du bist handlungsfähig.)
• Try to fix it - but don't wait for ever. "you can change your organization or change your organization" (by Martin Fowler)
• If technology seems to be passing you:
  • study interesting things in your own time
  • you're investing in yourself

The Cat Ate My Source Code (page 3)

• Take responsibility for
  • your career advancement
  • your learning and education
  • your project
  • your day-to-day work
• Are not afraid to admit ignorance or error (happens even in the best projects)
• Team trust - we need a healthy environment based in trust, so we
  • can safely speak our mind
  • can present our ideas
  • can rely on our team members
  • the team members can rely on us
• Take Responsibility
  • Responsibility is something you actively agree on - but not on impossible situations, or risks are too great, or on ethical implications.
  • You will held accountable - if an mistake/error happens, admit it honestly and try to offer options
  • It is your role to provide solutions, not excuses (tip 4)
  • Before arguing: Ask yourself "Have I tried/considered everything I can to provide a solution?"
• Challenges - 4-3-2-1-silent-all?
  1. How do you react when someone - such as a bank teller, and auto mechanic, or a clerk - comes to you with a lame excuse? What do you think of them and their company as a result?
  2. When you find yourself saying, "I don't know." be sure to follow up with "- but I'll find out." It's a gread way to admin that you don't know, but then take responsibility like a pro.

Software Entropy (page 6)

• "While software development is immune from almost all physical laws, the inexorable increase in entropy hits us hard. Entropy is a term from physics that refers to the a mount of 'disorder' in a system."
• Software entropy is also called "software rot" or "technical debts" - where the later is more optimistic (you mostly do not pay back your debts)
• The broken window effect (some houses in the city are beautiful and clean, others are rotting hulks)
• "hopelessness" can infect others like a virus → don't live with broken windows (tip 5; better comment out the code, display a 'not implemented' message, substitute with dummy data instead) → really?
• First, Do No Harm
  • Story with the firefighters, which rolled out a mat to save the carpet - because the flat was so beautiful
  • That's the way it must be with software: Independent of the fire (project pressure, deadlines, trade show demo, etc) to not break a window!
  • Design/implement your software so beautiful, that no one have the courage to break a window
• Challenges:
  • Help strengthen your team by surveying your project neighborhood. Choose two or three broken windows and discuss with your colleagues what the problems are and what could be done to fix them.
  • Can you tell when a window first gets broken? What is your reaction? If it was the result of someone else's decision, or a management edict, what can you do about it?

Stone Soup and Boiled Frogs (page 8)

• Story of the three soldiers, cooking stones and creating a square meal.
• The soldiers act as catalyst, enabling the villagers to do something they cannot do alone.
• Be a Catalyst for Change (tip 6)
• Creating SW you have two options:
  • Outline what you want to do and ask your colleagues for support → everyone will guard their own resources (people will form committees, budgets need approval, things getting complicated)
  • Bring out stones: work out what you can reasonable ask for. Develop it well. Show it to the people and let them marvel. Then say "of course, it would be better if we added..." - pretend it is not important. Sit back and wait until they start asking for the functionality you originally wanted.
• The Villagers' Side - the stone soup could also harm
  • The "frog and boiled water" experiment → when things change slowly, people don't notice the change → Remember the big picture (tip 7) - constantly review what's happening around you
  • Difference to "broken window" effect (they loose the will, and here they do not notice the change)
• Challenges:
  • While reviewing a draft of the first edition, John Lakos raised the following issue: The soldiers progressively deceived the villagers, but the change they catalyze does them all good. However, by progressively deceiving the frog, you are doing it harm. Can you determine whether you are making stone soup or frog soup when you try to catalyze change? Is the decision subjective or objective?
  • Quick, without looking, how many lights are in the ceiling above you? How many exits in the room? How many people? Is there anything out of context, anything that looks like it doesn't belong? This is an exercise in situational awareness, a technique practiced by folks ranging from Boy and Girl Scouts to Navy SEALs. Get the habit of really looking and noticing your surroundings. Then do the same in your project.

Good Enough Software (page 11)

• ...

Your Knowledge Portfolio (page 13)

• ...

Communicate! (page 19)

• ...