I dare you to code like a Spaghetti Monster
In today’s world, we as developers have to work at a high level of abstraction and make important decisions at every step in our daily work. Deciding repeatedly can be exhausting. Being a coder means also dealing with various aspects and processes of software development continuously. Sometimes simultaneously. Whether it’s integrating DevOps approaches to orchestrate a CI/CD pipeline or programming in different languages depending on the client and server technologies being used.
Every step lets developers face new fundamental questions. Is it wise to start with the frontend development? Or do we better start with the backend? Could we also start from the center and work towards the outer sides? Are we using libraries to implement a feature or do we code it ourselves? How do we architect or refactor the code? Which processes can we automate the best?
Complex requirements paired with the stated questions coupled with hours of coding will strain the ability to concentrate. Leading to the fact of deciding becomes increasingly difficult. At least to make the right decisions. I bet you’ve experienced such a scenario in your life as a coder already. What comes also next? Right, intuitive avoidance strategies take over. That means the developers skip aspects of decision-making. Resulting in taking the least resistant one or even avoid the decision entirely. We know this phenomenon as Decision Fatigue.
If you don’t address this in time, it inevitably leads to spaghetti code. And we all sure about spaghetti code being difficult to understand, maintain, and extend even in retrospect.
Pair Programming as a First Aid
Life is all about balance. It won’t be possible to avoid Decision Fatigue completely, but we can lower the risk to a minimum. Therefore, developers should take care to use their mental energy wisely and efficiently.
If you work in a team pair programming will be a good initial solution, because pair programming distributes the burden of decision-making between two people. This means both developers can support each other and reach conclusions and make therefore better decisions together. They can watch each other, not overstress themselves. Meaning to watch about the workload and remind the partner to take a break from time to time. This leads to less fatigue.
A major benefit of pair programming continues to be that developers receive comprehensive and immediate real-time feedback on the code during the writing process. Errors, suboptimal decisions, or alternative approaches can thus be addressed, discussed, and corrected immediately in the pair.
Compare this with a code review where the reviewer has no direct connection to the thought process that went into writing the code.
In order for the pair to work together smoothly and actually reduce stress and mental strain, rather than possibly increase it, proactive communication between the two developers is critical. Ultimately, this refers not only to the coding pair but to the entire team. Because sometimes, the duo may encounter situations where they think it would be better to involve other team members. For example, this may involve solutions to particular technical challenges or how to ensure consistency with the overarching code style.
One thing: A team always brings a wide variety of skills, backgrounds, and experience to the table which should definitely not go unused in difficult decision-making processes.
Remote Work is Good?
Talking about ideal situations, remote work in pair programming shouldn’t have a negative impact on decision-making. Providing that both members of the pair are actively communicating and engaged in the work being performed. Regardless of pair programming, however, remote work naturally brings with it several challenges that developers have to face additionally. If these prevent them from actively taking part, pair programming also loses its benefits. What follows is an increase in decision fatigue.
We all know the advantages of the home office, flexibility, no commute but also the disadvantages, domestic distractions, need for proper work environment and equipment, more costly communication across the team. To counteract the disadvantages, the values of Extreme Programming (XP) have become increasingly important: communication, feedback, simplicity, courage, and respect.
Working remotely makes it difficult to practice these values because of the limited opportunities to interact with teammates compared to face-to-face interaction. Therefore, it is even more important that team members consciously consider these values when interacting with their colleagues.
Rank It Till You Make It!
In times of Corona, remote work determines the everyday life of numerous developers. To make the best use of their mental energy under these circumstances, it is wise to prioritize. That means spending more energy on decisions that really matter. For example, decide how to design the architecture or to test an additional feature. Spend less energy on less important decisions you face every day.
Whenever it is possible to automate processes, just do it! This eliminates the need to make new decisions every day. We can automate simple tasks like consistent code formatting and complicated ones like writing a script for a repetitive task. Decisions are coded so they don’t have to be made a second time, and the process remains discoverable by other team members. This helps to maintain your ability to make decisions by giving away responsibility to automated processes.
Every decision, may it as little as answering an email directly or later, will drain your energy resources and let you hit the threshold of Decision Fatigue faster. However, through regular communication, mindful work, and the wise use of your mental energy, this problem can be reduced to a minimum. Thus, consistent and correct decisions ultimately shape clean, traceable, and robust code.
Get an Adventurous C# Course and enhance your future by having fun?
Get along with my C# Beginners’ & Advanced course explained by games on Udemy (~2850 Students already taught).