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.
In this conversation, we talked about what it’s like to work on Google’s tech writing team and my previous experience at Joyent. I spoke about the importance of multimedia documentation, creating proposals to tear down bad docs, and what it has been like to join the conference circuit.
Just a note, this conversation was one of my own and not on behalf of Google or Alphabet. My thoughts are not those of my employer’s.
There is something special about Write The Docs. I’ve been to a number of conferences in the last few years, many of which were tech-specific, and this is the only one where I feel confident that I could have walked away friends with everyone. People who attend this conference are kind, smart, thoughtful, and every other adjective you’d hope for your communicators.
I was honored to be among the 15 speakers chosen to speak. On Monday, September 10, I presented, “How to tear down your existing documentation,” focusing on the ways writers could write a proposal to convince their managers that the documentation needs to be blown up.
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?
Two years, six months, and seventeen days ago I got off a plane at LaGuardia Airport with a backpack and two giant suitcases. I got in a taxi and we sped (well, probably no more than forty miles an hour, but you get the point) towards Brooklyn. I moved to New York less than two months after college, two weeks after returning from traveling abroad solo, to start my first job as Digital Marketing Associate at JCC Association.
After two years, six months, and three days as a working professional, I hugged my colleagues goodbye and took my cubical decorations and paperwork home. The very next day, I took my Michigan oven mitt and a three legged chanchitos figurine (thanks Alex, Sarah, and Tom) to my new job at WNET (also known as Channel Thirteen). I accepted a position as Associate Web Developer (sometimes in official paperwork known as Web Engineer), beginning the day after I left.
Over the past year, I had decided I really loved building for WordPress and wanted to focus on becoming a better developer. That being said, my resume still spoke volumes to my marketing and community management abilities, more than my technical skills. While I decided in the spring to start looking for a new position, I decided I would apply on both sides of my skill spectrum. I knew my next position would probably help steer the rest of my career, which was extraordinarily nerve wracking. I knew what I wanted, but I also knew that without a computer science degree or a host of previous developer roles I was at a huge disadvantage.
Two years, six months, and seventeen days ago I got off a plane at LaGuardia Airport with a backpack and two giant suitcases. I got in a taxi and we sped (well, probably no more than forty miles an hour, but you get the point) towards Brooklyn. I moved to New York less than two months after college, two weeks after returning from traveling abroad solo, to start my first job as Digital Marketing Associate at JCC Association.