How to be interruptible?
One of the biggest problems to solve when a developer have lead responsibilities is to find time to develop (if you want to develop). Time…
One of the biggest problems to solve when a developer have lead responsibilities is to find time to develop (if you want to develop). Time management is critical, for sure, but you need to find a way to be interruptible.
I think we have been taught to finish everything that we start and do it by ourselves. I see a pattern in software engineers, when they have an issue they prefer to continue with that issue to be them the ones that solve it. It’s a kind of proud, you were able to fix it.
Everyone agrees with this because that person has been working in that problem, our driver understood the problem and defined a solution for it. We think that the next person is not going to be able to continue with the code created by our driver. This introduces a question, is there a way to work so other one can continue with low effort with the things I did?
Time and flow
Carlson’s law, also called the “Law of homogeneous sequences,” states that interrupted work will be less effective and will take more time than if completed in a continuous manner.
https://www.paretoanalysis.tools/carlsons-law-1-simple-yet-powerful-idea/
Following that definition, the first thing that you need is continuous-time, if we have several meetings and some mins between them is hard to use that time to develop. We could consider that time as a waste of time.
We are very bad at recovering from a context switch, so it’s a waste of time having a lot of context switching during the day.
One way to manage this is to defrag your calendar, this is basically to put similar tasks that you have to do in your calendar together and try to have continuous enough time to develop every day.
I try for example to block time to develop in my calendar every day and push meetings at the end or the beginning of those blocks.
Focus time
Focus is not given just because you have time to develop, your chat tools are there to warn you about things that happen. Being very focused on what others need makes you lose your focus on the task that you want to achieve.
One tool that focuses you a lot in a development task is pair programming, you are with another dev working on something, this is focusing you.
Sometimes those things in your chat are urgent, to balance flow with urgent tasks you can use the Pomodoro Technique.
We will use a timer of 25 mins (you can change it) to work just in one thing, this is the focus part, after that time you will have a rest of 5 mins, you can use that time to check if you have some chats asking for you. After four pomodoros, the break will be 10–15 mins.
A signal of too much context switching is when you stop answering people that ask you something by chat or email. We usually think that we will do it later, but we will forget it. Those 5–10–15 mins of break are good times to answer that person. There is no need to solve the thing, just annotate what they want from you in a to-do list and answer him that you will take a look. Get-things-done is a great framework to manage these requirements.
Another one is the two minutes rule s if you have to do a task that lasts less than two minutes do it right now, if not put it in your backlog.
Apart for emergencies, no one is expecting to have a solution for something after the question is raised in the first five minutes. Not everything is an emergency, so we need to limit that, urgent is different from important.
Defining what is urgent for everyone is a great exercise and helps you to move all the urgent things to a specific channel that needs to be checked frequently. In general, urgent means something that needs to be done now because consequences are so high in the next five minutes that we cannot wait. Something different from that is not urgent, so the channel should not be used. We are doing it very badly if the urgent channel is full of things.
If we are in an environment when the emergency chat needs to be answered very quickly, one way to focus others is to sacrifice one person or pair to check that channel and answer the people. This will help us to focus the rest of the team, this is the bat-person (bat person and robin for a pair). The bat-person is in charge of emergencies (bat-signal) and will have low priority things to do. Majority of time the bat-person will not be in emergencies, so we can use their time to fix our tech-debt. To avoid burning down the bat-person the role needs to rotate inside the team.
Ways of working
It’s true that you need a kind of flow to solve problems, but it’s also true that we usually define solutions in big-bang mode. Or we solve everything or nothing is done, so it’s very difficult to rotate with the responsibility of that specific task.
One way to mitigate this non-interruptible mode is to do smaller things, to solve smaller complete problems. Things that are useful for the user but are not covering all the possible scenarios.
We can do this at several levels, at user story level with vertical slicing. Smaller user stories is the way to accomplish with the Parkinson’s law, but in your own benefit.
At development level, we can also follow this principle, using small steps.
If we develop in a way that we commit small things very frequently and that commit solves a small user problem, we will be able to stop at each of those small cycles (TDD will help you a lot here).
CI/CD, TDD can help you to support this behavior and maintain the quality of your code. If you automatize to the maximum the deployment process, you gain time to do other more important things. Machines are good to do repetitive tasks people are good to think in better approaches.
Delegation and rest
Delegation is key to find time to develop, there are more people in the team so use them to solve the problems of your team. We don’t have to be heroes.
One hundred percent of utilization of any system causes the system to be dysfunctional because of the load.
Illich’s Law or “Law of Diminishing Returns” suggests that optimal productivity is reached with an appropriate balance between working time and resting time as productivity decreases after a certain period of continuous work. In short, relevant breaks are essential to staying productive.
https://www.paretoanalysis.tools/illichs-law-or-law-of-diminishing-returns/
Another great and very simple tool to gain time is saying no to people.
As a summary don’t accept that you cannot develop anymore, just try to change things to be interruptible.