Derek Lee Boire, Principal Software Engineer at VMware Tanzu, highlights how pair programming can combat decision fatigue
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 that have different paradigms, such as object-oriented or functional programming. In some cases, this could lead to coding for eight hours a day, leaving programmers constantly faced with the need to make decisions.
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? Do we refactor this code? If so, how do we refactor it? The list of questions goes on – which can all become exhausting.
With this endless need to make decisions, and hours on end of coding, developers may find themselves leaning towards the option that requires the least amount of effort. They may also end up looking at certain aspects of a decision in a very limited way, or maybe even avoid making a choice entirely. This is referred to as “decision fatigue”. If not tackled early, such it can lead to the phenomenon of ‘spaghetti code’ – code that is difficult to follow and understand, and can later become impossible to untangle.
Avoiding decision fatigue
There is no avoiding decision fatigue – there’s only making the best use of 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 or an artist’s performance or a finished book – viewers 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. They can gather all of the engineers together to discuss different topics such as how to solve a specific technical problem, getting consistency with code style, or any other topics that would benefit the group. The diversity of skills, backgrounds and experiences that a team brings ensures robust solutions to any recurring problems.
Remote working during the pandemic
Ideally, remote pair programming should not have a positive or negative impact on decision fatigue – assuming that both members of the pair are actively communicating and engaged in the work that is being done. However, the reality is that working remotely can be detrimental for a number of reasons, and when people are not actively engaged in pairing when working 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 and the comfort of working from home. However, without a proper working environment and equipment, working from home can be difficult or uncomfortable for some. 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 programming become increasingly relevant: communication, feedback, simplicity and respect. Remote pair programming makes practicing these values more difficult, as it limits the ability to interact 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 one – and expend less energy on less important decisions that engineers are faced with daily. These minor decisions, although equally important, could include matters of code style and formatting. These decisions can also be automated, so engineers don’t even have to worry about making them. Automation can be something simple like automatic code formatting, or it can be something more complicated like writing a script for a repetitious task.
Decision fatigue is an issue faced by developers and engineers across the board. However, by ensuring regular communication and mindful working, this issue can be overcome, allowing developers to express themselves articulately in beautiful code – avoiding siloed or spaghetti code.