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.
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.
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.
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.
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.
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.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include technical writing, authoring and publishing tools, API documentation, tech comm trends, visual communication, technical writing career advice, information architecture and findability, developer documentation, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here.