By Derek Lee Boire, Senior Member of Technical Staff at VMware Pivotal Labs
If you’re a developer, whether you realize it or not, you’ve probably experienced ‘decision fatigue’ at one point in your career. Decision fatigue occurs when the quality of the decisions we make deteriorates due to the mental fatigue of having already made a lot of decisions. While some people may want to believe that they have infinite willpower, our mental energy and focus has a limit. You can train long, or you can train hard – either way your body will tire eventually.
Just as we can train our bodies to endure additional stress, we can also train our minds to increase our focus. Here we look at some of the ways in which decision fatigue and other frustrations that can manifest in software development, and the tools and methods that can be employed to combat them.
If there is a task that must be performed many times, or takes a long time to do manually, or is complicated and error-prone, developers should consider using automation, one example of which being continuous integration and continuous delivery (CI/CD).
When you automate a process, you don’t just make it easier to execute, save time and ensure consistency – you also make it discoverable. This means that if a new member joins the team and has never worked with CI/CD before, reviewing the script that manages this automated process will help them to easily understand how the application is deployed. As software engineers, we are all authors. As such, we need to consider the audience who is consuming the code that we are writing.
When working independently, it can be easy to find yourself lost down a “rabbit hole” – deep into trying to solve a problem and unable to remember where you had started or why you went down this route in the first place. Developers working in isolation are particularly prone to finding themselves in a rabbit hole, which is a sure-fire sign that decision fatigue is settling in. Collaborative development processes, like pair programming, help developers avoid rabbit holes through creating a culture of fast feedback and knowledge-sharing.
One recommended practice for pair programming is to rotate who pairs with whom daily, to ensure that several different team members have knowledge of how each part of the system works. This is a great way to share knowledge throughout the team, as well as to ensure that the team can always continue to make forward progress, even if a team member is unavailable.
Developers often see an existing pattern and simply copy and paste or tack on more of the same. Whilst the pattern may have been easy to understand when it was initially implemented, repeated use can eventually create a ‘domino’ effect, whereby that same pattern, at scale, may no longer serve the code after it has evolved.
While there are some developers who are strictly against code duplication, it can sometimes actually be helpful. There’s a delicate balance between code duplication and creating a premature abstraction. Sometimes duplication is, in fact, necessary if an abstraction or cleaner way of writing can’t yet be discerned. It can be good to just let the code “simmer” for a bit longer and see how it will evolve.
Culture of growing and sharing knowledge
This is by no means an exhaustive list of all practices for building code which works for everyone. Consistency in the practices deployed (i.e. code style, formatting, automation) is another significant area where many of the major barriers can be overcome. But the first step toward implementing any of the practices described here involves a more widespread, cultural change within the organisation itself.
Developers work best when organisational culture promotes growing and sharing knowledge within the team. Development teams should tie core values like communication, courage and respect to every aspect of the work they do. Doing this will help alleviate common barriers faced by developers to writing great software, whilst also contributing to increase in productivity, quality of work and developer well-being.