The Pragmatic Programmer: From Journeyman to Master

But ask permission to tackle the whole thing and you'll be met with delays and blank stares.

every decision results in a different version of the future. How many possible futures can your code support?

What you're trying to do is foster an environment where it's easier to find and reuse existing stuff than to write it yourself. If it isn't easy, people won't do it.

envisioned by their original implementors. The more loosely coupled your systems, the easier they are to reconfigure and reengineer.

[Ber96] Albert J. Bernstein. Dinosaur Brains: Dealing with All Those Impossible People at Work. Ballantine Books, New York, NY, 1996.

[DL99] Tom Demarco and Timothy Lister. Peopleware: Productive Projects and Teams. Dorset House, New York, NY, second edition, 1999.

Have a central place in the source tree where utility routines and scripts can be deposited. And make a point of reading other people's source code and documentation, either informally or during code reviews.

In computing, the term has come to signify a kind of independence or decoupling. 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

We want to design components that are self-contained: independent, and with a single, well-defined purpose (what Yourdon and Constantine call cohesion [YC86]). When components are isolated from one another, you know that you can change one without having to worry about the rest.