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.

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.

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.

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

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

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.

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.

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]

Programmers are constantly in maintenance mode.

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

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

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.

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

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

We who cut mere stones must always be envisioning cathedrals.

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

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.

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.

Don't Gather Requirements—Dig for Them

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

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.

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

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.

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

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

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

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.

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.

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.

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

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.

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

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

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.

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

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.

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.

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.

The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas (Addison-Wesley Professional, 1999).

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.

The greatest of all weakness is the fear of appearing week.

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

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.

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.

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 O() notation puts an upper bound on the value of the thing we're measuring (time, memory, and so on).

Don't be a slave to any notation;

Requirements are not architecture. Requirements are not design, nor are they the user interface. Requirements are need.

When in doubt, it always pays to reduce scope.

We who cut mere stones must always be envisioning cathedrals.

nonorthogonal systems are inherently more complex to change and control. When components of any system are highly interdependent, there is no such thing as a local fix.

Algorithms [SW11]An Introduction to the Analysis of Algorithms [SF13]

Listen to Nagging Doubts—Start When You're Ready

Don't Think Outside the Box—Find the Box

Let your instincts contribute to your performance.

Just tell yourself, “No broken windows.

Pragmatic Programmers get the job done, and do it well.

A programação é uma arte. Basicamente, se resume a conseguir que um computador faça o que você quer que ele faça (ou o que seu usuário quer que ele faça). Como programador, você é parte ouvinte, parte conselheiro, parte intérprete e parte definidor. Tenta capturar requisitos vagos e encontrar uma maneira de expressá-los para que uma simples máquina possa concretizá-los. Tenta documentar seu trabalho para que outras pessoas possam entendê-lo e tenta construir seu trabalho de um modo que outros possam se basear nele. Procura fazer tudo isso contra o implacável decorrer do tempo do projeto. Você faz pequenos milagres diariamente.

This book will help you become a better programmer.

Studies from many parts of the world, and many different time periods, show that ‘less advanced’ agricultural practices can out-perform more complex technologies. Detailed knowledge of local conditions, combined with a pragmatic receptivity to useful ideas, facilitates effective use of resources, while the precarious conditions many small farmers face encourage innovation.7 In highland Guatemala, smallholders maintain vegetable plots producing food for their households alongside fields with export crops of the sort encouraged by development programmes. Such farmers cannot afford to be conservative in their agricultural practices.

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 span of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.

Computer languages influence how you think about a problem, and how you think about communicating. Every language comes with a list of features: buzzwords such as static versus dynamic typing, early versus late binding, functional versus OO, inheritance models, mixins, macros

Two or more things are orthogonal if changes in one do not affect any of the others. In a well-designed system, the database code will be orthogonal to the user interface: you can change the interface without affecting the database, and swap databases without changing the interface.

Tracer bullets show what you’re hitting. This may not always be the target. You then adjust your aim until they’re on target. That’s the point. It’s the same with tracer code.