Foreword
Preface to the Second Edition
How the Book Is Organized
What’s in a Name?
Source Code and Other Resources
Send Us Feedback
Second Edition Acknowledgments
From the Preface to the First Edition
Who Should Read This Book?
What Makes a Pragmatic Programmer?
Individual Pragmatists, Large Teams
It’s a Continuous Process

1. A Pragmatic Philosophy
Topic 1. It’s Your Life
Topic 2. The Cat Ate My Source Code
Topic 3. Software Entropy
Topic 4. Stone Soup and Boiled Frogs
Topic 5. Good-Enough Software
Topic 6. Your Knowledge Portfolio
Topic 7. Communicate!

2. A Pragmatic Approach
Topic 8. The Essence of Good Design
Topic 9. DRY—The Evils of Duplication
Topic 10. Orthogonality
Topic 11. Reversibility
Topic 12. Tracer Bullets
Topic 13. Prototypes and Post-it Notes
Topic 14. Domain Languages
Topic 15. Estimating

3. The Basic Tools
Topic 16. The Power of Plain Text
Topic 17. Shell Games
Topic 18. Power Editing
Topic 19. Version Control
Topic 20. Debugging
Topic 21. Text Manipulation
Topic 22. Engineering Daybooks

4. Pragmatic Paranoia
Topic 23. Design by Contract
Topic 24. Dead Programs Tell No Lies
Topic 25. Assertive Programming
Topic 26. How to Balance Resources
Topic 27. Don’t Outrun Your Headlights

5. Bend, or Break
Topic 28. Decoupling
Topic 29. Juggling the Real World
Topic 30. Transforming Programming
Topic 31. Inheritance Tax
Topic 32. Configuration

6. Concurrency
Topic 33. Breaking Temporal Coupling
Topic 34. Shared State Is Incorrect State
Topic 35. Actors and Processes
Topic 36. Blackboards

7. While You Are Coding
Topic 37. Listen to Your Lizard Brain
Topic 38. Programming by Coincidence
Topic 39. Algorithm Speed
Topic 40. Refactoring
Topic 41. Test to Code
Topic 42. Property-Based Testing
Topic 43. Stay Safe Out There
Topic 44. Naming Things

8. Before the Project
Topic 45. The Requirements Pit
Topic 46. Solving Impossible Puzzles
Topic 47. Working Together
Topic 48. The Essence of Agility

9. Pragmatic Projects
Topic 49. Pragmatic Teams
Topic 50. Coconuts Don’t Cut It
Topic 51. Pragmatic Starter Kit
Topic 52. Delight Your Users
Topic 53. Pride and Prejudice

10. Postface
A1. Bibliography
A2. Possible Answers to the Exercises

Chapter 2, Topic 10, image 1


Chapter 2, Topic 12, image 2


Chapter 5, Topic 28, image 3


Chapter 5, Topic 28, image 4


Chapter 5, Topic 29, image 5


Chapter 5, Topic 29, image 6


Chapter 5, Topic 29, image 7


Chapter 5, Topic 29, image 8


Chapter 5, Topic 29, image 9


Chapter 5, Topic 30, image 10


Chapter 5, Topic 31, image 11


Chapter 5, Topic 31, image 12


Chapter 5, Topic 32, image 13


Chapter 6, Topic 33, image 14


Chapter 6, Topic 34, image 15


Chapter 6, Topic 35, image 16


Chapter 7, Topic 39, image 17


Chapter 7, Topic 44, image 18


Chapter 8, Topic 46, image 19


Chapter 9, Topic 50, image 20


Chapter 9, Topic 52, image 21


Appendix 2, image 22
spoiler: https://i.imgur.com/k4290Fj.png
Appendix 2, image 23
spoiler: https://i.imgur.com/k7QBVs7.png

Tip 1. Care About Your Craft. We feel that there is no point in developing software unless you care about doing it well.
Tip 2. 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 one-time audit of current practices - it's an ongoing critical appraisal of every decision you make, every day, and on every project. Never run on auto-pilot. Constantly be thinking, critiquing your work in real time. The old IBM corporate motto, THINK!, is the Pragmatic Programmer's mantra.
Tip 3 You Have Agency.
Tip 4. 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. Talk to the rubber duck on your monitor, or the cat. Does your excuse sound reasonable, or stupid? How's it going to sound to your boss?
Tip 5. Don't Live with Broken Windows. Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take some action to prevent further damage and to show that you're on top of the situation.
Tip 6. Be a Catalyst for Change.
Tip 7. Remember the Big Picture. We've never tried this-honest. But "they" say that 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.
Tip 8. Make Quality a Requirements Issue. Often you'll be in situations where trade-offs are involved. Surprisingly, many users would rather use software with some rough edges today than wait a year for the shiny, bells-and-whistles version (and in fact what they will need a year from now may be completely different anyway). Many IT departments with tight budgets would agree. Great software today is often preferable to the fantasy of perfect software tomorrow. If you give your users something to play with early, their feedback will often lead you to a better eventual solution (see Topic 12, "Tracer Bullets").
Tip 9. Invest Regularly in Your Knowledge Portfolio.
Tip 10. Critically Analyze What You Read and Hear. Critical thinking is an entire discipline unto itself, and we encourage you to read and study all you can about it. In the meantime, here's a head start with a few questions to ask and think about.
Tip 11. English is Just Another Programming Language.
Tip 12. It's Both What You Say and the Way You Say It. Unless you work in a vacuum, you need to be able to communicate. The more effective that communication, the more influential you become.
Tip 13. Build Documentation In, Don't Bolt It On. It's easy to produce good-looking documentation from the comments in source code, and we recommend adding comments to modules and exported functions to give other developers a leg up when they come to use it.
Tip 14. Good Design Is Easier to Change Than Bad Design. A thing is well designed if it adapts to the people who use it. For code, that means it must adapt by changing. So we believe in the ETC principle: Easier to Change. ETC. That's it.
Tip 15. DRY-Don't Repeat Yourself. The alternative is to have the same thing expressed in two or more places. If you change one, you have to remember to change the others, or, like the alien computers, your program will be brought to its knees by a contradiction. It isn't a question of whether you'll remember: it's a question of when you'll forget.
Tip 16. Make It Easy to Reuse. What you're trying to do is foster an environment where it's easier to find and reuse existing stuff than to write it yourself. If it isn't easy, people won't do it. And if you fail to reuse, you risk duplicating knowledge.
Tip 17. Eliminate Effects Between Unrelated Things. We want to design components that are self-contained: independent, and with a single, well-defined purpose (what Yourdon and Constantine call cohesion in Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design [YC79]). When components are isolated from one another, you know that you can change one without having to worry about the rest. As long as you don't change that component's external interfaces, you can be confident that you won't cause problems that ripple through the entire system.
Tip 18. There Are No Final Decisions.
Tip 19. Forgo Following Fads. No one knows what the future may hold, especially not us! So enable your code to rock-n-roll: to "rock on" when it can, to roll with the punches when it must.
Tip 20. Use Tracer Bullets to Find the Target. In fact, given the complexity of today's project setup, with swarms of external dependencies and tools, tracer bullets become even more important. For us, the very first tracer bullet is simply create the project, add a "hello world!," and make sure it compiles and runs. Then we look for areas of uncertainty in the overall application and add the skeleton needed to make it work.
Tip 21. Prototype to Learn.
Tip 22. Program Close to the Problem Domain.
Tip 23. Estimate to Avoid Surprises.
Tip 24. Iterate the Schedule with the Code. This may not be popular with management, who typically want a single, hard-and-fast number before the project even starts. You'll have to help them understand that the team, their productivity, and the environment will determine the schedule. By formalizing this, and refining the schedule as part of each iteration, you'll be giving them the most accurate scheduling estimates you can.
Tip 25. Keep Knowledge in Plain Text.
Tip 26. Use the Power of Command Shells. Gain familiarity with the shell, and you'll find your productivity soaring. Need to create a list of all the unique package names explicitly imported by your Java code? The following stores it in a file called "list":
Tip 27. Achieve Editor Fluency. Why is this a big deal? Are we saying you'll save lots of time? Actually yes: over the course of a year, you might actually gain an additional week if you make your editing just 4% more efficient and you edit for 20 hours a week.
Tip 28. Always Use Version Control. Always. Even if you are a single-person team on a one-week project. Even if it's a "throw-away" prototype. Even if the stuff you're working on isn't source code. Make sure that everything is under version control: documentation, phone number lists, memos to vendors, makefiles, build and release procedures, that little shell script that tidies up log files-everything. We routinely use version control on just about everything we type (including the text of this book). Even if we're not working on a project, our day-to-day work is secured in a repository.
Tip 29. Fix the Problem, Not the Blame. It doesn't really matter whether the bug is your fault or someone else's. It is still your problem.
Tip 30. Don't Panic. It's easy to get into a panic, especially if you are facing a deadline, or have a nervous boss or client breathing down your neck while you are trying to find the cause of the bug. But it is very important to step back a pace, and actually think about what could be causing the symptoms that you believe indicate a bug.
Tip 31. Failing Test Before Fixing Code. Sometimes by forcing yourself to isolate the circumstances that display the bug, you'll even gain an insight on how to fix it. The act of writing the test informs the solution.
Tip 32. Read the Damn Error Message. 'nuf said.
Tip 33. "select" Isn't Broken. Remember, if you see hoof prints, think horses-not zebras. The OS is probably not broken. And select is probably just fine.
Tip 34. Don't Assume It-Prove It. When you come across a surprise bug, beyond merely fixing it, you need to determine why this failure wasn't caught earlier. Consider whether you need to amend the unit or other tests so that they would have caught it.
Tip 35. Learn a Text Manipulation Language. To show the wide-ranging applicability of text manipulation languages, here's a sample of some stuff we've done with Ruby and Python just related to the creation of this book:
Tip 36. You Can't Write Perfect Software. Did that hurt? It shouldn't. Accept it as an axiom of life. Embrace it. Celebrate it. Because perfect software doesn't exist. No one in the brief history of computing has ever written a piece of perfect software. It's unlikely that you'll be the first. And unless you accept this as a fact, you'll end up wasting time and energy chasing an impossible dream.
Tip 37. Design with Contracts. In Topic 10, "Orthogonality", we recommended writing "shy" code. Here, the emphasis is on "lazy" code: be strict in what you will accept before you begin, and promise as little as possible in return. Remember, if your contract indicates that you'll accept anything and promise the world in return, then you've got a lot of code to write!
Tip 38. Crash Early.
Tip 39. Use Assertions to Prevent the Impossible. Whenever you find yourself thinking "but of course that could never happen," add code to check it. The easiest way to do this is with assertions. In many language implementations, you'll find some form of assert that checks a Boolean condition.[31] These checks can be invaluable. If a parameter or a result should never be null, then check for it explicitly:
Tip 40. Finish What You Start. This tip is easy to apply in most circumstances. It simply means that the function or object that allocates a resource should be responsible for deallocating it. Let's see how it applies by looking at an example of some bad code-part of a Ruby program that opens a file, reads customer information from it, updates a field, and writes the result back. We've eliminated error handling to make the example clearer:
Tip 41. Act Locally.
Tip 42. Take Small Steps-Always. Always take small, deliberate steps, checking for feedback and adjusting before proceeding. Consider that the rate of feedback is your speed limit. You never take on a step or a task that's "too big."
Tip 43. Avoid Fortune-Telling. Much of the time, tomorrow looks a lot like today. But don't count on it.
Tip 44. Decoupled Code Is Easier to Change. Given that we don't normally code using steel beams and rivets, just what does it mean to decouple code? In this section we'll talk about:
Tip 45. Tell, Don't Ask. This principle says that you shouldn't make decisions based on the internal state of an object and then update that object. Doing so totally destroys the benefits of encapsulation and, in doing so, spreads the knowledge of the implementation throughout the code. So the first fix for our train wreck is to delegate the discounting to the total object:
Tip 46. Don't Chain Method Calls. Try not to have more than one "." when you access something. And access something also covers cases where you use intermediate variables, as in the following code:
Tip 47. Avoid Global Data.
Tip 48. If It's Important Enough to Be Global, Wrap It in an API.
Tip 49. Programming Is About Code, But Programs Are About Data.
Tip 50. Don't Hoard State; Pass It Around. In the transformational model, we turn that on its head. Instead of little pools of data spread all over the system, think of data as a mighty river, a flow. Data becomes a peer to functionality: a pipeline is a sequence of code -> data -> code -> data.... The data is no longer tied to a particular group of functions, as it is in a class definition. Instead it is free to represent the unfolding progress of our application as it transforms its inputs into its outputs. This means that we can greatly reduce coupling: a function can be used (and reused) anywhere its parameters match the output of some other function.
Tip 51. Don't Pay Inheritance Tax.
Tip 52. Prefer Interfaces to Express Polymorphism. Interfaces and protocols give us polymorphism without inheritance.
Tip 53. Delegate to Services: Has-A Trumps Is-A. In fact, we can take this a step further. Why should an Account have to know how to persist itself? Isn't its job to know and enforce the account business rules?
Tip 54. Use Mixins to Share Functionality.
Tip 55. Parameterize Your App Using External Configuration.
Tip 56. Analyze Workflow to Improve Concurrency. An activity diagram consists of a set of actions drawn as rounded boxes. The arrow leaving an action leads to either another action (which can start once the first action completes) or to a thick line called a synchronization bar. Once all the actions leading into a synchronization bar are complete, you can then proceed along any arrows leaving the bar. An action with no arrows leading into it can be started at any time.
Tip 57. Shared State Is Incorrect State. The problem is the shared state. Each server in the restaurant looked into the display case without regard for the other. Each point-of-sale device looked at an account balance without regard for the other.
Tip 58. Random Failures Are Often Concurrency Issues.
Tip 59. Use Actors For Concurrency Without Shared State.
Tip 60. Use Blackboards to Coordinate Workflow.
Tip 61. Listen to Your Inner Lizard. First, stop what you're doing. Give yourself a little time and space to let your brain organize itself. Stop thinking about the code, and do something that is fairly mindless for a while, away from a keyboard. Take a walk, have lunch, chat with someone. Maybe sleep on it. Let the ideas percolate up through the layers of your brain on their own: you can't force it. Eventually they may bubble up to the conscious level, and you have one of those a ha! moments.
Tip 62. Don't Program by Coincidence.
Tip 63. Estimate the Order of Your Algorithms. There are some approaches you can take to address potential problems. If you have an algorithm that is O(n^2), try to find a divide-and-conquer approach that will take you down to O(n * lg n).
Tip 64. Test Your Estimates. If it's tricky getting accurate timings, use code profilers to count the number of times the different steps in your algorithm get executed, and plot these figures against the size of the input.
Tip 65. Refactor Early, Refactor Often. Collateral damage in code can be just as deadly over time (see Topic 3, "Software Entropy"). Refactoring, as with most things, is easier to do while the issues are small, as an ongoing activity while coding. You shouldn't need "a week to refactor" a piece of code-that's a full-on rewrite. If that level of disruption is necessary, then you might well not be able to do it immediately. Instead, make sure that it gets placed on the schedule. Make sure that users of the affected code know that it is scheduled to be rewritten and how this might affect them.
Tip 66. Testing Is Not About Finding Bugs. We believe that the major benefits of testing happen when you think about and write the tests, not when you run them.
Tip 67. A Test Is the First User of Your Code. We think this is probably the biggest benefit offered by testing: testing is vital feedback that guides your coding.
Tip 68. Build End-to-End, Not Top-Down or Bottom Up. We strongly believe that the only way to build software is incrementally. Build small pieces of end-to-end functionality, learning about the problem as you go. Apply this learning as you continue to flesh out the code, involve the customer at each step, and have them guide the process.
Tip 69. Design to Test.
Tip 70. Test Your Software, or Your Users Will. Make no mistake, testing is part of programming. It's not something left to other departments or staff.
Tip 71. Use Property-Based Tests to Validate Your Assumptions. As an artificial example, we can build some tests for our sorted list. We've already established one property: the sorted list is the same size as the original. We can also state that no element in the result can be greater than the one that follows it.
Tip 72. Keep It Simple and Minimize Attack Surfaces.
Tip 73. Apply Security Patches Quickly. This tip affects every net-connected device, including phones, cars, appliances, personal laptops, developer machines, build machines, production servers, and cloud images. Everything. And if you think that this doesn't really matter, just remember that the largest data breaches in history (so far) were caused by systems that were behind on their updates.
Tip 74. Name Well; Rename When Needed. If for some reason you can't change the now-wrong name, then you've got a bigger problem: an ETC violation (see Topic 8, "The Essence of Good Design"). Fix that first, then change the offending name. Make renaming easy, and do it often.
Tip 75. No One Knows Exactly What They Want.
Tip 76. Programmers Help People Understand What They Want.
Tip 77. Requirements Are Learned in a Feedback Loop. Your job is to help the client understand the consequences of their stated requirements. You do that by generating feedback, and letting them use that feedback to refine their thinking.
Tip 78. Work with a User to Think Like a User. Gathering feedback is also the time to start to build a rapport with your client base, learning their expectations and hopes for the system you are building. See Topic 52, "Delight Your Users", for more.
Tip 79. Policy Is Metadata. Implement the general case, with the policy information as an example of the type of thing the system needs to support.
Tip 80. Use a Project Glossary. It's hard to succeed on a project if users and developers call the same thing by different names or, even worse, refer to different things by the same name.
Tip 81. Don't Think Outside the Box-Find the Box. When faced with an intractable problem, enumerate all the possible avenues you have before you. Don't dismiss anything, no matter how unusable or stupid it sounds. Now go through the list and explain why a certain path cannot be taken. Are you sure? Can you prove it?
Tip 82. Don't Go into the Code Alone.
Tip 83. Agile Is Not a Noun; Agile Is How You Do Things. As we write this, almost 20 years after the inception of the Manifesto for Agile Software Development,[73] we see many, many developers successfully applying its values. We see many fantastic teams who find ways to take these values and use them to guide what they do, and how they change what they do.
Tip 84. Maintain Small, Stable Teams. In this section we'll look briefly at how pragmatic techniques can be applied to teams as a whole. These notes are only a start. Once you've got a group of pragmatic developers working in an enabling environment, they'll quickly develop and refine their own team dynamics that work for them.
Tip 85. Schedule It to Make It Happen.
Tip 86. Organize Fully Functional Teams. Build teams so you can build code end-to-end, incrementally and iteratively.
Tip 87. Do What Works, Not What's Fashionable. How do you know "what works"? You rely on that most fundamental of Pragmatic techniques:
Tip 88. Deliver When Users Need It. In order to move to this style of continuous development, you need a rock-solid infrastructure, which we discuss in the next topic, Topic 51, "Pragmatic Starter Kit". You do development in the main trunk of your version control system, not in branches, and use techniques such as feature switches to roll out test features to users selectively.
Tip 89. Use Version Control to Drive Builds, Tests, and Releases. That is, build, test, and deployment are triggered via commits or pushes to version control, and built in a container in the cloud. Release to staging or production is specified by using a tag in your version control system. Releases then become a much more low-ceremony part of every day life-true continuous delivery, not tied to any one build machine or developer's machine.
Tip 90. Test Early, Test Often, Test Automatically. We want to start testing as soon as we have code. Those tiny minnows have a nasty habit of becoming giant, man-eating sharks pretty fast, and catching a shark is quite a bit harder. So we write unit tests. A lot of unit tests.
Tip 91. Coding Ain't Done 'Til All the Tests Run. The automatic build runs all available tests. It's important to aim to "test for real," in other words, the test environment should match the production environment closely. Any gaps are where bugs breed.
Tip 92. Use Saboteurs to Test Your Testing. If you are really serious about testing, take a separate branch of the source tree, introduce bugs on purpose, and verify that the tests will catch them. At a higher level, you can use something like Netflix's Chaos Monkey[81] to disrupt (i.e., "kill") services and test your application's resilience.
Tip 93. Test State Coverage, Not Code Coverage.
Tip 94. Find Bugs Once. Once a human tester finds a bug, it should be the last time a human tester finds that bug. The automated tests should be modified to check for that particular bug from then on, every time, with no exceptions, no matter how trivial, and no matter how much the developer complains and says, "Oh, that will never happen again."
Tip 95. Don't Use Manual Procedures. People just aren't as repeatable as computers are. Nor should we expect them to be. A shell script or program will execute the same instructions, in the same order, time after time. It is under version control itself, so you can examine changes to the build/release procedures over time as well ("but it used to work...").
Tip 96. Delight Users, Don't Just Deliver Code. If you want to delight your client, forge a relationship with them where you can actively help solve their problems. Even though your title might be some variation of "Software Developer" or "Software Engineer," in truth it should be "Problem Solver." That's what we do, and that's the essence of a Pragmatic Programmer.
Tip 97. Sign Your Work. Artisans of an earlier age were proud to sign their work. You should be, too.
Tip 98. First, Do No Harm. Second, there's a judgment related to the Golden Rule: would I be happy to be a user of this software? Do I want my details shared? Do I want my movements to be given to retail outlets? Would I be happy to be driven by this autonomous vehicle? Am I comfortable doing this?
Tip 99. Don't Enable Scumbags.
Tip 100. It's Your Life.. Share it. Celebrate it. Build it.

Preface.
[1] If, over the years, every component of a ship is replaced as it fails, is the resulting vessel the same ship?
[2] https://pragprog.com/titles/tpp20

Chapter 1.
[3] http://wiki.c2.com/?ChangeYourOrganization
[4] See, for example, a good meta-analysis at Trust and team performance: A meta-analysis of main effects, moderators, and covariates, http://dx.doi.org/10.1037/apl0000110
[5] See The police and neighborhood safety [WH82]
[6] See Contagious depression: Existence, specificity to depressed symptoms, and the role of reassurance seeking [Joi94]
[7] While doing this, you may be comforted by the line attributed to Rear Admiral Dr. Grace Hopper: "It's easier to ask forgiveness than it is to get permission."
[8] That was supposed to be a joke!
[9] An expiring asset is something whose value diminishes over time. Examples include a warehouse full of bananas and a ticket to a ball game.
[10] We may be biased, but there's a fine selection available at https://pragprog.com.
[11] Never heard of any of these languages? Remember, knowledge is an expiring asset, and so is popular technology. The list of hot new and experimental languages was very different for the first edition, and is probably different again by the time you read this. All the more reason to keep learning.
[12] The word annoy comes from the Old French enui, which also means "to bore."

Chapter 2.
[13] To paraphrase the old Arlen/Mercer song...
[14] Or, perhaps, to keep your sanity, every 10th time...
[15] https://github.com/OAI/OpenAPI-Specification
[16] In reality, this is naive. Unless you are remarkably lucky, most real-world requirements changes will affect multiple functions in the system. However, if you analyze the change in terms of functions, each functional change should still ideally affect just one module.
[17] In fact, this book is written in Markdown, and typeset directly from the Markdown source.
[18] Take a nonlinear, or chaotic, system and apply a small change to one of its inputs. You may get a large and often unpredictable result. The cliched butterfly flapping its wings in Tokyo could be the start of a chain of events that ends up generating a tornado in Texas. Does this sound like any projects you know?
[19] https://rspec.info
[20] https://cucumber.io/
[21] https://phoenixframework.org/
[22] https://www.ansible.com/
[23] https://yaml.org/

Chapter 3.
[24] All software becomes legacy software as soon as it's written.
[25] Although the Elm language does have a time-traveling debugger.
[26] Why "rubber ducking"? While an undergraduate at Imperial College in London, Dave did a lot of work with a research assistant named Greg Pugh, one of the best developers Dave has known. For several months Greg carried around a small yellow rubber duck, which he'd place on his terminal while coding. It was a while before Dave had the courage to ask....
[27] Earlier versions of the book talked about talking to your pot plant. It was a typo. Honest.
[28] Here router means the tool that spins cutting blades very, very fast, not a device for interconnecting networks.
[29] There is some evidence that doodling helps focus and improves cognitive skills, for example, see What does doodling do? [And10].

Chapter 4.
[30] Based in part on earlier work by Dijkstra, Floyd, Hoare, Wirth, and others.
[31] In C and C++ these are usually implemented as macros. In Java, assertions are disabled by default. Invoke the Java VM with the -enableassertions flag to enable them, and leave them enabled.
[32] http://www.eps.mcgill.ca/jargon/jargon.html#heisenbug
[33] For a discussion of the dangers of coupled code, see Topic 28, "Decoupling".
[34] See the tip here.
[35] Per the NHTSA, Stopping Distance = Reaction Distance + Braking Distance, assuming an average reaction time of 1.5s and deceleration of 17.02ft/s^2.
[36] Motif and OpenLook were GUI standards for X-Window based Unix workstations.

Chapter 5.
[37] So it's not really a law. It's more like The Jolly Good Idea of Demeter.
[38] https://media.pragprog.com/articles/jan_03_enbug.pdf
[39] Yes, we know that Ruby already has this capability with its at_exit function.
[40] https://media.pragprog.com/titles/tpp20/cod...ommon/logger.js
[41] It seems that the first use of the characters |> as a pipe dates to 1994, in a discussion about the language Isobelle/ML, archived at https://blogs.msdn.microsoft.com/dsyme/2011...ne-symbol-1994/
[42] We've taken a liberty here. Technically we do execute the following functions. We just don't execute the code in them.
[43] In fact you could add such an operator to Elixir using its macro facility; an example of this is the Monad library in hex. You could also use Elixir's with construct, but then you lose much of the sense of writing transformations that you get with pipelines.
[44] https://www.quora.com/What-does-Alan-Kay-th...ted-programming
[45] It didn't help that the settlers beat the placid (read: stupid) birds to death with clubs for sport.

Chapter 6.
[46] Although UML has gradually faded, many of its individual diagrams still exist in one form or another, including the very useful activity diagram. For more information on all of the UML diagram types, see UML Distilled: A Brief Guide to the Standard Object Modeling Language [Fow04].
[47] The names P and V come from the initial letters of Dutch words. However there is some discussion about exactly which words. The inventor of the technique, Edsger Dijkstra, has suggested both passering and prolaag for P, and vrijgave and possibly verhogen for V.
[48] https://github.com/ncthbrt/nact
[49] In order to run this code you'll also need our wrapper functions, which are not shown here. You can download them from https://media.pragprog.com/titles/tpp20/cod...actors/index.js

Chapter 7.
[50] Note from the battle-scarred: UTC is there for a reason. Use it.
[51] https://en.wikipedia.org/wiki/Correlation_d...imply_causation
[52] See Topic 50, "Coconuts Don't Cut It".
[53] You can also go too far here. We once knew a developer who rewrote all source he was given because he had his own naming conventions.
[54] https://media-origin.pragprog.com/titles/tp...ort/src/main.rs
[55] And yes, we did voice our concerns over the title.
[56] Originally spotted in UML Distilled: A Brief Guide to the Standard Object Modeling Language [Fow00].
[57] This is excellent advice in general (see Topic 27, "Don't Outrun Your Headlights").
[58] Some folks argue that test-first and test-driven development are two different things, saying that the intents of the two are different. However, historically, test-first (which comes from eXtreme Programming) was identical to what people now call TDD.
[59] https://ronjeffries.com/categories/sudoku. A big "thank you" to Ron for letting us use this story.
[60] http://norvig.com/sudoku.html
[61] We've been trying since at least 1986, when Cox and Novobilski coined the term "software IC" in their Objective-C book Object-Oriented Programming Object-Oriented Programming: An Evolutionary Approach [CN91].
[62] See Topic 20, "Debugging".
[63] Remember our good friend, little Bobby Tables (https://xkcd.com/327)? While you're reminiscing have a look at https://bobby-tables.com, which lists ways of sanitizing data passed to database queries.
[64] This technique has proven to be successful at the CPU chip level, where well-known exploits target debugging and administrative facilities. Once cracked, the entire machine is left exposed.
[65] NIST Special Publication 800-63B: Digital Identity Guidelines: Authentication and Lifecycle Management, available free online at https://doi.org/10.6028/NIST.SP.800-63b
[66] Unless you have a PhD in cryptography, and even then only with major peer review, extensive field trials with a bug bounty, and budget for long-term maintenance.
[67] Studies of Interference in Serial Verbal Reactions [Str35]
[68] We have two versions of this panel. One uses different colors, and the other uses shades of gray. If you're seeing this in black and white and want the color version, or if you're having trouble distinguishing colors and want to try the grayscale version, pop over to https://pragprog.com/the-pragmatic-programmer/stroop-effect.
[69] Do you know why i is commonly used as a loop variable? The answer comes from over 60 years ago, when variables starting with I through N were integers in the original FORTRAN. And FORTRAN was in turn influenced by algebra.

Chapter 8.
[70] Does a week sound like a long time? It really isn't, particularly when you're looking at processes in which management and workers occupy different worlds. Management will give you one view of how things operate, but when you get down on the floor, you'll find a very different reality-one that will take time to assimilate.
[71] https://www.wired.com/1999/01/eno/
[72] https://www.psychologytoday.com/us/blog/you...-solve-problems
[73] https://agilemanifesto.org
[74] For more on just how bad that approach can be, see The Tyranny of Metrics [Mul18].

Chapter 9.
[75] As team size grows, communication paths grow at the rate of , where is the number of team members. On larger teams, communication begins to break down and becomes ineffective.
[76] A burnup chart is better for this than the more usual burndown chart. With a burnup chart, you can clearly see how the additional features move the goalposts.
[77] The team speaks with one voice-externally. Internally, we strongly encourage lively, robust debate. Good developers tend to be passionate about their work.
[78] Andy has met teams who conduct their daily Scrum standups on Fridays.
[79] See https://en.wikipedia.org/wiki/Cargo_cult.
[80] We've seen this first-hand more times than you'd think.
[81] https://netflix.github.io/chaosmonkey
[82] For an interesting study of the correlation between test coverage and defects, see Mythical Unit Test Coverage [ADSS18].
[83] Always remember Topic 3, "Software Entropy". Always.
[84] http://www.extremeprogramming.org

Appendix 2.
Footnotes
[85] Thanks for this bit of trivia goes to Avi Bryant (@avibryant)

[ADSS18]. Vard Antinyan, Jesper Derehag, Anna Sandberg, and Miroslaw Staron. Mythical Unit Test Coverage. IEEE Software. 35:73-79, 2018.
[And10]. Jackie Andrade. What does doodling do? Applied Cognitive Psychology. 24(1):100-106, 2010, January.
[Arm07]. Joe Armstrong. Programming Erlang: Software for a Concurrent World. The Pragmatic Bookshelf, Raleigh, NC, 2007.
[BR89]. Albert J. Bernstein and Sydney Craft Rozen. Dinosaur Brains: Dealing with All Those Impossible People at Work. John Wiley & Sons, New York, NY, 1989.
[Bro96]. Frederick P. Brooks, Jr. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, Reading, MA, Anniversary, 1996.
[CN91]. Brad J. Cox and Andrew J. Novobilski. Object-Oriented Programming: An Evolutionary Approach. Addison-Wesley, Reading, MA, Second, 1991.
[Con68]. Melvin E. Conway. How do Committees Invent? Datamation. 14(5):28-31, 1968, April.
[de 98]. Gavin de Becker. The Gift of Fear: And Other Survival Signals That Protect Us from Violence. Dell Publishing, New York City, 1998.
[DL13]. Tom DeMacro and Tim Lister. Peopleware: Productive Projects and Teams. Addison-Wesley, Boston, MA, Third, 2013.
[Fow00]. Martin Fowler. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley, Boston, MA, Second, 2000.
[Fow04]. Martin Fowler. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley, Boston, MA, Third, 2004.
[Fow19]. Martin Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley, Boston, MA, Second, 2019.
[GHJV95]. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1995.
[Hol92]. Michael Holt. Math Puzzles & Games. Dorset House, New York, NY, 1992.
[Hun08]. Andy Hunt. Pragmatic Thinking and Learning: Refactor Your Wetware. The Pragmatic Bookshelf, Raleigh, NC, 2008.
[Joi94]. T.E. Joiner. Contagious depression: Existence, specificity to depressed symptoms, and the role of reassurance seeking. Journal of Personality and Social Psychology. 67(2):287--296, 1994, August.
[Knu11]. Donald E. Knuth. The Art of Computer Programming, Volume 4A: Combinatorial Algorithms, Part 1. Addison-Wesley, Boston, MA, 2011.
[Knu98]. Donald E. Knuth. The Art of Computer Programming, Volume 1: Fundamental Algorithms. Addison-Wesley, Reading, MA, Third, 1998.
[Knu98a]. Donald E. Knuth. The Art of Computer Programming, Volume 2: Seminumerical Algorithms. Addison-Wesley, Reading, MA, Third, 1998.
[Knu98b]. Donald E. Knuth. The Art of Computer Programming, Volume 3: Sorting and Searching. Addison-Wesley, Reading, MA, Second, 1998.
[KP99]. Brian W. Kernighan and Rob Pike. The Practice of Programming. Addison-Wesley, Reading, MA, 1999.
[Mey97]. Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall, Upper Saddle River, NJ, Second, 1997.
[Mul18]. Jerry Z. Muller. The Tyranny of Metrics. Princeton University Press, Princeton NJ, 2018.
[SF13]. Robert Sedgewick and Phillipe Flajolet. An Introduction to the Analysis of Algorithms. Addison-Wesley, Boston, MA, Second, 2013.
[Str35]. James Ridley Stroop. Studies of Interference in Serial Verbal Reactions. Journal of Experimental Psychology. 18:643--662, 1935.
[SW11]. Robert Sedgewick and Kevin Wayne. Algorithms. Addison-Wesley, Boston, MA, Fourth, 2011.
[Tal10]. Nassim Nicholas Taleb. The Black Swan: Second Edition: The Impact of the Highly Improbable. Random House, New York, NY, Second, 2010.
[WH82]. James Q. Wilson and George Helling. The police and neighborhood safety. The Atlantic Monthly. 249[3]:29--38, 1982, March.
[YC79]. Edward Yourdon and Larry L. Constantine. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. Prentice Hall, Englewood Cliffs, NJ, 1979.
[You95]. Edward Yourdon. When good-enough software is best. IEEE Software. 1995, May.

I would rather have questions that can't be answered than answers that can't be questioned.
Richard Feynman