Central to designing developer workflows is the idea of “the overhead of context switching”.
In computer science, a “context switch” is the process of switching from executing one process on the CPU to another. This process typically includes saving CPU registers (small capacity, blazing fast memory) which hold the first process’ data to RAM, and then loading the second process’ data from RAM into the registers.
Colloquially, “context switch” is often used as shorthand for “the overhead of context switch”. If it takes 10 milliseconds to perform the context switch, and then the new process runs for 20 milliseconds before the next context switch, the CPU is doing useful work only 2/3 of the time. So the overhead of context switching is 33%. Operating systems attempt to minimize costs of context switching.
The concept of “context switching” extends well into the realm of humans performing tasks, since the brain can roughly be modelled as a CPU. When you “get into” a task, you have a lot of context loaded in your head. If it’s a coding task, you know which files you need to touch, what potential bugs you need to avoid, what the testing requirements are, what the deadline is, etc. If you’re deeply focused, working on a task, and a colleague comes over and asks a question about some other, completely unrelated subject, you may blankly stare at them for a moment, and then say “sorry, can you repeat your question?” — you were so in context of the task at hand, that you didn’t have free brain cycles to even parse their speech.
Eventually you switch your context, have the colleague explain their question, recall all the nuances associated with the subject of the conversation, and give them a meaningful response. They leave, and you are left there, staring at the screen, trying to remember “what was I doing again…?” It takes a while to bring back the mental context and the level of concentration you had before the colleague’s visit. [1]
Now imagine you have colleagues visiting throughout the day, at fifteen minute intervals. All you’ll end up doing is switching from context to context, trying to remember what it is you were trying to do.
Exact costs vary depending on personality, but in general, context switches are expensive. Deep concentration and being “in the flow”, the states in which we do the best, most productive work, are difficult to achieve, so being forced to context switch out of them is that much more expensive.
There are a number of different types of context switches that are worth addressing when designing your own or your teams’ development workflow.
Interruptions
This is the “colleague coming over with a question” example from before. To do good quality work, you need uninterrupted chunks of time to focus and code. Typically it’s difficult to sustain deep focus for more than a couple of hours, so it would be worth your while to batch all interruptions in between these deep focus “sprints”.
Blocks
Nothing kills momentum quite as much as being blocked on another person.
If you need an answer to a question to unblock your coding, and the person able to provide the answer is at the time not available, you may want to employ some hacks to conserve your momentum, instead of losing it. For example, you can switch to some code cleanup or small refactoring work while waiting. You can also make a reasonable assumption about the answer, and continue coding based on that. Or you can continue coding parts of the system that do not depend on the answer while you’re waiting. Momentum is hard to build, so it’s worth your effort to preserve it when you do have it.
One special case of being blocked on people is waiting for code reviews. Finishing a change set and submitting the pull request for code review is typically a high-momentum point. This is somewhat paradoxical — you’ve just finished a chunk of work, so you should be tired, shouldn’t you? On the contrary, I often find that having the “clean slate” feeling generates momentum. At this moment, when the PR is submitted, yet you still feel high forward momentum, it’s a great time to start on the next feature set, and thus avoid the activation energy that’s typically required when starting a new task “cold”. This is why it helps to get your code reviews done quickly, ideally as soon as you submit them. They let you capitalize on this remaining momentum. On the other hand if the code review takes hours, or days, you’ll be tempted to kind of coast around, doing little or nothing, waiting for the review comments, not quite done, not quite ready to move forward, but already completely depleted of momentum.
Toolchain Delays
The “silent killers” of momentum are the delays of the toolchain.
The “edit-save-reload” cycle is the unit of workflow in which you make a code change, save the file, and see the change in action either via your app’s UI or via a unit test. The “edit-save-reload delay” is the duration of time between saving and being able to see the result of your change. This is the time when compilers, packaging scripts, browser reload hooks, etc run.
When the edit-save-reload delay is, say, 3 seconds, chances are you’ll hit save, and just stare at the screen for 3 seconds. It’s a short enough amount of time to have no effect on your momentum.
But consider what happens when the delay grows. Five seconds? You start twirling your thumbs. Ten seconds? Your mind starts wandering. What’s for lunch? What’s on TV tonight? Fifteen seconds? It’s over. You switch over to your browser, and open a new tab — news, Facebook, YouTube, whatever. The delay forced you to make a context switch, and a very sneaky one at that. The switch out of your work context was cheap, because the mental overhead of consuming media is low. And you’re guaranteed to be stuck consuming media for much longer than your edit-save-reload delay is. By the time you’re back, your momentum is severely decreased, and switching back into the work task is a drag.
Over time, high toolchain delays generate a sort of apathy that seriously degrades productivity.
Fixing toolchain delays has high ROI, but is paradoxically difficult to convince yourself to spend time on. This is probably because humans are highly adaptable, and get used to ignoring small inconveniences quickly, irrespective of the huge damage they can be dealing to productivity.
For all these reasons, lowering delays below critical thresholds and eliminating or cleverly avoiding blockages has extremely high ROI.
Momentum-generating work
When the main task you’re supposed to be working on feels like an uphill battle, and momentum is low, it may make sense to put that work on hold, and instead work on something light and straightforward, that will generate momentum and energize you. Some light refactoring, code cleanup, or a small big fix or feature are often great momentum-generating tasks.
Side-effect
Once you’ve tweaked and tuned your workflow for generation and conservation of momentum, eliminated most delays, waiting in people, organizational overhead, you may discover something surprising.
You can’t actually productively work for 8 hours a day. At least not sustainably over a long stretch of time.
The exact number of possible productive hours varies person-to-person, but the underlying pattern is the same. With a default workflow, all the delays and organizational/communication overhead adds up to a significant amount of downtime. During downtime, your brain rests. So when you eliminate the downtime, you are also inadvertently removing the chance for your brain to rest. And without this unrecognized background brain rest time, you’ll find the expenditure of willpower to force yourself into the next coding sprint is pretty high. The good news is that you gain the ability to have it rest in the way you find most effective, at the time of your choosing.
Super-weapon
Let me share a setup I consider my super-weapon. I use it when I need extreme level of focus to push through a bunch of coding in a short span of time.
Essentially, I turn off email/chat, put on some upbeat music at a larger than normal volume, and replace my office chair with a balance ball.
I discovered this by accident, and only later analyzed why it works as well as it does. The balance ball makes it easy to bounce up and down to the rhythm of the upbeat music, which in turn creates a great typing rhythm. But the real difference happens when toolchain delay inevitably kicks in. Without this setup, it’s easy for focus to start drifting as you’re waiting for the recompile or whatnot. But with this setup, the music and the bouncing keep you right where you were, right on that same rhythm, so you lose no focus, and when the recompile is done, you’re ready to get right back into active development.
Obviously your milage my vary, but for me, this setup works wonders. I also cannot sustain this level of focus for more than a few hours, it’s just too intense. But in those few hours, I can get a couple days’ worth of work done. I’ve never played a musical instrument with any competence, but I’m pretty sure the way I feel when coding in “super-weapon” mode is the way musicians feel during a concert that is going well. Interestingly, after getting into the zone, the type of music doesn’t seem to make a difference — some mellow Bach sustains the flow as well as high paced J-rock, heavy metal, pop, Astor Piazzolla or the Gypsy Kings.
Amazing performance aside, the balance ball will likely do wonders to your posture in the long term.
Next: Troubleshooting and Analysis Things ⇒
[1] It is also this idea of “context” and “being in context” that is responsible for the biggest culprit of all miscommunication, What Is Obvious To You Is Obvious To You. When you’re engrossed in a task, and suddenly have a question about some internal detail, chances are when you ask your coworker the question, they won’t have the full picture of what you’re talking about. This is likely because, being engrossed in the task, you didn’t slow down and think “okay, I’m deep in this task, and have all this mental context established, but when I ask my colleague for help, they would be working on some unrelated task, so I’ll need to spend some time explaining the context before I can even ask the question”.
Comments
Post a Comment