Familiarity is a lovely feeling. It's a feeling of comfort where you know what's happening because you've seen it before. This is the feeling we should hope to instill in all maintainers that may come across our code.

Imagine for a moment that you are a skilled mechanic. You open the hood of an old car. You expect all of the various components to be visible in their respective places. You are adept at recognizing specific components, and, even without having to move things about, you can see how components are linked together.

Some minor modifications have been made; maybe the owner has previously installed a turbocharged engine or modified the gear ratios, but overall, you see that everything is more or less where it should be. For you, the mechanic, making changes is going to be nice and simple:

In this example, everything under the hood is in its expected and designated location. Even though cars vary in many ways, their underlying functionality is the same, and so it makes sense that the layout and design are familiar to the mechanic.

When we think about it, software is not so dissimilar. Most software we end up creating is similar to other software in many ways. Most web applications, for example, will have a way for users to register, to login, and change their name. Most software, regardless of the problem domain, will have the concept of creation, read, update, and delete (CRUD). These make up the famous verbs of persistent storage. Most software can be thought of as fancy middleware sitting atop persistent storage. So, even though we may consider all software applications to be quite different, their fundamentals are usually very similar. It should, therefore, not be so difficult for us to write code that caters to the mechanic who opens the hood.

To make the mechanic's work as simple as possible, we need to focus foremost on the familiarity of our code. It's not simple to do this because different things are familiar to different people, but, on the whole, we can take heed from the following guides:

• Don't stray too far from common design patterns
• Be consistent with syntax and presentation
• Lend clarity to unfamiliar problem domains

The last point alludes to unfamiliar problem domains. This is something that you, as the programmer, will have to think about when it comes to each code base you work on. To discern if something can be considered unfamiliar, you can ask yourself: Would another programmer working within another industry be able to understand this with little introduction?