Here’s a hot take: disrupting coders isn’t all that bad.
Some disruptions are certainly bad but they usually aren’t. The coder community has overblown the impact. A disruption can be a good thing. How harmful disruption might be a symptom of other problems.
There are different kinds of disruptions. They are caused by other coders on your team, managers and other non-coders, or meetings throughout the day.
The easiest example to debunk is a question from a fellow developer. Imagine someone walks over to your desk or they ping you on Slack, because they have “one quick question.” Do you get annoyed at the interruption when you were in the middle of something important? You help out your teammate quickly and get back to work, trying to pick up where you left off. That’s a kind of interruption we complain about frequently, but I’m not convinced this is all that bad.
You are being disrupted but your team, of which you are only one member of the whole unit, is working smoothly. You unstuck another member of your team who may have lost more time without your advice. You can’t consider only your own time. If the disruption does cost you, it is weighed against your teammate.
When a junior developer disrupts you with a question your support of them is important. They can spend more time stuck than you’d spend to help. Consider how much time you’re actually saving by being interrupted if you include others’ time in that equation. This can lead to a long-term boost for the whole team as they learn from you and others.
In either case you should trust your teammates.
The most common disruption complaint is the “hapless manager” walking over to the in-the-zone programmer for a question. Developers think this yanks her out of a productive state of mind that’s hard to get back to. Do five minute interruptions really cost an hour of productivity? Does it take a long time to get back into a state of mind where you’re productive?
There is an often smug animosity towards non-coders who don’t understand what making software is like. They interrupt us, we like to say, because they don’t understand how a programmer’s mind works. This attitude inflates our perspective of what that interruption costs.
But, our managers want us to work well. Any good manager’s job is to support you in your work. We can communicate when real focus is necessary, but don’t be antagonistic about it. Everyone understands context switching, so include this when discussing schedules and allocation. It should be a part of the process to support the focus you need. Like the developers on your team, your manager needs your attention sometimes. Remember to think about the time of the whole team and project.
Don’t think only about your own time.
Remember that the actual act of writing code is only a part of our job. Collaborating with our team and coordinating with our clients and company are just as important. Disruptions from outside the technical team are not taking you away from your work. Those interactions are the work, too!
Interruptions can be irritating but they can also do more good than harm in a cooperating team.
And, sometimes an interruption actually helps you.
Those deep states of mind focused on a problem can feel like an important key to cracking a really hard problem. You just need to dig into the depths of the codebase for three hours to figure out how to solve those really thorny bugs, right? Those deep dives can be fraught with false tunnels and misconceptions along the way. An occasional reset can help a lot! A little interruption of your train of thought means you can look again with fresh eyes.
Opportunities in your work day to take a break from a problem and come back to it later are great. It can be good to have something to take you away from your desk. The truth is that “zone” we’re often in can just as likely see us stuck as it can see us through to a solution. Whether it’s taking a break to attend a meeting or juggling a few projects, something to redirect yourself to gives context switches that can be very helpful. Give developers some options for how to spend their time and give them reasons to break up their day.
A specific interruption can be frustrating but they are not inherently costly to a project. Pay attention to the balance, of course. You have to have a team you can trust, both among technical and non-technical members, too.
So, the next time you gripe about being pulled away from coding, think a little closer about it. Are you putting your team ahead of yourself? Are you giving yourself the breaks you need? Good teams give developers time to focus, but good developers give their teams their attention in return.
Some disruptions are certainly bad but they usually aren’t. The coder community has overblown the impact. A disruption can be a good thing. How harmful disruption might be a symptom of other problems.
There are different kinds of disruptions. They are caused by other coders on your team, managers and other non-coders, or meetings throughout the day.
The easiest example to debunk is a question from a fellow developer. Imagine someone walks over to your desk or they ping you on Slack, because they have “one quick question.” Do you get annoyed at the interruption when you were in the middle of something important? You help out your teammate quickly and get back to work, trying to pick up where you left off. That’s a kind of interruption we complain about frequently, but I’m not convinced this is all that bad.
You are being disrupted but your team, of which you are only one member of the whole unit, is working smoothly. You unstuck another member of your team who may have lost more time without your advice. You can’t consider only your own time. If the disruption does cost you, it is weighed against your teammate.
When a junior developer disrupts you with a question your support of them is important. They can spend more time stuck than you’d spend to help. Consider how much time you’re actually saving by being interrupted if you include others’ time in that equation. This can lead to a long-term boost for the whole team as they learn from you and others.
In either case you should trust your teammates.
The most common disruption complaint is the “hapless manager” walking over to the in-the-zone programmer for a question. Developers think this yanks her out of a productive state of mind that’s hard to get back to. Do five minute interruptions really cost an hour of productivity? Does it take a long time to get back into a state of mind where you’re productive?
There is an often smug animosity towards non-coders who don’t understand what making software is like. They interrupt us, we like to say, because they don’t understand how a programmer’s mind works. This attitude inflates our perspective of what that interruption costs.
But, our managers want us to work well. Any good manager’s job is to support you in your work. We can communicate when real focus is necessary, but don’t be antagonistic about it. Everyone understands context switching, so include this when discussing schedules and allocation. It should be a part of the process to support the focus you need. Like the developers on your team, your manager needs your attention sometimes. Remember to think about the time of the whole team and project.
Don’t think only about your own time.
Remember that the actual act of writing code is only a part of our job. Collaborating with our team and coordinating with our clients and company are just as important. Disruptions from outside the technical team are not taking you away from your work. Those interactions are the work, too!
Interruptions can be irritating but they can also do more good than harm in a cooperating team.
And, sometimes an interruption actually helps you.
Those deep states of mind focused on a problem can feel like an important key to cracking a really hard problem. You just need to dig into the depths of the codebase for three hours to figure out how to solve those really thorny bugs, right? Those deep dives can be fraught with false tunnels and misconceptions along the way. An occasional reset can help a lot! A little interruption of your train of thought means you can look again with fresh eyes.
Opportunities in your work day to take a break from a problem and come back to it later are great. It can be good to have something to take you away from your desk. The truth is that “zone” we’re often in can just as likely see us stuck as it can see us through to a solution. Whether it’s taking a break to attend a meeting or juggling a few projects, something to redirect yourself to gives context switches that can be very helpful. Give developers some options for how to spend their time and give them reasons to break up their day.
A specific interruption can be frustrating but they are not inherently costly to a project. Pay attention to the balance, of course. You have to have a team you can trust, both among technical and non-technical members, too.
So, the next time you gripe about being pulled away from coding, think a little closer about it. Are you putting your team ahead of yourself? Are you giving yourself the breaks you need? Good teams give developers time to focus, but good developers give their teams their attention in return.
Comments