The Pragmatic Programmer Quotes
The Pragmatic Programmer: From Journeyman to Master
by
Andy Hunt23,784 ratings, 4.33 average rating, 1,496 reviews
The Pragmatic Programmer Quotes
Showing 151-180 of 240
“Once they've agreed to the layout, you might throw it away and recode”
― The Pragmatic Programmer
― The Pragmatic Programmer
“Pragmatic Programmers don't shirk from responsibility. Instead, we rejoice in accepting challenges and in making our”
― The Pragmatic Programmer
― The Pragmatic Programmer
“we just don't have the time to go chasing after bugs that the automated tests could
have found for us. We have to spend our time writing new code—and new bugs.”
― The Pragmatic Programmer: From Journeyman to Master
have found for us. We have to spend our time writing new code—and new bugs.”
― The Pragmatic Programmer: From Journeyman to Master
“Pragmatic Programmers are different. We are driven to find our bugs now, so we don't
have to endure the shame of others finding our bugs later.”
― The Pragmatic Programmer: From Journeyman to Master
have to endure the shame of others finding our bugs later.”
― The Pragmatic Programmer: From Journeyman to Master
“Let the computer do the repetitious, the mundane—it will do a better job of it than we would. We've got more
important and more difficult things to do.”
― The Pragmatic Programmer: From Journeyman to Master
important and more difficult things to do.”
― The Pragmatic Programmer: From Journeyman to Master
“Nothing is more dangerous than an idea if it's the only one you have. • Emil-Auguste Chartier, Propos sur la religion, 1938 Engineers”
― The Pragmatic Programmer
― The Pragmatic Programmer
“At Group L, Stoffel oversees six first-rate programmers, a managerial challenge roughly comparable to herding cats. • The Washington Post Magazine, June 9, 1985 So”
― The Pragmatic Programmer: From Journeyman to Master
― The Pragmatic Programmer: From Journeyman to Master
“if you're using an exponential algorithm O(2n), you might want to make a cup of coffee—your routine should finish in about 10263 years. Let us know how the universe ends.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“In the most extreme case, the routine you called may not even be designed to do what you want, but it seems to work okay. Calling things in the wrong order, or in the wrong context, is a related problem. paint(g); invalidate(); validate(); revalidate(); repaint(); paintImmediately(r); Here it looks like Fred is desperately trying to get something out on the screen. But these routines were never designed to be called this way; although they seem to work, that's really just a coincidence.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“Suppose Fred is given a programming assignment. Fred types in some code, tries it, and it seems to work. Fred types in some more code, tries it, and it still seems to work. After several weeks of coding this way, the program suddenly stops working, and after hours of trying to fix it, he still doesn't know why. Fred may well spend a significant amount of time chasing this piece of code around without ever being able to fix it. No matter what he does, it just doesn't ever seem to work right. Fred doesn't know why the code is failing because he didn't know why it worked in the first place. It seemed to work, given the limited "testing" that Fred did, but that was just a coincidence. Buoyed by false confidence, Fred charged ahead into oblivion.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“One broken window—a badly designed piece of code, a poor management decision that the team must live with for the duration of the project—is all it takes to start the decline. If you find yourself working on a project with quite a few broken windows, it's all too easy to slip into the mindset of "All the rest of this code is crap, I'll just follow suit." It doesn't matter if the project has been fine up to this point. 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. By the same token, 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.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“Nothing astonishes men so much as common sense and plain dealing. • Ralph Waldo Emerson, Essays”
― The Pragmatic Programmer
― The Pragmatic Programmer
“People find it easier to join an ongoing success. Show them a glimpse of the future and you'll get them to rally around.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“All software becomes legacy as soon as it's written.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“Show them a glimpse of the future and you'll get them to rally around.”
― The Pragmatic Programmer: From Journeyman to Master
― The Pragmatic Programmer: From Journeyman to Master
“If you add layer upon layer, detail over detail, the painting becomes lost in the paint.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“Most software disasters start out too small to notice, and most project overruns happen a day at a time.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“Grace Hopper: "It's easier to ask forgiveness than it is to get permission.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“It is a painful thing To look at your own trouble and know That you yourself and no one else has made it • Sophocles, Ajax”
― The Pragmatic Programmer
― The Pragmatic Programmer
“Estimates given at the coffee machine will (like the coffee) come back to haunt you.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“Pragmatic Programmers, however, tend to prefer using tracer bullets.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“When an estimate turns out wrong, don't just shrug and walk away. Find out why it differed from your guess. Maybe you chose some parameters that didn't match the reality of the problem. Maybe your model was wrong. Whatever the reason, take some time to uncover what happened. If you do, your next estimate will be better.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“Software defects manifest themselves in a variety of ways, from misunderstood requirements to coding errors.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“Gain familiarity with the shell, and you'll find your productivity soaring.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“If you use plain text to create synthetic data to drive system tests, then it is a simple matter to add, update, or modify the test data without having to create any special tools to do so. Similarly, plain text output from regression tests can be trivially analyzed (with diff, for instance) or subjected to more thorough scrutiny with Perl, Python, or some other scripting tool.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“As Pragmatic Programmers, our base material isn't wood or iron, it's knowledge. We gather requirements as knowledge, and then express that knowledge in our designs, implementations, tests, and documents.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“Just as woodworkers sometimes build jigs to guide the construction of complex pieces, programmers can write code that itself writes code.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“Like the craftsman, expect to add to your toolbox regularly. Always be on the lookout for better ways of doing things.”
― The Pragmatic Programmer
― The Pragmatic Programmer
“You almost always get better results if you slow the process down and spend some time going through the steps”
― The Pragmatic Programmer
― The Pragmatic Programmer
“What to Say When Asked for an Estimate You say "I'll get back to you.”
― The Pragmatic Programmer
― The Pragmatic Programmer
