Credits:
Photo by Startup Stock Photos from Pexels Curious about what a technical writer can do for you?
Here are twenty-five things you might find a technical writer doing in their job on any given day:
Interviewing a subject matter expert to learn more about what they are writing about.
This might be a product manager, project lead, developer, customer, salesperson, developer advocate, end user, nearly anyone who might touch or use what we are a writing about.
Credits:
Photo credit: by Sara Kurfeß at Unsplash I started using Git and GitHub for docs in 2019. It’s been a slow build, but I’ve finally started to learn some helpful ways of going about things. So there are two GitHub specific tips I want to share with you that have helped me out in my day to day.
Choose where a repo’s notifications go For the longest time, I just let all of my notifications go to whichever default email address I had defined.
Credits:
Photo credit: by Pixabay at Pexels Why is good knowledge care critical? Every business, small or large, has a body of knowledge around its existence.
The business has one or more products or services it sells. It has processes for how to obtain, create, or use the products or services. It has sales documents and collateral. There are accounting charts and customer lists. How to manuals and vendors. Hire onboarding and competitive analyses.
Credits:
Image by Samson Katt on Pexels Good docs have (at least) six key characteristics:
Findable Accessible Legal Accessibility Language Accessibility Scannable Searchable Timely Complete Findable For documentation to be worth the time spent creating it, the user needs to be able to get to those docs when a problem or curiosity creates a need for information. The best docs do nobody any good if they can’t put their hands or eyes on them when they need them.
Credits:
Photo by Alexas Fotos from Pexels. There are many flavors of technical writing. Mine is software.
One of the constants of any software team is the change that comes with employee churn. People find new opportunities by joining your team. People find new opportunities and leave your team for elsewhere.
Sometimes the “people” winds up being you.
What can you do to leave well? What steps can we writers take to make sure the baton passes well to the next person, whoever that next person may be?
Credits:
Image credit: Photo by Moose Photos from Pexels I would also like to thank the tech writers in the Write the Docs Slack’s #lone-writer channel for bringing these ideas to the top of my mind. Everyone suffers from a bias of familiarity when looking at our docs. Once you read something once, the next time you read it the mind can anticipate and insert what it remembers and expects to be there.
Credits:
Image by Suzy Hazelwood on Pexels Are docs a good investment? One of the challenges every documentarian faces is justifying the investment in docs.
Whether that investment is
salary training and professional development expanded doc team tooling dev help for site development It can feel like we technical writers are always battling it out for the company’s money. And, often, the experience is that the money for conferences or books or a new team member goes to other teams instead.
Credits:
Photo by Startup Stock Photos from Pexels. Technical writing can be an introvert’s dream. (I know, I am one!) That said, there are two communities that every tech writer needs to develop to thrive in our work.
Network of co-workers and subject matter experts Other tech writers for support and professional development Why are these communities vital? And how does a tech writer go about developing them?
Let’s dive in!
Credits:
Photo credit: by Brett Jordan at Pexels What makes a good technical document? A good technical article, document, or topic has a few key points that make it stand out:
It understands the user and has empathy for the situation that brought them here, now.
Don’t miss this point. It’s key.
A good technical article has to be inside the mind of the user that’s come to the article.
Credits:
Photo by Ron Lach from Pexels You can’t hang out with knowledge management platforms for long without realizing that their structure, or, should I say, “architecture,” gets dated.
It cracks. It goes stale.
Stale knowledge, a litany Knowledge stops functioning the way it did at the beginning.
The roads go awry.
There are turnabouts everywhere.
Dead ends.
So many dead ends.
Construction projects started, then abandoned.
Detritus strewn about everywhere.