Perhaps the most important idea that software designers and programmers must understand is the abstraction barrier.

Every piece of software has, or should have, an abstraction barrier that divides the world into two parts: clients and implementors. The clients are those who use the software. The implementors are those who build it.

The clients don't need to know how the software works. To do their job, they have to trust the software.

The implementors do need to know how the software works. Part of their job is to distrust it. As an implementor, you should always assume there are bugs in the software you're implementing, and you should search for them diligently through testing, walkthroughs, and formal verification.

Whether you should trust or distrust a piece of software depends on whether you are a client or an implementor of it. For every piece of software, therefore, it is important to know which side of the abstraction barrier you are on. Are you a client or an implementor?

This is much more confusing than it sounds. When you implement software, you are also using other software, so you are an implementor of some software but a client of other software. What's more, you often use software you implemented yourself. You are a client when you use it, but an implementor when you implement it. Since programmers often switch back and forth between different parts of a program they are writing, they have to be able to switch from client to implementor and back to client in a matter of seconds.

Psychologically speaking, this is very difficult. The ability to switch back and forth between these two completely different modes of thinking is one of the things that separates the really good programmers from the average and not-so-good.