Column: Software
Address decision fatigue – before it turns into spaghetti code
By Derek Lee Boire, Principal Software Engineer, VMware Tanzu T
oday’s full-stack engineer could be dealing with different aspects of technology simultaneously. Tis 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-orientated or functional programming. Tis could easily lead to coding for eight hours a day, with 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 re-factor this code? If so, how do we re-factor it? Te 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 toward the option that requires the least amount of effort. Tey may also end up looking at certain aspects of a decision in a very limited way, or maybe even avoid making a choice entirely. Tis 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 Tere is no avoiding decision fatigue – there’s only making the best use of mental energy. Tis 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. Tis 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. Tis is similar to seeing a video on YouTube, 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, since both members of the pair can work together to support each other, make higher quality decisions and come to those conclusions quicker than individually. In some cases, the duo may encounter
situations where they feel it would be better to involve the entire team. Tey can gather the whole team of engineers 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. Te diversity of skills, backgrounds and experiences that a team brings ensures robust solutions to any recurring problems.
Remote working in 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 like the benefits of remote
working, and certainly there are many: 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 may even inhibit the ability to build relationships within teams. Tese opportunities are either completely lost when working remotely, or take a lot more effort to create. Tis is where the values of programming
become increasingly relevant: communication, feedback and simplicity. Remote pair programming makes practicing these values more difficult, as it limits the ability to interact compared to in-person interactions. Terefore, 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 re-factor an existing one – and expend less energy on less important decisions that engineers are faced with daily. Tese minor decisions, although equally important, could include matters of code style and formatting. Tese 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 repetitive task. Decision fatigue is an issue faced by
developers and engineers across the board. However, by ensuring regular communication and mindful working, it can be overcome, allowing developers to express themselves articulately in beautiful code – and avoiding any siloed or spaghetti code.
www.electronicsworld.co.uk February 2021 21
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44
