The Four Eyes Principle is one of those concepts that, once you have a label for it, you start noticing it everywhere.

I first encountered the four eyes principle before I even knew what it was called. At the time, we knew that code review was something we should be doing, and we were attempting our version of it. However, it wasn’t until we ran into trouble managing a sensitive file—a big production secrets file we couldn’t check into source control—that the principle became real to us.

The incidents started piling up: syntax errors that prevented the file from parsing, forgotten secrets, sequencing mix-ups (should the secret or the code come first?). The list went on. Frustrated, we reached out to someone with ~~more~~ experience and asked for guidance. “The Four Eyes Principle!” they proclaimed, almost as if it were the most obvious solution.

What

The Four Eyes Principle is an approval process where at least two people (hence, "four eyes") review something before it moves forward. Yes, it’s as simple as it sounds—and maybe a little underwhelming.

Effect

The assumed effect of review is with someone else involved we're more likely to catch mistakes. That's true to an extent, the caveat is we're likely to catch foreseeable or recognisable mistakes. Some issues come about because of unexpected interactions between components in the system, whilst a second set of eyes might increase the chance of catching these type of issues it's not guaranteed.

Making review an event can bring about an attitude of seriousness which can work to counter carelessness if it has crept in. When performing something by yourself the attitude you bring towards it is, for the most part, your own attitude. With a second set of eyes there's a certain gravity implied, maybe they ask questions or perhaps you feel the need to set a good example. This subtle shift in attitude can change the way we treat something, for the better.

Building in an expectation of review encourages that no person is alone when changing a system important enough to warrant the practice. Introducing other people into the mix brings about a necessity to make a system understood or better yet understandable. The process of making the change gets refined over time, with more eyes on it they spot opportunities for improvement you might not have. Consequently review becomes more sustainable, eventually it might not be you bringing about the review but instead you're providing it.

How

1. Identify where it’s needed Look at your existing system and how you change it for opportunities. Secrets management, highly depended on components and configuration are good places to start looking.

2. Bring a case Help your team understand the concept and why it's worth the effort in the given area. Details of past issues could help the team understand the case for review.

3. Establish expectations early Figure out what good reviews look like. What should reviewers focus on? How can they add value? Set a collaborative tone from the start by doing this together.

4. Iterate and improve Treat the review process as a living practice. Keep an eye out for friction or inefficiencies and refine the process over time.

The objective is to push as much of this into system primitives, guardrails and automation as possible, but pragmatically that’s a moving target and not always possible when it's needed. Don't operate your system irresponsibly because you're waiting for the time and space to "do it properly".