After last week’s post about Docs FixIt Day at Cockroach Labs, I received several requests asking me to suggest open source projects that people can contribute docs to. As far as I know, almost all open source projects accept docs contributions. The following list includes some open source projects I find interesting:
- Mermaid (Docs: https://github.com/mermaidjs/mermaidjs.github.io)
- Typo 3 Documentation
- OpenStack Docs
- Microsoft Docs
If you have any favorite docs-friendly open source projects, tell me about them in the comments. And don’t forget to subscribe!
Update 1: Suggestions from the community:
Update 2: Came across this article: Open Source Maintainers Owe You Nothing, which I thought was a mandatory read for anyone who wants to contribute to open source projects. It is important to remember that developers and maintainers of open source projects usually work on these projects on their own time and dime, and it is not their responsibility to help us understand how the project works. We need to put in our own efforts, read all available documentation, learn about the project on our own, before we ask for their help.
As an engineer-turned-tech writer, I have repeatedly heard “Writing is so hard; how do you do it?” and “Anyone can write”. Both statements are fallacious. Yes, anyone can write, but not everyone can write well. And yes, writing is hard, and it is made harder by the romanticized notions of inspiration striking, wooden cabins in the middle of nowhere, and solitude.
In reality, writing is a methodical, multi-step process. In this blog post, I attempt to break down my technical writing process so as to demystify it and hopefully make you think about your own process. The following image depicts my writing workflow for any technical document:
As the image shows, my writing workflow consists of four phases:
Phase One: Research
My research phase consists of the following steps.
- Use the Cornell Note-taking System to briefly record the key points gathered from sources (reading materials, talking to engineers, attending meetings, and so on).
- Use the Feynman technique to ensure that you understand the information.
- Setup CockroachDB.
- Try out the feature being written about.
Phase Two: Draft
I use the 5-draft method while writing documents.
Phase Three: Editing and Reviews
Once I am satisfied with the rough draft, I edit my document using several techniques. Each technique helps uncover and correct different facets of the document:
- Grammarly: Check spelling, grammar, adherence to technical writing conventions
- Text-to-speech: I use the text-to-speech feature on my Macbook Pro to listen to the document. It helps me catch awkward sentence constructions, missing words, and so on.
- Elements of Style: This little book sits on my desk and reminds me of my personal pitfalls/repeated mistakes. I have earmarked the style guidelines that I know I forget. Going through the book helps me ensure I am not repeating my mistakes.
- Style guide: I go through the company style guide to ensure I adhered to it.
Once I am done self-editing, I open a Pull Request in GitHub which enables others to review my document. My review process is iterative, wherein my draft goes through technical and editorial reviews multiple times before it can be published. At Cockroach Labs, our engineers and other stakeholders (Product Managers, Sales, etc.) review the document for technical accuracy and completeness, and my manager and fellow technical writers review the document for editorial as well as technical completeness and correctness. The perks of working at a company that is deeply interested in good documentation 🙂
Phase Four: Publish
Once the reviews are done and everyone gives the LGTM (Looks Good To Me), it’s time to merge the document on GitHub and celebrate! Check out my Git profile here.
Try out the process, form your own, and share it with me at email@example.com. And don’t forget to subscribe!
Bonus: I track the various phases of each document in my bullet journal:
Before I started my graduate program in Technical Communication, I had no idea about the immense wealth of knowledge that are the Tech Comm publications. This post provides information about the Tech Comm journals and publications that helped me in my graduate program as well as thesis. Following are peer-reviewed quarterly journals published in the field of technical communication:
Technical Communication (Published by STC)
Technical Communication Quarterly (Published by ATTW)
IEEE Transactions in Professional Communication (Published by the Professional Communication Society of the Institute of Electrical and Electronics Engineers (IEEE))
In the upcoming blog posts, I will review articles from these journals to give you an idea of the type of articles published in the academic tech comm world.
One of the life-changing books I have read in my professional life is Deep Work (affiliate link) by Dr. Cal Newport. As I discussed in the Day-In-The-Life blog post, I start my day with one-hour (2 Pomodoros) of Deep Work. And that has been the secret to my productivity and success as a technical writer.
Following are a couple of resources that summarize the book far better than I could have. Go through the resources, try out the technique, and drop me a line at firstname.lastname@example.org to let me know what you think of it. And don’t forget to subscribe!
Book summary: https://fourminutebooks.com/deep-work-summary/
One of the benefits of being a part of the academic as well as practicing circles of Technical Communication is that I can participate in conferences and communities in both domains. This post lists the conferences and communities that I find useful:
- WriteTheDocs Slack
- STC India Facebook group
- Technical Writers United
- Information Developers Foundation
- STC India
- WriteTheDocs Portland
- STC meetups in the Bay Area
- WomenInTC Slack and Twitter
- ATTW mailing list
- CPTSC mailing list
- ATTW conference
- CPTSC conference
- GPACW conference
- STC regional conferences (I attended two: one in Springfield and another in Missouri State University)
Update: Came across this incredible list of conferences. Check it out!
Thе Pоmоdоrо Tесhniԛuе iѕ a time mаnаgеmеnt mеthоd developed bу Frаnсеѕсо Cirillо in thе late 1980s.Thе tесhniԛuе uѕеѕ a timеr to break dоwn wоrk into 25-minute intеrvаlѕ, ѕераrаtеd bу 5-minute breaks. These intеrvаlѕ are nаmеd Pоmоdоrоѕ, thе plural in Engliѕh оf the Itаliаn word Pomodoro (tоmаtо), after the tоmаtо-ѕhареd kitchen timеr thаt Cirillо uѕеd аѕ a university ѕtudеnt.
The Pomodoro tесhniԛuе helps you асhiеvе the following:
- Imрrоvе efficiency
- Kеер away from diѕtrасtiоns and fосuѕ оn thе task аt hand
- Imрrоvе timе-ѕеnѕе
- Eliminаtе ѕtrеѕѕ burnоutѕ
- Assist in аnаlуzing timе taken fоr tаѕkѕ
Hоw thе Pоmоdоrо Tесhniԛuе wоrkѕ
Thе Pоmоdоrо Technique rеgulаtеѕ when to diligеntlу fосuѕ оn a tаѕk аnd whеn you ѕhоuld take a brеаthеr.
This tесhniԛuе iѕ centered аrоund brеаking your timе down into роmоdоri (one Pomodoro iѕ еԛuаl tо 25 minutеѕ). You lоg a ѕресifiс tаѕk уоu are going tо work on and thеn ѕрrint уоur wау thrоugh thаt роmоdоrо. Aftеr 25 minutes of dеdiсаtеd wоrk, the timеr gоеѕ off аnd уоu tаkе a nice 5-minute brеаk frоm your wоrk.
Once your brеаk is over, уоu ѕtаrt аnоthеr 25 minutе long Pomodoro. This new роmоdоrо саn be dedicated tо thе ѕаmе tаѕk аѕ bеfоrе (if уоu did not complete it during thе previous роmоdоrо) оr a new оnе. Aftеr every 4 роmоdоri (рlurаl fоr роmоdоrо), уоu саn tаkе a lоngеr break, if уоu would like (ѕuсh аѕ fоr 15 minutеѕ).
While уоu’rе wоrking уоur way thrоugh a роmоdоrо, уоu can temporally interrupt it for uр to 45 seconds, if need bе. If thе interruption lаѕt fоr longer thаn thаt, уоur dеdiсаtеd fосuѕ оn thе mаin tаѕk iѕ viewed to bе lоѕt, аnd thuѕ thе Pomodoro iѕ rеѕеt (having tо ѕtаrt over at 25 minutеѕ) again.
Thе dеfаultѕ of 25 minutеѕ реr роmоdоrо, 5 minutеѕ реr rеgulаr breaks, 15 minutеѕ реr lоngеr break, and 45 ѕесоndѕ реr intеrruрtiоn seem to wоrk wеll for me аnd most people I knоw whо’vе triеd thiѕ hаndу tесhniԛuе оut. Hоwеvеr, that said, thоѕе arbitrary аllоtmеntѕ оf timе саn bе сhаngеd dереnding оn уоu реrѕоnаl hаbitѕ and ѕсhеdulе, ѕо аѕ lоng as уоu consistently ѕtiсk with thе аllоtmеntѕ thаt уоu’vе lаid оut. Fоr example, ѕоmе реорlе may prefer to wоrk “in the zоnе” for 50 minutеѕ, аnd then tаkе a 10 minutе break.
Why the Pomodoro Technique works
It is common experience that we can focus on a given task only for a short period of time before we get distracted (or seek out distractions). The Pomodoro technique helps to quantify and manage those focus periods. If you know you have to work for just 25-minutes, and then you can surf the web or check Facebook guilt-free, you will be more inclined to put in those 25 minutes of focused work. And you can get a lot done with 25 minutes of focus!
This technique has been a game-changer for me in terms of my productivity. As I discussed in the Day-In-The-Life blog post, I start my workday with at least 2 Pomodoros of focused work (which is almost one hour), and then I am free for the rest of the day to attend meetings, do some mundane tasks, socialize, or just goof off, because I have done the most important tasks for the day already.
The Pоmоdоrо Tесhniԛuе fоrсеѕ me to think in tеrmѕ of асtiоnѕ that nееdѕ tо bе tаkеn in order tо еffесtivеlу gеt things dоnе. It also imроѕеѕ thаt I рriоritizе аnd dесidе whiсh асtiоn I’m gоing to work оn. By hеlрing tо limit my аttеntiоn ѕраn tо a ѕinglе activity, thiѕ tесhniԛuе аidеѕ me in ѕtауing focused (instead of hopping between a handful оf diffеrеnt tаѕkѕ аnd/оr diѕtrасtiоnѕ).
Rеviѕiting my dаilу Pomodoro lоgѕ highlights whеrе I spend my timе аnd hоw рrоduсtivе I was thrоughоut a given timе period.
I now think of my tasks in terms of thе number оf роmоdоri thаt a givеn tаѕk might rеԛuirе. I diѕсоvеred that еvеn сhаllеnging tаѕkѕ саn оftеn bе tаkеn care оf in a handful of pomodori ѕеѕѕiоnѕ.
Try out the technique and let me know if it works for you. Drop me an email at email@example.com. And don’t forget to subscribe!
P.S: Here’s my favorite Pomodoro playlist:
I often imagine myself greeting my tech writing students as they graduate and enter the technical communication workplace. I imagine myself saying to them, “Welcome to the professional world. You have now graduated from being a tech writing student to a knowledge worker. And the key to succeeding in this role is not writing well, or being a good team player, but knowing what work to do.”
You see, in your days as a student, you knew what work was to be done that had pre-determined success metrics. You had set courses, with defined assignments and grading rubrics. You knew if your work was finished or not, and if you met the success criteria or not.
However, in the professional world, you will not be given a well-defined assignment. Instead, you will be given a “project” – a fluid, ever-changing best-guess scenarios developed by others in the organization. The success metrics are not defined either. As David Allen puts it, “There is usually no right answers; there are choices instead”.
As a technical writer, this is the part of the job I struggled with the most. With a never-ending stream of emails and Slack messages, changing roadmaps and company priorities, I was drowning in an information overload. I couldn’t get a handle on all the things that need to be done, let alone actually doing the tasks. At a time, I was juggling three highly technical projects that each required a considerable amount of brainpower and writes and rewrites. On the brink of a breakdown, I found David Allen’s Getting Things Done: The Art of Stress-Free Productivity (affiliate link). The book has been my savior. It has led to massive increase in my productivity and helped me maintain my sanity.
The Concept of Stress-Free Productivity
Anxiety quickly builds up when we begin to think about all the tasks we have to complete each day. It’s impossible to rely on our brains to remember it all! The Getting Things Done (GTD) strategy works on the premise of relieving our brains of the stress of remembering all that needs to be done by appropriately capturing everything in writing.
Capturing this information in what is dubbed our “external brain” allows us to be fully focused on what we’re doing in the present moment. This increases efficiency and creativity.
My GTD workflow
Develop the 4 Vital Habits for GTD Success
Applying GTD effectively requires more than just recording your to-do list. Making the GTD system truly work for you means embracing the following essential habits: capturing/collecting, daily processing, organizing, and weekly reviewing.
Capturing: Record ideas immediately. Keep notepads in places you frequent, make use of your smartphone’s virtual assistant (such as Siri or Cortona), or create a bullet journal. This helps your brain release the pressure of having to hold on to something to try to remember it. This ultimately releases your mental space so that you can focus on the present.
Daily Processing: Schedule time at the end of each day where you review each captured item and determine if you want to carry out the idea. If you do, you then need to determine the subsequent actions that must be taken. Actions that require extensive attention should be added to a project list.
Organizing: Actions that can be completed in 2 minutes or less should be further categorized into calendar lists, next actions lists, and follow-up lists. Calendar lists are for time-specific items. Next actions are important, but don’t need to be done within a specified time-frame. Follow-up list items are those that are dependent on additional information or actions from another individual.
Weekly Reviewing: Schedule about an hour at the end of each week to check the progress of your task completion. Reflect on where you see yourself in the next 3 to 5 years. Think about the projects and tasks that will help you accomplish that vision. Prioritize the action items that must be accomplished in the following week to make this vision real.
The GTD productivity strategy may seem like more work than you’re prepared to do. Hard work deserves a reward. Treat yourself to something you like at the end of your weekly review. The trick is that you can only effectively complete that weekly review to get the treat. Approaching your weekly review this way increases your motivation to get it done.
Bonus resource: An excellent YouTube video that discusses the GTD method:
So there you have it: the secret to my productivity and success as a technical writer. Next week, we will discuss another of my favorite productivity tools – the Pomodoro technique. Subscribe to stay tuned!
In January, we discussed how to get a job in technical writing: how to search for a job, craft your resume, write a cover letter, and build your portfolio. Graduates of professional technical communicator programs tend to have a sense of ambivalence about what to expect in their new careers. Several questions flood their minds. Is the work world really like the picture my lecturers have painted it out to be? What can I expect? What should I really be looking for? This article chronicles a day in my life as a technical communicator. I hope that sharing my experiences will help you better understand what to expect when you enter the real world.
Starting the day right
Preparation for my workday begins the night before. I follow the Getting Things Done (affiliate link) method by David Allen for planning out my week and workdays (detailed blog post here). By the end of my planning session, I know the meetings I have the next day, which deliverables are due (if any), and what documentation project I need to focus on that day. I juggle several projects, so it’s important to have a focus project for each day to reduce context-switching.
I then break down the focus project into tasks I need to get done that day. Some of these tasks include: meeting people to get information, drafting, editing, reviewing and publishing.
This night-before preparation helps me start my day right. My morning routine begins with a nice, relaxing cup of coffee, cereal with oats, nuts, and apples/bananas, getting ready for work, and a half-hour commute.
I am lucky to work at a company that understands that every individual has different work environment and timing preferences, and encourages us to figure out a schedule that works best for us. For me, I love getting my writing tasks done in the morning even before I reach the office. Most workdays, I go to my favorite cafe at Union Square, get myself a Chai Latte, and put in an hour of Deep Work (affiliate link) (detailed blog post here). In this hour, I work on tasks that require a fresh mind and focus: drafting a technical document or studying how a piece of technology works. I time myself in Pomodoros (detailed blog post here). Once I get at least 2 Pomodoros of the most important task of the day done, I walk to my office at around 11 AM.
At the Office
The first thing I do when I arrive in the office is pour myself a large glass of water and sift through emails and Slack messages. I adjust my task list based on these emails and messages, if required.
I then do some “shallow work” for an hour at noon. Shallow work includes editing something I had written before, processing GitHub issues, and publishing stuff to our Docs site.
At around 1 PM, I have lunch and check my emails and forums such as Reddit and Hackernews. All my meetings are usually post-lunch. This is the time to socialize, meet my colleagues, discuss work projects with them, get information, and so on. The 1 PM to 4 PM time slot is when my energy is the lowest in the day. So, I don’t do any writing tasks then. I leave work around 5 PM and head home for another Deep Work sprint.
At Cockroach Labs, we have a thing called Free Fridays, which basically means you can do whatever you choose to do. You can continue working on your work projects, or put work is placed on the back burner and work on any personal projects, or just take the day off. I usually do my most difficult writing tasks at home on Fridays, and also get in an hour at the gym.
This is just a basic outline of my work day. Each technical writer may have a different experience. Following are some day-in-the-life blogs of other technical writers that I found interesting. I hope that sharing my routine and the routine of other technical writers gives you a clearer picture of what it is like to work in the industry:
Now that we have discussed what a technical writing job looks like on a daily basis, let’s move on to how to succeed at a technical writing job. In my opinion, the most important skill for a technical writer is figuring out the scope of work and planning it well. And that’s what we will discuss in detail in next Wednesday’s blog post. Subscribe to stay tuned!
A portfolio of relevant and professional technical writing samples can be the deal-sealer while applying for technical writing jobs. Check out the following posts from Tom Johnson’s for ideas to build your tech writing portfolio:
For every sample document you create, add a cover letter that describes what the document is about, who’s the audience for the document, which tools you used, and which of you skills does the document demonstrate.
If you have questions, suggestions, or blog post requests, drop me a line at firstname.lastname@example.org