Column: Software
Common developer frustrations and how to overcome them
I
By Derek Lee Boire, Senior Member of Technical Staff at VMware Pivotal Labs
f you’re a developer, whether you realise 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 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 soſtware development, and the tools and methods that can be employed to combat them.
Discoverability 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. Tis 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 easily understand how the application is deployed. As soſtware engineers, we are all authors. As such, we need to consider those who are using the code that we are writing.
Rabbit holes 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. Tis is a great way to share knowledge among the team, as well as to ensure the team continues to make progress, even when a team member is unavailable.
Domino code Developers oſten 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 aſter it has evolved. While there are some developers who
are strictly against code duplication, it can sometimes be very helpful. Tere’s a delicate balance between code
duplication and creating a premature abstraction. Sometimes duplication is, in fact, necessary if an abstraction or a 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 Tis is by no means an exhaustive list of all practices for building code that works for everyone. Consistency in the practices used (i.e. code style, formatting, automation) is another area where many 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. Doing this will help alleviate common barriers to writing great soſtware, whilst also contributing to increased productivity, quality of work and developer wellbeing.
www.electronicsworld.co.uk September/October 2020 15
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 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68
