The Pragmatic Programmer

Topic 1: It's Your Life

  • “Kaizen” is a Japanese term that captures the concept of continuously making many small improvements.
  • Pragmatic Programmers take responsibility for everything they do.
  • I’m not in this world to live up to your expectations and you’re not in this world to live up to mine.

Topic 2: The Cat Ate My Source Code

  • Above all, your team needs to be able to trust and rely on you.
  • When you do accept the responsibility for an outcome, you should expect to be held accountable for it. When you make a mistake (as we all do) or an error in judgment, admit it honestly and try to offer options.
  • What to do if something goes wrong: Don’t blame someone or something else, or make up an excuse. Don’t blame all the problems on a vendor, a programming language, management, or your coworkers. Any and all of these may play a role, but it is up to you to provide solutions, not excuses. Provide Options, Don’t Make Lame Excuses
  • What to remember before sharing the problem: Run through the conversation in your mind. What is the other person likely to say? Will they ask, “Have you tried this…” or “Didn’t you consider that?” How will you respond? Before you go and tell them the bad news, is there anything else you can try? Sometimes, you just know what they are going to say, so save them the trouble.
  • Mental Checklist when something goes wrong:
    • Does code have to be deleted? Tell them so, and explain the value of refactoring.
    • Do you need to spend time prototyping to determine the best way to proceed.
    • Do you need to introduce better testing.
    • Automation to prevent it from happening again?
  • Tell the cat your concerns first: Try to flush out the lame excuses before voicing them aloud. If you must, tell your cat first. After all, if little Tiddles is going to take the blame
  • When you find yourself saying, “I don’t know,” be sure to follow it up with “—but I’ll find out.” It’s a great way to admit what you don’t know, but then take responsibility like a pro.

Topic 3: Software Entropy

  • Hopelessness: Psychologists have done studies that show hopelessness can be contagious.
  • Don’t leave broken windows’ (bad designs, wrong decisions, or poor code) unrepaired.
    • If there is insufficient time to fix it properly, then board it up.
    • Take some action to prevent further damage and to show that you’re on top of the situation.
  • Neglect accelerates the rot faster than any other factor.
  • Don’t cause collateral damage just because there’s a crisis of some sort. One broken window is one too many.
  • Walk the project neighbourhood: Help strengthen your team by surveying your project neighbourhood. Choose two or three broken windows and discuss with your colleagues what the problems are and what could be done to fix them.

Topic 4: Stone Soup and Boiled Frogs

  • People find it easier to join an ongoing success. Show them a glimpse of the future and you’ll get them to rally around.
  • Be a Catalyst for Change
  • In the Broken Window Theory, people lose the will to fight entropy because they perceive that no one else cares. The frog just doesn’t notice the change. Don’t be like the fabled frog. Keep an eye on the big picture.

Topic 5: Good Enough Software

  • Great software today is often preferable to the fantasy of perfect software tomorrow.
  • Don't spoil a perfectly good program by over-embellishment and over-refinement. Move on, and let your code stand in its own right for while.

Topic 6: Knowledge Portfolio

  • Learn at least one new language every year
  • Read a technical book each month
  • Critically Analyse What You Read and Hear
    • Ask the “Five Whys”:
      • Who does this benefit?
      • What's the context?
      • What will happen next?
      • Why is this a problem?
      • Is there an underlying model? How does the underlying model work?