Pragmatic Programmer Quotes

The greatest of all weaknesses is the fear of appearing weak.

An investment in knowledge always pays the best interest.

Tools amplify your talent. The better your tools, and the better you know how to use them, the more productive you can be.

Kaizen" is a Japanese term that captures the concept of continuously making many small improvements.

Great software today is often preferable to perfect software tomorrow.

Names are deeply meaningful to your brain, and misleading names add chaos to your code.

We who cut mere stones must always be envisioning cathedrals. —Quarry worker's creed

Don't be a slave to history. Don't let existing code dictate future code. All code can be replaced if it is no longer appropriate. Even within one program, don't let what you've already done constrain what you do next -- be ready to refactor... This decision may impact the project schedule. The assumption is that the impact will be less than the cost of /not/ making the change.

The editor will be an extension of your hand; the keys will sing as they slice their way through text and thought.

Don't gloss over a routine or piece of code involved in the bug because you "know" it works. Prove it. Prove it in this context, with this data, with these boundary conditions.

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.

A good idea is an orphan without effective communication.

Every day, work to refine the skills you have and to add new tools to your repertoire.

One hundred years from now, our engineering may seem as archaic as the techniques used by medieval cathedral builders seem to today's civil engineers, while our craftsmanship will still be honored.

The amount of surprise you feel when something goes wrong is directly proportional to the amount of trust and faith you have in the code being run.

All software you write will be tested—if not by you and your team, then by the eventual users—so you might as well plan on testing it thoroughly.

Programmers are constantly in maintenance mode.

Just as in financial investing, you must invest in your knowledge portfolio regularly.

In an article in the April 1999 CACM, Robert Glass summarizes research that seems to indicate that, while code inspection is effective, conducting reviews in meetings is not.

By coding at a higher level of abstraction, you are free to concentrate on solving domain problems, and can ignore petty implementation details.

People find it easier to join an ongoing success. Show them a glimpse of the future and you’ll get them to rally around.[7]

In some ways, programming is like painting. You start with a blank canvas and certain basic raw materials. You use a combination of science, art, and craft to determine what to do with them.

If you work closely with your users, sharing their expectations and communicating what you're doing, then there will be few surprises when the project gets delivered. This is a BAD THING. Try to surprise your users. Not scare them, mind you, but /delight/ them.

In some ways, programming is like painting. You start with a blank canvas and certain basic raw materials. You use a combination of science, art, and craft to determine what to do with them. You sketch out an overall shape, paint the underlying environment, then fill in the details. You constantly step back with a critical eye to view what you've done. Every now and then you'll throw a canvas away and start again. But artists will tell you that all the hard work is ruined if you don't know when to stop. If you add layer upon layer, detail over detail, the painting becomes lost in the paint.

We who cut mere stones must always be envisioning cathedrals.

In addition, build dependencies may not be the same as test dependencies, and you may need separate hierarchies.

...maintaining good regression tests is the key to refactoring with confidence.

Providing a comfortable transition through familiar metaphors is one way to help get buy-in.

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.

Rather than construction, software is more like gardening—it is more organic than concrete. You plant many things in a garden according to an initial plan and conditions. Some thrive, others are destined to end up as compost.

We can be proud of our abilities, but we must be honest about our shortcomings—our ignorance as well as our mistakes.

Responsibility is something you actively agree to.

Don't Gather Requirements—Dig for Them

Just be aware that you reach a point of diminishing, or even negative, returns as the specifications get more and more detailed.

More testing should be done automatically. It's important to note that by "automatically" we meant that the test /results/ are interpreted automatically as well.

Documenting the reasons behind requirements will give your team invaluable information when making daily implementation decisions.

As a programmer, you are part listener, part advisor, part interpreter, and part dictator.

Pragmatic Programmers won't sit idly by and watch their projects fall apart through neglect.

A Pragmatic Programmer takes charge of his or her own career, and isn't afraid to admit ignorance or error.

Great software today is often preferable to perfect software tomorrow. If you give your users something to play with early, their feedback will often lead you to a better eventual solution

In an abstract sense, an application is successful if it correctly implements its specifications. Unfortunately, this pays only abstract bills. In reality, the success of a project is measured by how well it meets the expectations of its users.

There is a simple marketing trick that helps teams communicate as one: generate a brand. When you start a project, come up with a name for it, ideally something off-the-wall. (In the past, we've named projects after things such as killer parrots that prey on sheep, optical illusions, and mythical cities.) ...Use your team's name liberally when talking with people. It sounds silly, but it gives your team an identity to build on, and the world something memorable to associate with your work.

Ruthless and Continuous Testing Many developers test gently, subconsciously knowing where the code will break and avoiding the weak spots. 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 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. Check requirements Analyze risk Design, implement, integrate Validate with the users

not just asking questions, having discussions, and taking notes, but asking questions and having discussions while you’re actually coding.

Most people assume that maintenance begins when an application is released, that maintenance means fixing bugs and enhancing features. We think these people are wrong.

An investment in knowledge always pays the best interest. • Benjamin Franklin

You have the right not to take on a responsibility for an impossible situation,

There are other factors that can contribute to software rot, and we'll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.

it is equally unprofessional to promise impossible time scales and to cut basic engineering corners to meet a deadline.

Don't rely on the properties of things you can't control.

The DRY principle tells us to keep the low-level knowledge in the code, where it belongs, and reserve the comments for other, high-level explanations.

Within the overall structure of a project there is always room for individuality and craftsmanship.

it is up to you to provide solutions, not excuses.

Entropy is a term from physics that refers to the amount of "disorder" in a system.

perfect software doesn't exist. No one in the brief history of computing has ever written a piece of perfect software.

In the same way a woodworker invests the time in a jig, a programmer can build a code generator. Once built, it can be used throughout the life of the project at virtually no cost.

There is a luxury in self-reproach. When we blame ourselves we feel no one else has a right to blame us.

Nothing is more dangerous than an idea if it's the only one you have.

Finding an answer that happens to fit is not the same as the right answer.

The best way to start fixing a bug is to make it reproducible. After all, if you can’t reproduce it, how will you know if it is ever fixed?

However, for programmers, combining rich, flexible human thought with the rigid constraints of a digital computer exposes the power and the deepest flaws of both.

Don't be like the frog. Keep an eye on the big picture. Constantly review what's happening around you, not just what you personally are doing.

Delivering good software today is often better than perfect software tomorrow, so finish things and ship.

One of the cornerstones of the pragmatic philosophy is the idea of taking responsibility for yourself and your actions in terms of your career advancement, your project, and your day-to-day work.

Often this is an orthogonality issue. When teams are organized with lots of overlap, members are confused about responsibilities. Every change needs a meeting of the entire team, because any one of them might be affected.

Have you noticed how some project teams are efficient, with everyone knowing what to do and contributing fully, while the members of other teams are constantly bickering and don't seem able to get out of each other's way? Often this is an orthogonality issue. When teams are organized with lots of overlap, members are confused about responsibilities. Every change needs a meeting of the entire team, because any one of them might be affected.

Look for the important requirements, the ones that define the system. Look for the areas where you have doubts, and where you see the biggest risks. Then prioritize your development so that these are the first areas you code.

All programs transform data, converting an input into an output. And yet when we think about design, we rarely think about creating transformations. Instead we worry about classes and modules, data structures and algorithms, languages and frameworks.

A very simple but particularly useful technique for finding the cause of a problem is simply to explain it to someone else. The other person should look over your shoulder at the screen, and nod his or her head constantly (like a rubber duck bobbing up and down in a bathtub). They do not need to say a word; the simple act of explaining, step by step, what the code is supposed to do often causes the problem to leap off the screen and announce itself.[7] [7] 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....

Before you start to look at the bug, make sure that you are working on code that built cleanly—without warnings. We routinely set compiler warning levels as high as possible. It doesn’t make sense to waste time trying to find a problem that the computer could find for you! We need to concentrate on the harder problems at hand.

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.

Malthus’s poor laws were wrong; British attitudes to famine in India and Ireland were wrong; eugenics was wrong; the Holocaust was wrong; India’s sterilisation programme was wrong; China’s one-child policy was wrong. These were sins of commission, not omission. Malthusian misanthropy – the notion that you should harden your heart, approve of famine and disease, feel ashamed of pity and compassion, for the good of the race – was wrong pragmatically as well as morally. The right thing to do about poor, hungry and fecund people always was, and still is, to give them hope, opportunity, freedom, education, food and medicine, including of course contraception, for not only will that make them happier, it will enable them to have smaller families.

The native islanders had never seen an airplane before, or met people such as these strangers. In return for use of their land, the strangers provided mechanical birds that flew in and out all day long on a “runway,” bringing incredible material wealth to their island home. The strangers mentioned something about war and fighting. One day it was over and they all left, taking their strange riches with them. The islanders were desperate to restore their good fortunes, and re-built a facsimile of the airport, control tower, and equipment using local materials: vines, coconut shells, palm fronds, and such. But for some reason, even though they had everything in place, the planes didn’t come. They had imitated the form, but not the content. Anthropologists call this a cargo cult. All too often, we are the islanders.

Unfortunately, the most common metaphor for software development is building construction. [...] Well, software doesn’t quite work that way. Rather than construction, software is more like gardening—it is more organic than concrete. You plant many things in a garden according to an initial plan and conditions. Some thrive, others are destined to end up as compost. You may move plantings relative to each other to take advantage of the interplay of light and shadow, wind and rain. Overgrown plants get split or pruned, and colors that clash may get moved to more aesthetically pleasing locations. You pull weeds, and you fertilize plantings that are in need of some extra help. You constantly monitor the health of the garden, and make adjustments (to the soil, the plants, the layout) as needed. Business people are comfortable with the metaphor of building construction: it is more scientific than gardening, it’s repeatable, there’s a rigid reporting hierarchy for management, and so on. But we’re not building skyscrapers—we aren’t as constrained by the boundaries of physics and the real world. The gardening metaphor is much closer to the realities of software development. Perhaps a certain routine has grown too large, or is trying to accomplish too much—it needs to be split into two. Things that don’t work out as planned need to be weeded or pruned.

Despite the best laid plans and the best people, a project can still experience ruin and decay during its lifetime. Yet there are other projects that, despite enormous difficulties and constant setbacks, successfully fight nature's tendency toward disorder and manage to come out pretty well. What makes the difference? In inner cities, some buildings are beautiful and clean, while others are rotting hulks. Why? Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism, one that very quickly turns a clean, intact, inhabited building into a smashed and abandoned derelict [WK82]. A broken window. One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don't care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner's desire to fix it, and the sense of abandonment becomes reality. The "Broken Window Theory" has inspired police departments in New York and other major cities to crack down on the small stuff in order to keep out the big stuff. It works: keeping on top of broken windows, graffiti, and other small infractions has reduced the serious crime level.

Always take small, deliberate steps, checking for feedback and adjusting before proceeding

A dead program normally does a lot less damage than a crippled one.

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...

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.

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.

If you can’t describe what you are doing as a process, you don’t know what you’re doing.

Doctor, it hurts when I do this. Then don’t do that.

It’s much easier to find and diagnose the problem by crashing early, at the site of the problem.

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?

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

When in doubt, it always pays to reduce scope.

you shouldn’t make decisions based on the internal state of an object and then update that object.

There are certain tips and tricks that apply at all levels of software development, ideas that are almost axiomatic, and processes that are virtually universal. However, these approaches are rarely documented as such; you'll mostly find them written down as odd sentences in discussions of design, project management, or coding.

When we perform maintenance, we have to find and change the representations of things—those capsules of knowledge embedded in the application. The problem is that it's easy to duplicate knowledge in the specifications, processes, and programs that we develop, and when we do so, we invite a maintenance nightmare—one that starts well before the application ships.

Nothing is more dangerous than an idea if it's the only one you have. • Emil-Auguste Chartier, Propos sur la religion, 1938

If it's easy to reuse, people will. Create an environment that supports reuse.

Alexis Tsipras, the Syriza leader, has in recent weeks abandoned his pledge to “tear up” the country’s bailout agreement with international creditors and is emphasising more moderate steps to address Greece’s debt load as well as his deep commitment to the euro. Krishna Guha, of Evercore ISI, warned that — at a minimum — investors now faced “a four-week period of elevated uncertainty in which eurozone risk assets will struggle to perform”. Yet Mr Guha added: “We believe that Tsipras will prove more pragmatic than past Syriza rhetoric suggests. He has opened back channels to Berlin, Paris and Frankfurt, and has every incentive to try to negotiate relatively cosmetic changes to Greece’s programme and ride the early-stage Greek recovery rather than derail it.” Nick Wall, a portfolio manager at Invesco, also noted Mr Tsipras’ recent attempt to tack to the political centre. “They are going to need private sector investors, particularly if they are going to start running deficits again.

Developers who don't actively think about their code are programming by coincidence—the code might work, but there's no particular reason why.

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

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.

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.

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.

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 greatest of all weakness is the fear of appearing week.