Carol - A problem or a blessing???
Conway - ....A problem
Ah as always, Archer provides the perfect foil to real life. Today I'd like to talk about context switches. Context switching is the reason why I'm writing this post instead of writing a Backbone tutorial as I promised in my last post. In Backstep, context switching has me juggling between three different languages, stacks, and sets of issues. Working simultaneously on a Backbone admin app, Django web app, and Android mobile app (with an iOS app soon to come), I feel like a cheater trying to keep his story straight with his various mistresses. It isn't easy. But is it so bad?
First, let's talk about the merits of context switching. For one, context switching can sometimes work wonders when you need to take a step back from a problem. Anyone who's faced down that one monster bug or monolothic feature request knows the feeling when they need to look at something else. Anything else, just so long as it gets them away from the nightmare-inducing monstrosity. In this case, context switching can be super beneficial as it allows one to remain both productive and serves the purpose of evacuation from the volatile section of code.
Context switching can also be useful in the case that you easily get bored working on one thing (I'm a culprit of this). Switching context gives the illusion of working on multiple projects and thus may ease the feeling of stasis one sometimes feels when working for a long time on a single project.
Now, up to this point you might think I'm pro-context switching. I'm not. I've learned the hard way that context switching is detrimental and I'll tell you why.
1. It steers you away from thinking deeply about problems
As programmer's, we're taught that only about 20% of development time should be writing new code. The rest is occupied with writing tests, debugging, and planning. By switching context, one erroneously inflates that number. If you're always writing new code, it gives no time to reflect on the code you've already written, and no time to step back and think about the bigger picture. While at a cursory glance switching context might seem like it would provide the widest lens for examining your project, it in fact provides the narrowest. By switching attention away from planning and into coding, you are opting for the quick fix rather then for a long-term, sustainable solution.
2. Context switching gives you a false sense of progress
When I learned about FDR's New Deal, I was taught that the primary reason it worked was not due to the content of the legislature. Rather, it worked because of the simple fact that people want to feel like they're moving forward. Like they're making progress. We can all relate to this feeling. Take the example of waiting in line at a grocery store. When the line is moving quickly, even if it's a long line, one feels a sense of hope. Now, take a shorter line but one that is moving at a crawl. Most people in that line look something like this:
People in both lines reach the end at the same time, the only difference being that those in the longer line felt like they reached the end quicker.
Now if programming was like waiting in a line and context switching was like being in the longer, faster line, it wouldn't matter if we context switched or not as we would complete the project in the same amount of time as our single-threaded counterparts. Fortunately, programming isn't like waiting in a line. It requires deliberation and thought. But herein lies the danger with context switching. When we switch context we feel like we're moving faster then when we focus on a single segment of code. In reality, however, this notion is misguided and leads to a false sense of progress. Much of this code will later be revealed as buggy, poorly planned, or both.
So next time you think about switching context for the sake of switching context, remember:
- Context switching is just a cheap out for thinking deeply about problems
- By switching context, you might feel like you're moving faster, you're not.