The Pragmatic Programmer Quotes

“be strict in what you will accept before you begin, and promise as little as possible in return.”
― David Thomas, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“When good-enough software is best [You95], you can discipline yourself to write software that’s good enough—good enough for your users, for future maintainers, for your own peace of mind.”
― David Thomas, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“We who cut mere stones must always be envisioning cathedrals.”
― David Thomas, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“Pragmatic Programmers get the job done, and do it well.”
― David Thomas, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“We find that often the only way to determine the timetable for a project is by gaining experience on that same project. This needn’t be a paradox if you practice incremental development, repeating the following steps with very thin slices of functionality: Check requirements Analyze risk (and prioritize riskiest items earlier) Design, implement, integrate Validate with the users”
― David Thomas, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“Here are some specific areas you may want to look for in the architectural prototype: Are the responsibilities of the major areas well defined and appropriate? Are the collaborations between major components well defined? Is coupling minimized? Can you identify potential sources of duplication? Are interface definitions and constraints acceptable? Does every module have an access path to the data it needs during execution? Does it have that access when it needs it?”
― David Thomas, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“But that ignores the fact that tests are also a way of communicating with other developers, so I now do write tests on code shared with others or that relies on the peculiarities of external dependencies.”
― David Thomas, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“we want to avoid creating a “time bomb”—something that sits around unnoticed and blows up at an awkward moment later in the project. By emphasizing testing against contract, we can try to avoid as many of those downstream disasters as possible.”
― David Thomas, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“All on Automatic We were once at a client site where all the developers were using the same IDE. Their system administrator gave each developer a set of instructions on installing add-on packages to the IDE. These instructions filled many pages—pages full of click here, scroll there, drag this, double-click that, and do it again. Not surprisingly, every developer's machine was loaded slightly differently. Subtle differences in the application's behavior occurred when different developers ran the same code. Bugs would appear on one machine but not on others.”
― Andrew Hunt, The Pragmatic Programmer

“Don’t try to refactor and add functionality at the same time.”
― David Thomas, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“Always be aware of what you are doing.”
― David Thomas, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“At all levels, people operate with many assumptions in mind—but these assumptions are rarely documented and are often in conflict between different developers.”
― David Thomas, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“Don’t assume it, prove it.”
― David Thomas, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“For routines you call, rely only on documented behavior. If you can’t, for whatever reason, then document your assumption well.”
― David Thomas, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.”
― David Thomas, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“Civilization advances by extending the number of important operations we can perform without thinking.”
― Andrew Hunt, The Pragmatic Programmer

“A dead program normally does a lot less damage than a crippled one.”
― Andrew Hunt, The Pragmatic Programmer: From Journeyman to Master

“We frequently hear software development leaders tell their staff, “We should operate like Netflix” (or one of these other leading companies). Of course you could do that. First, get yourself a few hundred thousand servers and tens of millions of users...”
― Andrew Hunt, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“Always take small, deliberate steps, checking for feedback and adjusting before proceeding”
― Andrew Hunt, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“I would rather have questions that can’t be answered than answers that can’t be questioned. Richard Feynman”
― Andrew Hunt, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“Commenting source code gives you the perfect opportunity to document those elusive bits of a project that can’t be documented anywhere else: engineering trade-offs, why decisions were made, what other alternatives were discarded, and so on.”
― Andrew Hunt, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“The more effective that communication, the more influential you become.”
― Andrew Hunt, The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

“The greatest of all weaknesses is the fear of appearing weak. • J. B. Bossuet, Politics from”
― Andrew Hunt, The Pragmatic Programmer

“Distrust environments where requirements are gathered, specifications are written, and then coding starts, all in isolation.”
― Andrew Hunt, The Pragmatic Programmer

“Finally, there is the straightjacket effect. A design that leaves the coder no room for interpretation robs the programming effort of any skill and art. Some would say this is for the best, but they're wrong. Often, it is only during coding that certain options become apparent. While coding, you may think "Look at that. Because of the particular way I coded this routine, I could add this additional functionality with almost no effort" or "The specification says to do this, but I could achieve an almost identical result by doing it a different way, and I could do it in half the time.”
― Andrew Hunt, The Pragmatic Programmer

“The Landing Pilot is the Non-Handling Pilot until the 'decision altitude' call, when the Handling Non-Landing Pilot hands the handling to the Non-Handling Landing Pilot, unless the latter calls 'go-around,' in which case the Handling Non-Landing Pilot continues handling and the Non-Handling Landing Pilot continues non-handling until the next call of 'land' or 'go-around' as appropriate. In view of recent confusions over these rules, it was deemed necessary to restate them clearly. • British Airways memorandum, quoted in Pilot Magazine, December 1996”
― Andrew Hunt, The Pragmatic Programmer

“Every craftsman starts his or her journey with a basic set of good-quality tools. A woodworker might need rules, gauges, a couple of saws, some good planes, fine chisels, drills and braces, mallets, and clamps. These tools will be lovingly chosen, will be built to last, will perform specific jobs with little overlap with other tools, and, perhaps most importantly, will feel right in the budding woodworker's hands. Then begins a process of learning and adaptation. Each tool will have its own personality and quirks, and will need its own special handling. Each must be sharpened in a unique way, or held just so. Over time, each will wear according to use, until the grip looks like a mold of the woodworker's hands and the cutting surface aligns perfectly with the angle at which the tool is held. At this point, the tools become conduits from the craftsman's brain to the finished product—they have become extensions of his or her hands. Over time, the woodworker will add new tools, such as biscuit cutters, laser-guided miter saws, dovetail jigs—all wonderful pieces of technology. But you can bet that he or she will be happiest with one of those original tools in hand, feeling the plane sing as it slides through the wood.”
― Andrew Hunt, The Pragmatic Programmer

“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.”
― Andrew Hunt, The Pragmatic Programmer

“Debugging itself is a sensitive, emotional subject for many developers. Instead of attacking it as a puzzle to be solved, you may encounter denial, finger pointing, lame excuses, or just plain apathy.”
― Andrew Hunt, The Pragmatic Programmer

“The greatest of all weakness is the fear of appearing week.”
― Andrew Hunt, The Pragmatic Programmer: From Journeyman to Master