Derek Lee Boire, Senior member of Technical Staff at VMware Pivotal Labs, highlights how pair programming can combat decision fatigue
Coding for at least eight hours a day, programmers are constantly faced with the need to make decisions. This can become exhausting. Today’s full-stack engineer could be dealing with different aspects of technology simultaneously. This could include using DevOps skills to orchestrate a continuous integration (CI) and continuous delivery (CD) pipeline, or programming in different languages, depending on the client and server technologies being used. Some may also be working in programming languages, such as object-oriented or functional programming, which have varying paradigms.
With each task comes a different set of questions. Do we start to build this feature from the outside (user interface, or front end) and work our way in (towards the back end), or do we work from the inside out? Do we use a third-party library to implement this feature or do we write the code ourselves? How should we refactor this code? How do we automate this process? The list of questions goes on.
With this endless need to make decisions, and hours on end of coding, developers may find themselves leaning towards the option that presents the least amount of friction. They may also end up looking at certain aspects of a decision in a limited way, or maybe even avoid making a choice entirely. This is referred to as decision fatigue. If not tackled early, it can lead to the phenomenon of ‘spaghetti code’ – code that is difficult to follow and understand, and can later become impossible to untangle.
Can decision fatigue be avoided?
There is really no avoiding decision fatigue – but we can put our efforts towards making the best use of our mental energy. This is where programming in pairs becomes very helpful. Pair programming helps by sharing the load of decision making between two people. Proactive communication within the pair and within a team can help everyone to get on the same page.
Regardless of how the decision goes, pair programming is one of the many ways that engineers can get immediate, real-time feedback on the code that they are writing. This is in stark contrast to performing a code review where the reviewer doesn’t always have access to the thought process that went into writing the code. This is similar to seeing a finished video on YouTube, an artist’s performance, or a published book – consumers don’t have visibility into the process that contributed to the final product.
Pair programming ideally leads to less decision fatigue as both members of the pair can work together to support each other, make higher quality decisions, and come to those conclusions quicker than by oneself.
In some cases, the duo may encounter situations where they feel it would be better to involve the entire team. In this case, they can gather all of the engineers together to discuss different topics such as how to design a solution to a specific technical challenge, ensuring consistency with code style, or any other topics that would benefit from communicating with everyone in the group. The diversity of skills, backgrounds, and experiences that a team brings ensures robust solutions to any recurring problems. It is also very important for the pair to remind each other to take breaks – especially when one of them is too engrossed in their work to remember!
Has remote working during this pandemic led to an increase in decision fatigue?
Ideally, working remotely while pair programming should not have a negative impact on decision fatigue – assuming that both members of the pair are actively communicating and engaged in the work that is being done. Regardless of pair programming or not, the reality is that working remotely itself can be challenging for a number of reasons, and when people are not actively engaged in pairing when working in person or remotely, then teams may see an increase in decision fatigue and lose the benefits of pairing.
Many people tout the benefits of remote work, and certainly there are a lot of them: flexibility, no commute, comfort of working from home, and so forth. However, without a proper working environment and equipment, working from home can be difficult or uncomfortable for many. In particular it can be difficult for people to get their mind off work and can also inhibit the ability to build relationships within teams. These opportunities are either completely lost when working remotely, or they take a lot more effort to create.
This is where the values of extreme programming (XP) become increasingly relevant: communication, feedback, simplicity, courage, and respect. Working remotely makes practicing these values more difficult, as it limits the ability to interact with your teammates compared to in-person interactions. Therefore, it’s even more important that team members consciously consider these values when interacting with teammates.
As many continue to work remotely, my advice to other developers would be to preserve mental energy for decisions that really matter – such as how to design or test a new feature, or how to refactor an existing feature – and expend less energy on less important decisions that engineers are faced with daily. Some processes can also be automated, so engineers don’t even have to worry about the overhead of re-making decisions. Automation can be something simple as consistent code formatting, or it can be something more complicated like writing a script for a repetitive task. Automation codifies decisions so they don’t have to be made a second time, ensuring that the processes are executed consistently, and makes them discoverable by other members of your team.
Decision fatigue is an issue faced by all engineers across the board. However, by ensuring regular communication and mindful working, this issue can be overcome. This allows developers to express themselves articulately in beautiful code – avoiding the alternate of cryptic and brittle spaghetti code.
