Several Solutions to Alleviate Mental Load Coming from Complexities of Software Engineering
From time to time, I send messages and emails to my teams to remind them of the complexities of our work, and how we can address them strategically so that we can scale up easily without working longer hours. This post is one of them turned into a blog entry.
Engineering software is hard. We deal with lots of moving pieces, and a wide variety of complexities, which includes communication, tools, technologies, organizational and structural elements, and so forth. All these parameters take their toll on our mental energies first. On top of them, there are always new things to learn, which causes us to context switch when we are in the flow of knocking down our tasks. We would want to use our brains for more important things rather than trying to remember a past meeting or repetitive duties or trying to find out how to do things over and over again. As software engineers, we are aware of the realities and hardships of this occupation, and we constantly are exposed to new realities as well as advance in experience level. But, fortunately, there are lots of methods at our disposal to address many of these issues. Some are straightforward, and some are a little complex. But, we have the perseverance to learn and apply them to our daily work. Three things that are especially important for us to deal with this ever-increasing complexity in our job:
- Consistency
- Writing things down. Taking notes.
- Automating repetitive tasks
Consistency
By keeping how we use tools, how we communicate, how we coordinate consistently across the board, we eliminate and/or alleviate the need for excessive context switches, surprises in the middle of our work, and the way we communicate. Some examples for consistency
- Writing clean and idiomatic code
- Establishing merge review process (with checklists, etc.)
- Establishing a consistent way of using our tools like Slack, etc.
- A consistent way of documenting our practices and newly acquired knowledge
Take Notes
And we forget things similar to billions of normal people out there. After we leave our meetings, we go back to our work, and we forget what we talked about among our daily responsibilities, and this is perfectly normal. The simplest and most straightforward solution to that problem is to write things down. Take notes in the meetings, create action items (with what, who, and when), and follow up on them.
Automate
As software engineers, our power comes from automating tasks for our customers, and the same power can perfectly be used for our own tasks. A repetitive task is a perfect candidate for the question “Can we automate it?” We can scale up fast if we automate manual labor as much as possible. I know many of you are already taking notes in meetings and strive for consistency among their practices. But we are a growing team, and I find regular reminders of our cultural practices really crucial. Keep up the great work everyone and remind yourselves and your fellow engineers of the following action items where and when applicable:
Actions Items
- Take meetings notes with action items, and define how the action will be followed up. Action items should have “What is the action, assigned person, and due date, and how it is going to be followed up”. We need this to ease our mental load and remember our past conversations and create value from them.
- Keep processes and practices consistent to eliminate surprises and frustrations. For instance, having an MR/PR questionnaire template for a set of questions and expectations from each MR will provide a consistent experience for both the reviewers and authors. Always ask yourselves “How can we ease our mental load here? How can we make it more straightforward?”
- A repetitive task is a perfect candidate for the question “Can we automate it?”
- We don’t do finders keepers here meaning that just because you find out a problem and mention it to the team, doing the work does not automatically fall onto your laps. Define the work, write it down, split it if necessary, and own it as a team.
As always, please reach out to me if you have any questions or there are things that don’t make sense above.
