A few weeks ago, I was invited as a guest on one of my favorite podcasts: 10-min Tech Comm. Check out my episode:
PS: Tom Johnson is hosting a poll based on the podcast. Cast your vote here: https://idratherbewriting.com/2018/08/10/how-much-time-devoted-to-learning-tech-is-needed/
In May, I announced a hiatus from blogging because my parents were visiting me in New York and I wanted to spend quality time with them. We had an excellent summer in the city – I have never seen them so relaxed and happy! Now they are safely back home in Pune and I am back to my routine.
The hiatus proved more beneficial and necessary than I expected. Not only did it cure my homesickness, but also gave me a chance to take a step back and rethink my purpose for this blog and its future. You see, the reason I started blogging consistently in 2018 was because I had a lot of things to say about life as a Technical Writer and the blog seemed to be the best medium to share my thoughts and experiences. But now I find that having this blog as my only platform is pretty limiting. I have so many more things to share, but not all of them fit the content structure of a blog post. Some topics are better suited to video content, while others need more long-form content, such as a full-blown course or even a book. Some topics are about my knowledge gaps that need collaboration with other content creators in the tech writing space.
So that’s what I want to do next – experiment with different content platforms that best suit the topic I want to discuss. I still want this blog to be my central platform, so I will continue writing blog posts and link to other content as and when I create it. I hope you find this experiment helpful and entertaining.
Until next week, happy creating!
As you might know, I recently conducted a webinar about contributing docs to open source projects. In this blog post, I am answering few follow-up questions about the topic.
Vinaya Krishna asks:
How to acquire domain knowledge of these communities? (Since you work in Cockroach Labs, there are people who guided you there. But how did you start working on others? Is it just by browsing their pages? Or did you actually get KT from other fellow members?)
Acquiring domain knowledge of the project depends on the complexity of the project. For beginners, I would recommend that they start by just observing the projects that they are interested in – follow the repository, see which contributions are being made, participate in their communication channels (probably Slack or Gitter), and keep an eye out on the issues list. When you feel confident enough to make your first contribution, start small – pick the easiest issue you can find and get a win under your belt. This will help you get familiar with the process and tools, and then you can move on to handling the technical complexity of the project.
I cannot stress enough the importance of being self-motivated and self-reliant when contributing to open source projects. Remember that the project maintainers are most probably employed full-time elsewhere and are working on the project on their own time. We cannot expect them to handhold us through the project – so make sure to do your homework, try figuring stuff out on your own, and approach them only when absolutely necessary.
More details in the presentation: Contributing docs to open source projects
Can a for-profit organization use Github with their data confidential in it?
As far as I know, yes. So GitHub has two flavors: you can choose your GitHub repository private or public. The repositories that seek contributions are public repositories. But you can make your repositories private to keep your data confidential.
Can you please upload the PPT somewhere so that we can visit the links you had mentioned in the closing slides of PPT?
Yes! Here you go: Contributing docs to open source projects
Update: A helpful reader, Suzanne de Veld, suggested the following projects that accept contributions and other useful links:
I am taking a break from blogging this summer, but wanted to come here real quick to answer reader questions about pursuing a Masters degree in Technical Communication.
Neha asks:
Which universities offer this course?
Surprisingly, a lot of universities offer this course. The ones that I know of are Missouri S&T, NC State University, Texas Tech University, and University of Minnesota (Twin Cities).
For a detailed list of graduate programs, see:
Applying to Grad School (This is an excellent resource about applying to graduate programs in Technical Communication. It is written by Dr. Angela Eaton, a professor at Texas State University).
Choosing a Technical Communication graduate program
What are the prospects of getting a work permit or OPT after its completion (Since I am not sure whether it falls under STEM.)
Technical communication graduate programs don’t usually fall under STEM. Which means you get one-year OPT instead of three-years. But you also get CPT in your second year of the graduate program, which allows you to do a part-time internship while studying.
Getting a work permit (by which I assume you are referring to the H1B visa) is decided by luck – literally – since it’s a lottery system. Getting a job in a company which would sponsor your work visa is even more difficult. If your purpose of pursuing a Masters program is to eventually get a job in the US, I need to warn you that it is not a sure thing. I have discussed this issue in detail here: Frequently asked questions
Average tuition fees
Tuition fees vary from state-to-state. At Missouri S&T, the average tuition fees were $11000 per semester. But if you can get financial assistance through teaching assistantships, the burden of the fees lessens considerably.
I hope this blog post helps you make an informed decision about graduate programs in tech comm. If you have follow-up questions, feel free to comment on the post or drop me an email at hello@amrutaranade.com
My parents are going to arrive in New York soon and I want them to have every moment I can spare from work and all my attention. Thus my blog will be on hiatus until August. Till then, happy writing and be well!
I recently attended the Write the Docs 2018 conference in Portland, Oregon. For those of you who don’t know, Write the Docs is a community for everyone who writes tech docs. I have been a part of the Write the Docs Slack community for quite some time now, and I have found immense value from the interactions on the Slack channels. I was excited to meet everyone in person and put faces to names (or Slack handles). And I was not disappointed 🙂
The conference is a four-day event that consists of a hike, the Writing Day, and two action-packed days of scheduled talks, lightning talks, unconferences, reception, social, and the job fair. Not being an outdoorsy person, I skipped the hike and joined the group on Sunday for the Writing Day.
Writing Day is a day meant for conference attendees to contribute to open-source docs projects. This was the day I was most excited about. The entire Docs team at Cockroach Labs had prepped and planned for weeks to set up our project for the Writing Day. During our brainstorming sessions, Rich had excellent suggestions about the types of documentation tasks our contributors could work on. Lauren worked tirelessly to create an incredible style guide to help people edit or write docs for our project. Jesse and I created detailed GitHub issues for tasks we had identified and labeled them with `wtd-writing-day`. And all the preparation paid off.
On the day, we had a full table (that is 6-7 contributors) at any given time. I was impressed by how dedicated our contributors were. While a couple of contributors were already familiar with GitHub and Markdown, most of the contributors had never worked with GitHub/Markdown before. But they were determined to learn the tools and contribute to our docs. They worked through our contributing guide and Getting Started docs and made substantial first contributions. By the end of the day, we had received several contributions and the contributors had successfully learned GitHub/Markdown. It was a win-win!
Since I live-tweeted the talks and unconferences that I attended, you can view my key takeaways from the conference here:
Live tweetstream: Amruta’s key takeaways from Write the Docs Portland 2018
In addition to this blog post, I attempted a vlog as well. Here it is for your viewing pleasure:
Thank you for the response to the Contributing Docs to Open Source Projects webinar! You can help me better prepare for the webinar and make sure that you find it useful and answers your questions by filling in the following survey:
Oh, and if you haven’t registered for the webinar yet, here’s the registration link:
https://zoom.us/meeting/register/52becf806408f7f67510d14dfea9e911
I am back from my very first Write The Docs (WTD) conference in Portland. I represented Cockroach Labs at the Writing Day. We set up our project for open source contributions and the response was amazing! And we were in good company – the other open source Writing Day projects included Kubernetes, Write The Docs, and Netlify. I also met up with Mike Lewis from GitLab and had a productive discussion about their open source contribution process. To summarize, I am pumped up about all things open source docs, and want to share all I learned with you!
Which brings me to an exciting announcement: I am teaming up with Information Developers Foundation to conduct a webinar about “Contributing docs to open source projects”. This is a topic I am passionate about because I have benefited immensely from working with open source projects. But my pet peeve is that while everyone agrees that contributing to open source is a great idea, nobody really talks about how to actually go about it. What is an open source project? How do you get started with one? What do you need to know to make meaningful contributions? What are the things to look out for, or things not to do? I intend to answer all these questions and also walk you through a few open source projects I personally like. So join me on May 19 at 8:30 PM IST to discuss how to contribute to open source projects. Here’s the registration link:
https://zoom.us/meeting/register/52becf806408f7f67510d14dfea9e911
Also, feel free to send in any questions or topic suggestions you might have and I will try to answer them in the webinar:
In April, I had the privilege of sharing with you the day-in-the-life posts from four inspiring technical writers. To wrap up the series, I wanted to do something special. Which is why I made my very first day-in-my-life vlog! Here it is for your viewing pleasure:
Don’t forget to check out the day-in-the-life posts of our amazing guests:
Bart Leahy: Day in the life of a freelance technical writer (who previously worked at NASA and Disney)
Jason Tham: Life of a PhD student in Technical Communication
Swapnil Ogale: Day in the life of a contract technical writer in Australia
Larry Kunz: Day in the life of a technical writing veteran
Special announcement: There will be no post next week because I will be at the Write The Docs conference. However, I am planning to live-tweet the conference. Follow me on Twitter to keep up with the live updates!
The last post in this month’s series of guest posts is by Larry Kunz, a technical writing pro for 39 years! I have been a follower of Larry’s insightful blog for quite some time now, and it is an honor for me to have Larry share his perspective here on my blog. So let’s get to it! Here’s Larry’s post:
I’ve worked in technical writing, and in closely related fields, like project management or marketing, for almost 39 years. Today I’m a Lead Technical Writer at Extreme Networks.
We make and sell equipment for data networks — switches, routers, wireless access points — and the software that controls them. I write the documentation for installing, customizing, and maintaining the physical equipment.
You might’ve heard that technical writing is humdrum, that we do the same work day in and day out. That isn’t my experience.
One of the things I love about working in technical writing, in fact, is that every day is unique. We serve our employers and our customers in so many ways, and we use so many processes and tools, that every day presents new variety.
Let me show you what I mean, by stepping through a day in my life.
Knowing the technology
You might’ve heard that technical writers only need to know the basics of the technologies they work with. That isn’t my experience.
Today I’ll read the design specs for a new product the company hopes to introduce. I’ll read with two purposes in mind: to learn about the product, and to return comments to the designer if anything seems out of whack or is unclear. I might challenge the author to explain the app in terms that a customer would understand — to help me (and the customer I represent) understand how to use the app, not how the app works.
Working on teams
You might’ve heard that technical writing is a solitary profession — that you spend most of the time by yourself. That isn’t my experience.
Today I’ll meet with a software designer to get a big-picture understanding of a new app that customers will use to monitor our equipment. I’ll visit the hardware lab, where one of our test engineers will show me how our new switches are cabled together. In both cases, my colleague will help me gain the understanding I’ll need to describe our products to our customers.
Participating fully
You might’ve heard that technical writers aren’t respected by subject-matter experts, or accepted as colleagues. That isn’t my experience.
Today I’ll meet with three colleagues from Engineering, one from Tech Support, and one from Marketing to discuss a white paper I’m developing. This particular piece was inspired by something a customer wrote on the company’s user forum. It looked so good that I suggested touching it up and publishing it on the company website. But now, questions have arisen about whether its recommendations are in sync with the company’s overall marketing themes. I’m sure we’ll have a lively discussion, with each constituency being heard before I try to lead the group to consensus.
Solving problems creatively
You might’ve heard that technical writing isn’t a creative endeavor. That isn’t my experience.
Today I have to write instructions for mounting switches in a rack, when three different switch models come with three different mounting brackets. Some of the steps will be common to all three models, but some will vary. Making each step clear and not leaving anything out will require cleverness and imagination. It’ll require creativity.
Creativity is the art of solving problems, whether the problem is how to paint the creation of Adam on a curved surface (as it was for Michelangelo) or how to document the best way to mount three switch models with different mounting brackets. Don’t misunderstand: I’m not saying that I have even a tiny fraction of Michelangelo’s genius or talent. But I’m saying that he would recognize the creative process involved in doing the job of a technical writer.
A new day tomorrow
After a day of delving into technical details, of talking – and leading a conversation – with subject-matter experts, of solving problems creatively, I’ll rest up for tomorrow.
Tomorrow’s tasks will be different. I’ll post the final, approved version of a Hardware Configuration Guide. I’ll meet with the team that maintains the Confluence wiki we use to communicate throughout the Tech Pubs organization. Since I hold a senior-level position within my team, I’ll also be helping to rewrite the template our organization uses for documentation plans.
See what I mean? Every day is different. But every day makes use of my technical knowledge, every day has me working on teams, and every day gives me a chance to solve problems creatively.
Is technical writing the life for you?
