23 Highlights

The problem, I figured, was that there were too many opinions in the world of software and not enough facts.

The difference between a bad programmer and a good programmer is understanding. That is, bad programmers don’t understand what they are doing, and good programmers do.

...the entire reason that we focus on improving code is because improving the code is the most important problem we must solve in order to improve the result.

When we start off, our software systems are small and easy to maintain. But they all grow, in time. The average software system becomes large enough that no human being could hope to hold all of its code in their mind at once. This isn’t good or bad, it’s just a fact.

Programming, in essence, must become the act of reducing complexity to simplicity.

...any given decision must be made by an individual, not by a group of people.

The desirability of any change is directly proportional to the value of the change and inversely proportional to the effort involved in making the change.

The ideal solution — and the only way to guarantee success — is to design your systems such that the effort of maintenance decreases over time, and eventually becomes zero (or as close to it as possible).

The quality level of your design should be proportional to the length of future time in which your system will continue to help people.

The most common and disastrous error that programmers make is predicting something about the future when in fact they cannot know.

The point is, you don’t have to try to predict what will change; you just need to know that things will change.

Code should be designed based on what you know now, not on what you think will happen in the future.

The best design is the one that allows for the most change in the environment with the least change in the software.

It’s important to have evidence of problems before you address them. Otherwise, you might be developing features that don’t solve anybody’s problem, or you might be “fixing” things that aren’t broken.

In any particular system, any piece of information should, ideally, exist only once.

You might notice that the level of complexity doesn’t have to get very high before it becomes frustrating to read other people’s code.

To the developer, the way his program works is obvious, but to others it’s totally unknown.

...the target audience for code is other programmers.

...code is read more often than it is written. So, it’s important to make code easy to read.

Names should be long enough to fully communicate what something is or does without being so long that they become hard to read.

The real purpose of comments is to explain why you did something, when the reason isn’t obvious.

Handling a big failure gets you a lot of thanks, but preventing one from ever happening...well, nobody’s likely to notice.

Users are happiest with a focused, simple product that never violates its basic purpose.