Two days in my life as a technical writer, followed by reflection and analysis of fragmenting microtasks
Day 1
Morning routine
- I usually wake up around 3 am and wonder why I’m awake, but today I managed to sleep in until 5:30! Hooray. At 6:20 am I’m out the door, driving to the train station with my bike on a back rack. I make it with 1 minute to spare before the train arrives. The train station agent says “You made it!” and I say I need to leave 1 minute earlier because cutting it this close is too stressful.
- Once I’m on the 6:42 am train, I fasten my bike to the train’s velcro attachments and then do some stretches in the stairwell between cars. I’ve only been doing this stretching for about a week, but already I feel like it’s a much better use of my 15-minute train ride time than sitting like the rest of the passengers. Why am I stretching? During a massage a couple of weeks ago, the masseuse said that most people they see have problems because they don’t stretch. Plus stretching warms me up for my bike ride. Stretching feels so good. Does it matter that I’m stretching on the train? No one cares—they barely look up from their phones.
- Soon after the train arrives at King Street Station, I’m riding my bike along the downtown Seattle waterfront, past the Wheel, the docks, smelling the salty sea breeze and navigating through pedestrians. The pedestrians thin out as I make my way to Elliot Bay trail and up across Interbay over to the Ship Canal trail and up to Fremont. I arrive at 7:45 am at the Fremont campus, ready for an 8 am fitness class.
- The fitness class focus is on “Body Strengthening” and thank goodness it’s not another leg day. The instructor, Aaron, explains that the X/O curriculum has changed and now we don’t do foam rolling. The number of exercises seems too many, and it’s true, we don’t finish them. Even so, this workout is more intense and I can really feel it.
- After the fitness class, I do some physical therapy exercises, mostly to rehab my calf. I’ve realized that doing these exercises directly after my class is the perfect time. Some eccentric calf lowering, jumping, more stretches, etc. My muscles are already warmed up and I’m in the mood to do them.
- After the PT exercises and a shower, I go to a nice spot along the Burke Gilman trail, right by the ship canal, where some cement stairs cascade up the hill, and do a 10-minute meditation from the Calm app. I really like Tamara Levitt’s calming voice. Doing this meditation slows my breathing and helps me switch gears.
- After the meditation, at about 9:15 am, I hit the cafeteria for some breakfast, opening my computer to browse email and other updates while eating.
- On my way to my desk, I stop by the cafe for a coffee (my preference is decaf breve, some days a decaf cortado). I gave up caffeine a couple of months ago but still like the taste of coffee.
- Now my morning routine has been completed, and at around 9:30 am I’m ready to start working for the day.
First pomodoro
- With a hot espresso in front of me, I set my Focus timer for my first 90-minute pomodoro. I close down Messages, Chat, and email so that I really focus. This is the prime time for my best hour of the day, and I can fly through tasks if my focus isn’t fragmented in a dozen directions. I have two main tasks I want to complete today: complete a conceptual doc on a mapping concept, and finish writing talking points for some peer reviewers for a promotion submission.
- Starting on the conceptual topic, I see that a reviewer has added a lot of comments on the changelist (or CL), which captures all the doc changes I’ve made. The reviewer wants me to remove a section that I think partners will want to read, but at the same time I lack accurate and detailed information to avoid the landmines in that section, so I oblige and hit delete there. I make my way through his other comments and update the CL.
- Then I switch over to the other task—brainstorming some peer reviewer talking points. I begin with an outline and add details as they come to me. No one likes writing self-praising content like this, but it’s the task. As I dive into some details, I find that I have some good points the reviewer can make, drawing on experiences for previous docs I wrote for them. I manage to flesh out three meaty bullets for the first reviewer. This is exhausting.
- My Breaktime timer goes off, reminding me to stand. I have this set to go off every 30 minutes. I push a button to raise my desk, take off my shoes, and stand on my Movemate board. It takes a few minutes to adjust to the new position but already my back is thanking me and I’m feeling great standing.
- I’m back to the peer reviewer’s talking points. Working on some talking points for the second reviewer. I’ve worked with this person for two years, but what experiences can I focus on? I tease out some more details, building it out little by little. I learned long ago that I’m infinitely creative—I just need to noodle on this a bit and some experiences will pop up. Some docs I write come to mind. Now I’m remembering why I chose this reviewer.
- Time’s up on the pomodoro. I relax a bit and check email, news, and get a banana from the breakroom. It seems that during this 90 minutes, I’ve already gotten 15 emails, though none look particularly exciting. Looking at the email, though, a product manager had comments on the conceptual doc too but failed to submit them earlier. Now I’m seeing his comments. I go through and incorporate them as well, though half of them are moot because I deleted that problematic section. I love that the PM is getting involved in doc reviews rather than just engineers.
- My calendar dings to remind me about a lecture on cars in china. I want to hear it but I can’t stand to sit and watch presentations for long periods of time when I can instead listen to it while biking. I’ll catch the recording later if I can remember it.
Lunchtime
- It’s now lunchtime, and I’m ready for a break. I walk around a bit, looking at a previous building we left and notice that it seems to be under construction. I get some lunch at a cafe, opting for the protein vegetarian option and some slices of sushi. After lunch I browse around online and leave some Google reviews on businesses that I’d been planning on reviewing for a while. I briefly review a physical therapy clinic, a car dealership, an Ethiopian restaurant, and a vintage thrift store in Bellingham.
- I wander back over to the cafe and chat with the barista Sam a bit. He says my name “Toom” to be playful and we talk about how no one ever mispronounces Tom or Sam. I wish I had a more creative name that people might occasionally get wrong.
Second pomodoro
- After lunch, it’s time for my second 90-minute pomodoro. I shut down email, chat, and messages again and turn my attention to some release notes for an SDK that has a release tomorrow and the peer reviewer’s talking points.
- As I dig into the release notes, I see that some content is appearing in the generated doc that is supposed to be hidden until a later release. Why is it appearing now, then? Did the engineer apply the annotations in the source incorrectly, or is there another process that was skipped? I read through an internal doc on the annotations but don’t immediately spot the problem. I’ll just manually remove the unintended sections from the generated content for now. This hidden content will appear in the next release anyway.
- It’s “No meeting” week so I have more time than usual, as most meetings have been wiped off the calendar. I don’t usually have more than 1-2 meetings a day anyway. Even so, it’s refreshing not to have meetings.
- Switching tasks, I make good progress developing three bullets each for two of the reviewers. I revise them multiple times and proofread them and am feeling proud that I actually have something for them to potentially say. But for the last reviewer, I’m still drawing a blank. Why did I select her again?
- I need a break and wander into the breakroom to get some snacks. I choose an apple and a red plum—quite a natural sugar dose. I run into one of the reviewers on the mapping concept CL and chat with him for a few minutes. He fills me in on why that section was problematic and how we’re better off not including it. I see now that it’s best to reduce or minimize it. I like running into engineers and having short conversations. I seem to recognize at least half of the people walking around in my building.
- Back at my desk I see I missed approving a CL that I should have reviewed last week. A partner engineer is merely updating the minimum supported Java version for a tool, but it seems two different engineers have different supported versions in different CLs. One acquiesces to the other so I approve the CL that has the latest supported version and assume they have their reasons.
- I check on a release notes staging doc for another API that’s releasing today. Thank goodness there aren’t any new features, but we still need release notes that say this much. Otherwise partners will wonder why the release notes haven’t been updated. I create a new CL and send it to an engineer for review. It basically says there are no new features for this release.
- Back to the peer reviewer’s doc, I start adding more details for the third peer reviewer’s talking points. Some ideas are coming into focus, but slowly. I know if I keep chipping away at this I’ll have it soon. Now I remember why I selected her. She’s been close to some major docs that I worked on and I want her to comment on how I solved some partner pain points.
- Breaktime timer goes off, I’m standing again. I really like swiveling around on the Movemate and it suddenly dawns on me that I might wear the carpet thin below me. I check the bottom of the Movemate’s wooden slats and realize that I should sand them down a bit to smoothen things out.
- I finish ironing out the release notes for the API that’s releasing tomorrow. It turns out everything I thought was being updated was really intended for a later release, so there aren’t any new features after all. I instead look closely at the file diff and remove these unintended sections. After some poking around, I realize that the engineer put the exclusion tags in the wrong yaml file. I update the bug I originally assigned to him, assigning it to me and moving the exclusion tags to the right yaml file. Theoretically I could regenerate the doc but who knows if some other stuff will come over because if I regenerate now, it will build from the latest commit rather than the build snapshot last week. Also, why didn’t my script catch the error? Something is wrong with my script. I should fix it but not now, that would slow me down too much today.
- Looking back at the release notes, I see a comment from a PM who asked about a section of the release notes highlighting doc updates. She didn’t think a certain field had been updated. I thought someone had updated it with the word “Optional” and added a clarifying sentence, but with more investigation at the commit history and the file diff, I realize that I misread the diff. There aren’t any changes, but a systems architect, seeing me call out the doc update, asks me to remove a phrase anyway. I remove it from the source and generated output, but now this requires more approvers for the CL because the proto file I updated is in an engineering directory.
- Back at the peer reviewing talking points, I flesh out two bullet points for the third reviewer. Turns out I don’t need three bullets for this reviewer. I’ve expanded the details with enough substance. This is looking good and I ping my manager to review it before sharing it with the reviewers. He suggests adding another bullet for business impact—good call.
- Times up on the pomodoro. I need a break.
Afternoon break
- I wander back into the breakroom and chat with another engineer. I haven’t talked with this engineer for a while nor seen any new features for that team, so I ask him what he’s working on. Thankfully, it’s just metrics, which isn’t something partner-facing. That means there won’t be any doc requests related to that work. We talk briefly about Labor Day and what we did. I’m boring and didn’t do much except help one of my kids prepare to move back to Bellingham for college.
- I’m still in break mode. My oldest daughter recently moved to an apartment a mile away from me. I scooter up to her place to drop off some laser printer toner that I ordered for her because I know she has a job interview and I want her to be able to print her resume. Too late, she already had the interview and fixed the printer ink problem herself. Her job interview went well. She’s smarter than me, I’ve realized, and will be a super catch for anyone who hires her. Her roomies, just moved from Oregon, are all at the kitchen table with their laptops looking for jobs. They’re just starting out, and I’m pretty much at the peak of my career. My visit is short (5 min.) as I just want to say hello.
- Back in the office I create release notes for the no-feature release. Then I decide to triage some bugs. I usually mean to do this triage on Mondays but didn’t, as it was Labor Day. I make sure any incoming bugs are tagged with the right API. I notice that many of the bugs that are piling up are short ones that I can do in about 15 minutes each. I look through the unfinished bugs I’d scheduled for last week and remove their tags for that week’s date. Then I archive that list.
- As I have more time this morning, before submitting release notes for the no-new-feature API releasing today, I decide to include a simple doc update where another engineer asked me to add a paragraph and diagram to an existing conceptual doc. This will pad out the empty release notes with at least some update, so I do it. Both engineers quickly approve the release notes and I publish them. I wonder why the engineer didn’t just make the update herself, as I’m just copying a paragraph and adding a diagram she already created.
- Back to the peer reviewer talking points, I’m feeling pretty good about the bullets. Writing them made me realize that I’m drawn to more complex problems, so leveling up is probably the right move. Trivial doc updates bore me. The problem is, I’m the only writer in this part of the org, so not all doc updates are challenging problems. I contemplate adding a note to the doc bug template that asks engineers to make their own updates if they’re small. “Think about whether you need a professional technical writer to do this, or whether it’s a small enough update to make yourself.” Should I add that? It doesn’t sound quite right. I’ll keep thinking about this.
- I think about checking in on a contractor who’s working on some doc work for me. I filed a massive bug for them and they had a bunch of questions the other day, which I tried to address, but now I haven’t heard anything from them for 2 days. Should I check in? Maybe wait until tomorrow, I think. It’s a gargantuan task of ensuring field descriptions are consistent across two APIs. There are hundreds of elements to match with slightly different names as well. I think the weight of the difficulty finally settled on them.
Journey home and evening
- It’s near the end of the day and I get on my bike and ride back to King Street Station. The ride down Elliot Bay trail along the Sound, with the blue water, is gorgeous and always rejuvenating. The sidewalk is full of people; most likely the cruise ships are in port, though I didn’t look specifically. More people come out in good weather. Before long I’m on the train and stretching again. The workout from this morning felt great all day, and the stretch feels even yummier than the one this morning. Here’s part of the bike ride that I love:
- At home I chat with my family for an hour or so. One of my daughters has been picking out furniture for their new apartment, getting just the right size desk to fit in the small room. Another is cooking pasta—she has goggles on to avoid tearing up while she sautes onions, which she recently discovered she likes. Another kid picked up a shift at Starbucks, where she works as a barista.
- We eat dinner on the back patio, where my wife loves to have dinner. It’s a warm summer night even though it’s early September. A heat wave is coming tomorrow. Mosquitoes cut the dinner short and we return inside.
- I do some dishes while we watch a dog show. One dog named Dory keeps getting confused and distracted on the course while an Australian toy shepherd looks sharp and quick and smart. Dogs are funny but my kids are dedicated cat people. There aren’t any cat shows that I know of.
- I beg my youngest to turn off the TV and do her homework. She later shows me perfect math scores on Canvas. Another daughter works on her college app in Common App and asks me questions for the profile section.
- I sit down and write this blog post as well as add the final bullet about business impact to the peer reviewers comments, which I’ll send tomorrow. Then I head for bed. It’s 10:30 pm and I’m super tired but ready for my morning routine tomorrow.
Day 2
I found that logging the activities of my day was fun, so I decided to do it again, this time a couple of days later.
Morning routine
- Today’s routine follows the same, with a couple of differences. Recently, my PT recommended I use clip-ins on my bike so that I can pull up. The first couple of days pulling up I don’t think I was doing it right. Now I switch to pulling back and I can feel more of my hamstrings engaged. It’s a pulling back and up motion, like going from 4pm to noon counterclockwise on a clock dial. I’m flying with this new technique.
- I arrive about 5 minutes earlier than usual and have enough time to do the meditation first. The focus is on controlling obsessive thinking.
- The fitness class (“Body Performance”) starts out easy, then gets much harder with a metabolic conditioning circuit that I can’t actually finish. I only get 6 of the 10 rounds completed, but that’s okay—it was a great workout. It’s nice that the exercises scale to an individual’s conditioning level.
- At my stop for coffee, I ask the barista what would be the equivalent of two cortados poured together (because they’re so small), and they tell me triple decaf flat white. It’s perfect!
First pomodoro
- For my first pomodoro, I want to close out as many changelists (CLs) as I can, as it’s Friday and I need to put together my snippets (accomplishments) for the week. Yesterday I added a visual label/button to docs indicating they only apply to a specific API. I had to hack the button into a label, but it looked decent. Now a higher-level PM is wondering who asked for the button and I’m hoping he doesn’t kill the effort.
- The mapping concept doc has stagnated. The requester is too busy to drive its completion and now some commenters are asking if we should change the name of the feature to something else. They suggest using the same terminology as the API, and I sort of agree, except that everyone else calls it by another term. I’m happy to oblige on the terminology change, though, but no one else has any input. I wait for corroboration on the terminology change. Is this what it will take to close the CL?
- The release for an API I worked on a couple of days ago has been delayed. It should have gone out yesterday but was hung up due to PM approval. Now the team doesn’t want to release it on a Friday. I’m not even sure what they’re releasing because there aren’t any new features in the release. My release notes are ready to go except that I forgot to remove some other unintended tags from the output, so I make a few updates.
- As I close out comments on a staging doc for the release notes, I see that an engineer added an update. It’s minimal and surely no one will care, but I’ve been asked to be exceptionally granular in noting each and every change, so I explain what’s been updated. A cleanup script has a tiny update, that’s all.
- While my attention is focused on this API, I decide to dig into the script to see what was wrong the other day. It should have caught the errant tags that came through. Why didn’t it? I dig around in the script and use AI to try to troubleshoot. I make change after change and try to test the output, but testing the rebuild takes forever, so I finally strip out the build commands and shorten the testing time. The script seems to be working fine—it identifies errant tags in the output—so what was wrong before?
- While I’m fixing things, I decide to address a shortcut key that stopped working. A eng team updated a VS Code Studio extension, and it takes only a few minutes to see the new command name and remap my shortcut key.
- The contractor pings me about having finished the bug I asked them earlier in the week. I’m blown away by the amount of work they did so quickly. It makes me wonder if I’m losing my edge or maybe getting old. Am I slow? What would it be like to have this person engaged on all these tasks? Maybe they could power through them, if they didn’t have to deal with all these micro-task distractions with the release snafus.
- My Breaktime timer goes off, and I stand again. I put on some Hurraw coffee bean lip balm and am pleased with how it smells. This is the one present someone gave me for my birthday that I truly like. How ironic that it was the smallest thing.
- Back to troubleshooting my script, I do more digging and fixing. At one point I consider revamping the entire script. Why didn’t I insist on keeping it simple? Then I remember why I have multiple scripts and workflows. As I scroll up through the terminal output, a light bulb moment occurs. The script working all along and I just didn’t realize it. I thought my celebratory ascii art indicated the script was free of the errant tags, but it turns out the celebratory art appears no matter if other parts of the script identify problems. I just needed to scroll back through the output to see the flags about the errant tags! I try to make the art output conditional (flipped upside down) if the previous output identifies errant tags, but it’s too complex given the multiple scripts and workflows. Leaving it as is. Wasted 3 hours.
Lunchtime
- I jump on a scooter and ride it around a few blocks, over to a nearby basketball court where I plan to occasionally shoot baskets during breaks, just not today. Today there’s a heat wave and I don’t even have my basketball. At the court I envision myself shooting a few shots and wonder if the double-walled rim will be a good hoop. Then I return and eat lunch.
Second pomodoro
- I browse to the cafe to get another triple decaf flat white. The baristas smile, knowing that they’ve nailed exactly what I like.
- Today hasn’t gone so well with planning. I’m scattered across a lot of half-finished CLs and really want to close out more of them to have more accomplishments for my week’s snippets. One item that remains is to prepare for my prompt engineering for docs study session on Monday. What will we even talk about?
- I want to focus on AI in health and fitness, but this is outside the study group’s focus, which is on AI in docs. Maybe I can make the topic fit somehow? Perhaps as an analogy? I get my latest bloodwork report from my annual physical, download a copy of Peter Attia’s Outlive (from a random Internet site), and paste both into an internal AI tool and ask it to analyze my blood results based on Attia’s insights from the book. OMG, the result is mind-blowing. Yes, this RAG stuff really works, especially with two million tokens as the context limit. Could this focus work?
- During this pomodoro I haven’t closed down my email or chat because I’ve been trying to interface with some engineers to close out CLs. But in my email I see I’m mentioned in a long bug thread about a feature missed in earlier release notes. The bug thread is immense and takes me 20 minutes just to figure out what the context is. I paste it into AI and ask for a summary and action item, then I skim the thread again and pick out the action item. The doc update is two lines about a data update (which wouldn’t have been visible in any API diff). Before I finish typing my comment to provide an update about the doc, an engineer has already approved my CL.
- But before I submit the two-line update, I see a link path that’s wrong. Oh no, during an earlier site migration, my sed command on path replacements munged some paths. I look through the entire dev portal and find half a dozen instances of the munged path. Fortunately, no one has seemed to notice. I fix all the broken links in the same CL as the missed release note.
- I return my attention to the prompt engineering topic. How do different prompts perform in different AI tools? Maybe that’s it? I try the same prompt with Attia’s book and my blood lab results in Claude, but Claude’s context limits require me to split up the PDF and chat session into multiple sessions due to the 200k context limit. I string the chat responses together, but they aren’t nearly as interesting, and splitting up a 450 page book is tedious. Even so, the gist of the response is similar.
- What other CLs can I close out? I look at the CL with the buttons/labels, the one in which the PM asked who requested it. I’ve seen no other activity on the CL, so I submit it. The conceptual mapping CL is still unfinished by the reviewer who can close it out, but her later time zone means her week has already finished. It’ll have to wait until next week.
- I need to start writing my snippets to close out the week, but the office is dead and the only people around look sad and isolated. I can’t take much more of this week and decide to head out a half hour earlier than usual. I’ll finish the snippets over the weekend as well as finish the prompt engineering session preparation.
Journey home and evening
- Although my body is sore, I’m surprised at how much energy I have for the bike. It’s a beautiful day and not as hot in Seattle as it is in Renton. I’m flying along Elliot Bay trail.
- My wife has made shepherd’s pie and my youngest is banging a coconut with the backside of a knife. I get her some safety goggles at least.
- I sit down, ready to watch an NFL game but realize that the game is in Brazil at an odd time, so there’s nothing but the end of a tennis game. I watch a TV show instead: Kaos. No one else joins me because I’m mid-way through the season and one of my daughters is hanging out with their boyfriend.
- At 9 pm I’m super tired. When you’re tired, sleep, I think. So my day ends.
Reflection and analysis
In logging the activities of my day, I’m surprised at how fragmented things are, and how little actual writing I’m doing. These days were somewhat more fragmented than others, but I’m regularly bouncing from task to task, as things come into my email or as I try to interface with engineers in different CLs. My preference is to pick one or two big tasks and work my way through them. However, once I get an initial draft, getting the CL over the finish line often requires considerable pinging of engineers, back-and-forth outreach, small updates and other tweaks. There’s too much overhead for the tasks I’m doing and it’s consuming much of my bandwidth.
Looking at the tasks, I would benefit more by perhaps implementing a filter in the initial bug requests that asks engineers whether the update is something they could do on their own. If so, there’s no need to involve a professional technical writer. I’m spending too much of my time handling tasks that could be done by a junior writer or even someone who’s not a writer at all. This kind of over-engagement on microtasks will likely lead to unfulfillment and boredom.
For example, consider release notes that are no-feature releases. Why are we even doing these? I’ve asked this before, but sometimes there are small fixes or improvements behind the scenes that aren’t externally facing. Having an erratic release schedule also creates unpredictability and questions with partners. Why were there no release notes this week? Did the release happen? Why not? Did the technical writer forget? So it seems that some statement is always necessary. But do I need to write it? Could engineers handle this instead? Yes, but now we have situations where some release notes would be written by engineers, others not written by them, and how does an engineer know when to write the release notes? Engineers like clearly defined processes rather than week-by-week judgment calls.
And what happens when engineers start taking on more release notes writing but do it badly, such as being overly vague, calling classes and methods by more generic names (or even the wrong names) and not linking to them? At this point I’ll have to start adding comments to their CLs, which can require more bandwidth overall than if I’d written it myself.
Another task that consumed an inordinate amount of bandwidth was the thread where I had to write the missed release note. The participants offloaded the context deciphering onto me, requiring me to trace back through a long thread and try to figure out what docs are needed and what should be said. What could have taken the PM or engineer in that thread 30 seconds instead took me 30 minutes just to trace the context. This is basically what nearly every bug looks like in tech comm, though, so I’ve come to accept it as the norm.
Instead of immediately responding to the thread, I should have asked people to file a bug. That bug template should ask the requester to clearly state the release note that should be published. Yes, that’s probably a much better approach—to provide sections within the bug template that require the engineer to more clearly provide the needed documentation and release notes, which I can then simply copy and paste. At least this wouldn’t require them to figure out authoring tools and workflows; they could instead just write in the bug template, knowing that I’ll at least review and edit the content before publishing it.
My existing bug template actually does have a section asking engineers to write the release note for a feature, and about 75% of the time what they write is unintelligible garbage. Most of the time I look at what’s written and can’t make sense of it, and the person requesting the feature isn’t available. For these bugs I should simply reject them and ask them to clean it up, even if it means pasting the content into an AI tool to fix the grammar and clarity first.
Overall, I think my strategy of the two 90-minute pomodoros, one in the morning and one in the afternoon, is a good, sustainable approach to getting doc work done. Certainly it’s more suited to working on larger tasks that require more time and energy. Because of this approach, many small bugs have been queueing up, such that I have about 90 open bugs. I swear half of them can be done in an hour. They’re small things like changing “less than” to “fewer” (yes, someone filed a bug about this, but the fix involves changing engineering source comments, so this simple update will be 10x harder than updating a markdown page). Other updates involve changing table column names. But this column name can’t simply be changed without a release note, and I can’t make the change without first checking with a PM that such a column title change is needed or allowed because it’s a policy doc.
Overall, the updates are simple, but for every update, there’s a lot of overhead. First, someone has to create a bug. Then you create a CL in the authoring system. Then you find someone to review the CL. Then you have to submit the CL successfully, which might involve adding tags and other notes to the CL. This is the basic tracking of any change that’s necessary, so that later when someone looks at an update, there’s a history and context they can investigate to see who made the change and why. But it slows everything down. The administrative cost of fixing one small typo can be 20 minutes. Add in the diminished attention from context switching and fragmentation, and it’s a productivity killer.
Additionally, there’s no real pat-on-the-back for making small updates like this. These updates align with a much lower role profile, so even knocking out 100 of these microtasks won’t help me list any accomplishments or even help make the case that I’m fulfilling my current role during quarterly reviews. You’re a senior technical writer and you fixed some munged links? Uh, okay. But what did you actually accomplish?
Perhaps all the overload from microtasks can be solved through better organization, processes, and productivity. Part of the point in fixing the scripts is to reduce the amount of manual labor. Even though I sunk a few hours into investigating why a script wasn’t working as I thought it should, this is time well spent. A script can automate a process, and I definitely want to optimize my day with scripts where possible. If I can use AI to help write scripts that automate smaller processes, great. Perhaps one script can be to remind engineers to comment on a CL, though these automated reminders are easily ignored and become like spam, so probably not.
The larger problem of all of these microtasks is that they don’t scale well for AI integrations. AI works well when you have larger, meatier writing tasks. For example, I mentioned analyzing my bloodwork results by uploading Peter Attia’s book and asking AI to respond like Attia might. Imagine if I instead asked AI to correct some typos in a few paragraphs—what a waste of time for AI. Knowing that AI can read a 450 page book and articulate some pros and cons of arcane biology details, it’s sad to think that I wouldn’t take advantage of this but instead spend its bandwidth doing menial tasks. That’s a shame, a waste of one’s talent.
I dream big as a technical writer. I like to swing for home runs and tackle complex, sophisticated problems. This is why I’m a senior technical writer and should even be moving to the next level. Figuring out how to focus on these tasks, to get into the deep work that Cal Newport talks about, is what I need to do. I want to leverage AI in these homerun-swinging tasks. Instead, I’m too regularly caught up in the minutia of microtasks.
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.