You are assigned to do some bug fix work in a project, and everything is going well. You pick up your favorite coffee from the cafeteria, put your best EDM songs to get into the mood on your wireless headphones, and you can even snap your fingers to feel the vibe coming.
When you finally open your IDE to start working, you get an email notification about the project. It’s better to check out what it is about because this can be important, but it turns out it wasn’t, and it’s ok; the team just carbon copied you misleadingly.
Now it's time to rock; you again start to think about the resolution of the problem. You begin to think about where this bug might be and why it’s not covered with tests. So now you start digging into the code base, checking all the classes and structures when…
A coworker starts a small talk about why the Lakers didn’t win the game yesterday. No problem, just a little chat, and we can come back to the action, but you check your calendar, and you have a meeting in 17 minutes. It’s not enough time to code anything, so you just make some code reviews ( that are super important, don’t play around with your pull requests) and go to the meeting.
This tiny tale says a lot about a developer’s life. We are assigned to do our work, but getting into the flow state isn’t instantaneous. The flow state is where we have the optimum performance and creativity. This state is when your mind is clear, and you can almost feel the universe’s knowledge passing through you. Developers… you know what I mean. It represents the two types of interruptions we need to handle:
the planned and the unplanned ones.
The dark side of interruptions is that they can be something that gradually decreases the developer’s well-being. For instance, when your coding session is interrupted, you could see an increasing number of bugs because of the lack of attention you will be putting into your code. And also a stress increase due to not being able to finish the work you were asked to.
We, developers, tend to check our calendar at the beginning of the day and think: “When can I code today? Oh… the morning is lost because of these two meetings, and in the evening I have another long one. So I have from lunch to the evening to code...". This quick-thinking process explicitly specifies the planned interruption type, where you know that your coding work will be interrupted.
So you have this short timeframe to code the bug fix or do whatever you were assigned to do. Of course, this is precious time, and it should be used as optimally as possible so you can imagine that every interruption is devastating in these hours.
The other types of interruption we told in the tale were the unplanned ones. The unplanned ones can be divided into two categories:
self-made and external sources.
The self-made interruption lies in the fact that we have many notifications, devices, and apps that strive to get our attention in the modern world. These interruptions are the ones you create because you are using apps or software demanding your attention.
Everything nowadays is made to draw our attention and make us spend a lot of time in it. Infinity feeds, push alerts, local notifications, game notifications, and so on. There are so many self-made interruptions that you can quickly lose your day only in the social media feeds.
For the self-made interruption, the solution is to decrease the number of things that can interrupt your work. There are some suggestions around this topic: Managing your pull requests directly from Slack, so you don't need to change tools and keep focus. Slack can be your best friend here, thinking about how to empower it with everything a developer needs to do their job.
For the external interruption sources, you can name everything that is not created or used by you, like: coworkers stopping by your desk to cheap chat, your dog or family while you are doing home office, some cars that are playing loud music outside, or even a blatantly irritating fly in your room.
The external unplanned interruption sources are harder to control;
Here are some tips to improve your well-being as a developer:
All in all, the rule of thumb here is before you even open your favorite IDE, try to visualize (or even draw it on paper) how the problem can be solved and split that solution into small pieces. This simple tip will save you a lot of time having to rethink until the last code thinking process.
And always, and I can’t stress this more; Try to divide your solution into small pieces so you can efficiently finish them even if you were interrupted.
So now you have some strategies to be more productive; it’s time to code! Good luck, have fun
I’m an Italian-Brazilian software engineer with 10+ years of experience developing software for a variety of tech stacks. I’ve being working in back for 7 years as a Java developer but for the last two years I’m love with iOS development. I had some experience in software management being scrum master for two years and loved study software development methodologies, but my real passion is to code. In my free time I like to hang out with my wife, write tech stuff online, read articles and chat about life, universe and everything else.