Pragmatic Programmer, The

What distinguishes Pragmatic Programmers? We feel it’s an attitude, a style, a philosophy of approaching problems and their solutions. They think beyond the immediate problem, placing it in its larger context and seeking out the bigger picture.

I’m not in this world to live up to your expectations and you’re not in this world to live up to mine. Bruce Lee

Don’t leave “broken windows’’ (bad designs, wrong decisions, or poor code) unrepaired.

Don’t spoil a perfectly good program by overembellishment and overrefinement.

Ask the “Five Whys”

Who does this benefit?

Why is this a problem?

Plan what you want to say. Write an outline. Then ask yourself, “Does this communicate what I want to express to my audience in a way that works for them?” Refine it until it does.

DRY—Don’t Repeat Yourself

This layered approach is a powerful way to design orthogonal systems. Because each layer uses only the abstractions provided by the layers below it, you have great flexibility in changing underlying implementations without affecting code. Layering also reduces the risk of runaway dependencies between modules.

There are several techniques you can use to maintain orthogonality: Keep your code decoupled Write shy code—modules that don’t reveal anything unnecessary to other modules and that don’t rely on other modules’ implementations.

Avoid global data Every time your code references global data, it ties itself into the other components that share that data.

With DRY, you’re looking to minimize duplication within a system, whereas with orthogonality you reduce the interdependency among the system’s components.

Every PERT task has an optimistic, a most likely, and a pessimistic estimate.

It doesn’t really matter whether the bug is your fault or someone else’s. It is still your problem.

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?

A very simple but particularly useful technique for finding the cause of a problem is simply to explain it to someone else.

The finish what you start tip tells us that, ideally, the routine that allocates a resource should also free it.