The Pragmatic Programmer: From Journeyman to Master

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

Don't spoil a perfectly good program by overembellishment and over-refinement.

Show them a glimpse of the future and you'll get them to rally around.[1]

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,

We feel that the best way to deal with this is to encourage active and frequent communication

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. Otherwise, we're duplicating knowledge, and every change means changing both the code and the comments. The comments will inevitably become out of date, and untrustworthy comments are worse than no c

Start learning a new language this week.

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

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