As generative AI has become more widely available, we’ve seen how widely the quality of results can vary. In fact, there are several components that impact result quality, such as which large language model (LLM) you’re using, model size, and prompt quality.
As a technical writer, quality prompt writing is pretty close to a summary of a key job component: ask the right questions of the right people to get the best possible information to shape what I produce. I go to the subject matter expert (SME), who may be an engineer, a product manager, a UX researcher, or another technical writer.
In my day-to-day work for Google Chrome, some of my questions could be asked of an LLM, but that requires the model have pre-existing information or to be given the context within the prompt itself.
Prompt quality is impacted by the level of details provided, initial information accuracy, description of expected format, and so much more. Prompt engineering is the practice of asking better questions to generate the best possible response for your needs.
If you’re wondering how to be a better prompt engineer (or a better tech writer!), keep reading to learn best practices.
I had the pleasure of editing Carie Fisher, the author of web.dev’s latest course, Learn Accessibility. Learn Accessibility gives web developers the essentials for building accessible websites and web apps.
To promote this new content, I interviewed folks who work to build an accessible web.
Melanie Sumner told me about her journey from spy to engineer, accessible design, Ember.js, and the importance of funding these efforts.
Olutimilehin Olushuyi told me about his move from the law to web development, building accessible community, and creating accessible layouts.
Elisa Bandy told me about her work for Google’s internal teams, developing accessibility best practices for the web. Her blog post has yet to be published, but look for it in mid-December.
It’s an honor to work on Google Chrome’s developer relations team. I have the opportunity to speak with experts and offer a platform with a huge audience.
We highlighted additional resources as a part of ChromiumDev’s Accessibility Week.
In October 2017, I decided to apply to Google. It wasn’t the first time I had applied—I applied in 2011 when trying to get a job post-graduation in communications. Back then, I never received a response to my application and expected similar results in 2017.
Although I applied for a product Developer Programs Engineer position in New York, I ended up getting an email from their technical writer recruiter the following week. A year and one day from the day I submitted my application, I signed an offer letter. And 6 weeks after that, I finally went to Noogler (that’s what they call new Googlers) orientation. It was a long road to get here.
In a few months, I’ll be joining the technical writers community at Write The Docs Prague. I’m thrilled to have been chosen and I look forward to meeting my fellow writers. Check out my intended abstract:
How to tear down existing documentation and rewrite docs that actually work
We all know what it’s like to look at a series of existing documentation and think, “how did this happen?” Be it a large swath of unorganized content or a lack of a clear strategy, the complications of bad docs aren’t just a curse for documentation editors. Our readers see it, too. It leads to confused support requests and possibly a loss of customers.
Over the last three months, I’ve written a series of four blog posts about creating and managing instances with Packer and Terraform. It’s been a tremendous learning experience, and I couldn’t have done it without the help of some HashiCorp experts (and ex-pats). Thanks to Sean Chittenden, Paul Stack, and Justin Reagor for your advice, critique, and editing.
Below I’ve included excerpts from all of the posts. The source code for all of the exercises is available on GitHub.
Are my readers already experts? Have they done this process before, if not exactly then in similar circumstances?
Are my readers internal or external? If my readers are within the same company, what language do we share that will help better explain the process?
What mood will they be coming to my content with? Am I creating this content for someone who is in a rush to get something done, or is this for a more casual learner who is just hoping to further their education on a topic?
What is most important to my readers? What is least important?
How do my readers prefer to learn? Do I know if a blog post is more successful than a video? Is there any analytical data to support these claims?
Are my readers native English speakers? If I use an idiom, will it hinder their ability to learn how to complete the process?
