Is it inefficient to frequently switch contexts among multiple projects?
- Juggling multiple projects is the norm
- Context-switching reduces productivity
- Switching contexts can inject new interest
- Repeating ramp up time is where context-switching becomes inefficient
- Mentally resetting your knowledge can give you a fresh perspective
- Conclusion
Juggling multiple projects is the norm
It seems that nearly every job description for technical writing mentions that the writer will need to “juggle multiple projects.” And it’s true. The nature of technical writing is that you are rarely dedicated to a single project. Most of the time, you are only needed near releases, so you end up switching among multiple projects depending upon which project needs documentation the most.
For example, right now I’m documenting three separate products. Usually their release cycles don’t all crest at the same time, so I bounce from project to project based on their pace of development. I’ve always had several projects going at once, and I’ve accepted this as part of the nature of technical writing.
Context-switching reduces productivity
If I had my way, I’d become fully dedicated to a single project. I feel like just when I’m getting my momentum going with one project, really learning it inside and out, connecting with all kinds of team members, and making a lot of progress in understanding the deeper technology of the product, I have to switch contexts and focus on documentation for another product.
Then when I get momentum going with that product, it’s time to switch to another project, and so on.
It’s kind of like watching a TV show. You get a few episodes into a TV series and really start liking the characters and plot. You start understanding exactly what’s going on (unless you’re watching True Detective), you get hooked, and then bam, it’s time to switch series.
You switch to some other series and have to get used to new characters, a new plot, and other details. Then after 4 episodes you’re hooked. You’re totally binge-watching the show and are even predicting things about the plot. You know the names of all the characters, their histories and internal struggles, their pasts and importance in the show, and so on.
Now it’s time to switch shows again. Either you have a new show, or you have to get back into the context of your old show, but not in the same place where you left off before. You start at some other random place, and so on.
With projects, it’s not as passive as watching TV shows, of course, but it’s about as annoying.
Switching contexts can inject new interest
The flip side of context switching is that the new context sometimes provides renewed interest — kind of like moving to a new city or house; it’s fun to explore the new scenery and people.
And sometimes the larger context of understanding other products helps you in documenting the current product. For example, although I document three products, they do overlap in purpose and technology in pretty helpful ways. One is an on-premise product, another is a cloud version, and another is a more comprehensive, robust version of a similar concept. But despite the conceptual overlap, the documentation content doesn’t so much overlap.
Repeating ramp up time is where context-switching becomes inefficient
As I was looking into “context-switching,” with the suspicion that it wasn’t very efficient to be switching contexts like this, I ran across this article by Joel Spolsky: Human Task Switches Considered Harmful. He approaches the context-switching problem like a programmer might analyze it. Then he explains,
When you manage programmers, specifically, task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code. If you send that programmer to Crete for a three week vacation, they will forget it all. The human brain seems to move it out of short-term RAM and swaps it out onto a backup tape where it takes forever to retrieve.
Joel’s article made a lot of sense to me. If you consider the ramp-up time required to push everything you need back into your frontal lobe’s working memory (or however the brain works), task-switching projects all the time makes you inefficient.
When you’re in full swing with a project, you remember where every detail is located, the terms you’re using, the commands and test scripts and test environments you’ve set up, the holes in the doc that need filling, and so on. When you lose this information from your working memory, you have to build it up again to continue from the same place. The time for ramping up with each product creates inefficiency. That’s why programmers hate to switch contexts.
It’s why I said that, ideally, I’d like to stay focused on the same project — it’s easier to keep the momentum because you don’t have to re-remember all the details.
Mentally resetting your knowledge can give you a fresh perspective
However, sometimes this mental reset might be a good thing when it comes to technical writing. If you get too mired in assumptions and other details, so much that you’ve become numb to them because you’re so familiar with them, it may lead to poor documentation.
The best documentation happens right in the space between familiarity and unfamiliarity, when you’re aware enough to understand but not hampered by the curse of knowledge. The mental reset might help you see the product from a fresh perspective.
In a way, it’s like taking the 20 pages of your novel that you’ve just written and putting them in a drawer for a week. You need that space to really reboot/refresh/wipe-clean your previous perspective and see the content anew. In fact, it’s probably a good idea to work on multiple writing projects at once for exactly this same reason.
Conclusion
In conclusion, is it good to switch contexts among multiple projects? Yes, because it’s exactly this mental reset that helps you see your writing for what it is. Switching contexts purges your brain of too many assumptions and other details, and helps you see the product as a new user might.
This fresh perspective comes at a price, however. That price is decreased efficiency. Depending on the particular task you’re doing, you’ll have to decide whether efficiency or a fresh perspective is more important.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.