Programming Pearls by Jon Bentley

• Careful analysis of a small problem can sometimes yield tremendous practical benefits.
• Determining what the user really wants to do is an essential part of programming.
• Don't write a big program when a little one will do.
• Be familiar with advanced data structures. Advanced data structures aren't appropriate very often, but when you need them, they're indispensable.
• Let the data structure the program. The theme of this column is that data can structure a program by replacing complicated code by a data structure.
• The relations among input, program variables, and output describe the "state" of a program; assertions allow a programmer to enunciate those relations precisely.
• To verify a subroutine, we first state its purpose by two assertions. Its precondition is the state that must be true before it is called, and its post-condition is what the routine will guarantee on termination.
• The output of any calculation is only as goo d as its input.
• Everything should be made as simple as possible, but no simpler.
• The most important principle about code tuning is that it should be done rarely.
• When efficiency is important, the first step is to profile the system to find out where it spends its time.
• Simplicity can yield functionality, robustness, speed and space.
• The space required to store a given object can be dramatically reduced if we don't store it but rather recompute it whenever it is needed.
• Replacing a data structure can drastically reduce the space required to store given information.
• How should you sort a sequence of records into order? The answer is usually straightforward: use a sort command provided by the system.
• One part of a programmer's job is solving today's problem. Another, and perhaps more important, part of the job is to prepare for solving tomorrow's problems. Sometimes that preparation involve taking classes or studying books like Knuth's. More often, though, we programmers learn by the simple mental exercise of asking how we might have solved a problem differently.
• Good engineers distinguish between what a component does (the abstraction seen by the user) and how it does it (the implementation inside the black box).
• Before you build a fancy program, let potential users experiment with a simple prototype on many real inputs.
• A well-built system is divided into independent components, each of which does one thing well.
• The best design is usually the simplest.