I find developers to be fascinating people with a lot of potential and a passion to solve problems, but because of the type of technology they use, they require deep concentration states to complete their tasks. As a result, it can be challenging for managers and non-technical colleagues to communicate with them.
This post's main goal is to shed some light on how developers’ minds work in order to make it easier to work and live among us.
This article is suggested for both colleagues who find it difficult to communicate with developers and devs who wish to understand better what are the triggers for their different mind states.
I saw numerous disagreements over more than 15 years in the various development teams I worked in as a backend (lead) developer. They caused anger, holdups, burnout, or people to merely change employment as a result of feeling underappreciated and misunderstood.
Different points of view and dysfunctional communication methods were frequently the causes of these disputes. Simply put, it appears that developers occasionally attempt to interact with non-technical coworkers as if the latter were fluent in the languages, frameworks, and architectures they deal with daily.
Additionally, non-technical staff members and managers often communicate with developers without taking into account the intricate mental models that developers must create to address some of the daily problems that businesses confront. This is especially true in the era of distributed systems and microservices architectures, where complexity is omnipresent.
While reading Ted Chian's Exhalation book, I thought I could also (metaphorically) dissect my brain to help others who might be facing similar issues and contribute to healthier working environments!
The Flow state
I've been passionate about finding out how things work for as long as I can remember, from childhood toys, mechanical watches and of course any kind of intricate hardware and software. The curiosity for how things work is one of the reasons why developers are such great problem solvers.
Imagine for a moment we could measure dopamine levels using a tool as straightforward as a thermometer. Developers who are engaged in problem-solving activities would have high dopamine levels! The reward system would make them feel good and seek more problem-solving. Some people call this the Flow state.
The Drop state
Single developers aren’t usually enough to build complex systems, they work in teams. Often these teams also include individuals from other disciplines, like product owners, designers, data scientists, managers, etc.
When planning new features, designers and product owners need input from other team members and when working as a team, developers need to communicate and coordinate their technical designs so that all of them can work on the different parts of the problem while following the same blueprints.
The need for communication that comes with working in teams is one of the reasons developers can't spend their entire work days doing what they enjoy most, creating and maintaining systems or the Flow state.
On the other hand, context switching is the process of shifting between multiple unrelated tasks. The bigger the difference between the tasks, the larger the context switch between them.
Every time a developer immersed in a complex problem-solving task is interrupted, the required context switch ruins the focus.
In my experience, getting interrupted often reduces my capacity to focus on a problem and generates frustration. As a result, I’m less eager to interact and engage with others. Let's call this the developer’s Drop state.
There are, of course, many other complexities and factors in a developer's mind as well as other states than
Drop. I have based my explanation on a limited number of them to reduce the scope of this text to a short blog post.
In the next posts, I’ll provide tips on how developers can maximize their flow state, as well as how managers and non-technical staff may interact with them more productively to minimize the drop states. Stay tuned!