# Technical Writing One and Two: Google's free writing courses every FDE should take > One passive sentence in a handover email can leave a whole customer team waiting on each other. Two free Google courses teach you to avoid that mistake and many like it. Original: https://fdetimes.net/en/books-courses/google-technical-writing-courses-fde/ Picture this sentence in a handover email: "The SSL certificate will be renewed before the 15th." It sounds tidy. But on the 16th, your team and the customer's team may both discover that neither side thought it was the one doing the renewal. Google teaches engineers to avoid exactly this kind of mistake in two courses, Technical Writing One and Technical Writing Two. Both are free and hosted on Google for Developers (developers.google.com/tech-writing). You do not need to be a professional technical writer: the courses are aimed at software engineers, computer science students and adjacent roles such as product managers. Imagine the deployment ends and you move on to another project. The spec, the runbook and the handover email stay behind, and the customer's team has to run the system using only what you wrote. If the documents force them to call you with questions, the deployment is not really finished. ## Why does Google teach engineers to write? An article in tcworld by Dirk Göhmann, published in March 2022, gives a blunt reason: demand for documentation far outstrips the number of technical writers available. With nobody to write it for them, engineers have to write it themselves. In a post on the Google Developers Blog on 9 July 2020, technical writer James Scott added another point: as remote work spreads, good documentation matters more because it lets engineers work independently. For FDEs, this is even truer. When the customer's team needs an answer, the person who wrote the document is usually no longer sitting next to them to explain it. According to the official changelog, both courses were announced on 24 February 2020. Technical Writing Two was last updated on 15 April 2024, when a summary slide was added to each exercise. Each course has two parts: self-study lessons to complete before class, and an in-class session with an instructor and other learners. ## Technical Writing One: two ideas worth keeping Technical Writing One is the foundational course, teaching you to write clearer technical documentation. According to its introduction page, you only need basic written English. **The first idea is to define your reader by what they are missing.** The lesson on audience stresses that a job title is not enough to describe a reader. A document must supply the information readers need but do not yet have. It also warns that experts easily forget that newcomers do not know what they know. Take two data engineers on the customer's side with the same job title. They may not need the same document. One has used the message queue you chose; the other never has. Before you write, list three things your reader does not yet know, then check that the document explains all three. **The second idea is to use the active voice.** The lesson on active voice recommends writing mostly in the active voice. The reason: some passive sentences drop the actor entirely, leaving the reader to guess who does the work. The SSL sentence at the top of this article is one. Rewrite it as "Minh's infrastructure team renews the SSL certificate before the 15th", and the sentence grows by only a few words but now has someone responsible. **Key point:** An instruction that does not say who must act will not be acted on. ## Technical Writing Two: for long documents Technical Writing Two is the intermediate course. It covers self-editing, organising long documents, writing captions for illustrations, writing tutorials and, more recently, using LLMs when writing. Google advises anyone new to technical writing to take One first. **The third idea comes from the lesson on organising large documents:** a document's opening should state what it covers, what the reader needs to know beforehand, and what it does not cover. Take a runbook for pipeline incidents. You might open it like this: this runbook explains how to restart a stuck ingest job; readers need to know how to use kubectl; it does not cover corrupted source data. The last line looks like an excuse, but it is genuinely useful. It tells the on-call engineer when to stop reading and switch to another document, instead of following steps that were never meant for their situation. ## Where do people still go wrong after the course? The most common mistake is switching a sentence to the active voice while leaving the subject vague. "The customer side renews the certificate" is grammatically correct, but the reader still has to guess which team. A subject only helps when it is a specific team or person that everyone recognises. The next mistake is writing one document for everyone with the same job title. That is precisely the trap the audience lesson warns about. The simple fix: if your readers have different backgrounds, move the background material into its own section so those who already know it can skip it. The third mistake is writing the opening but leaving out the "what this document does not cover" line for fear the document will look incomplete. To catch all three, hand your draft to a colleague who has never seen the system, and note every place where they have to ask you a question. ## In what order should you take them? If you are an FDE or preparing to move into the role, take One first, even if you think you already write well. After each lesson, apply it straight away to a real document rather than saving it for the end of the course. Two is most useful when you are about to write a spec or a handover document several pages long. Writing can also serve as evidence of your ability when you apply for jobs. Rewrite an old runbook, remove the customer's confidential information, and put the before and after versions in your portfolio. On your CV, state the specific job the document helped get done. When you interview for an FDE role, bring that pair of runbooks. In a take-home round, submit a README with the full three-point opening. In a system design round, when asked how you would hand over to the customer, open the after version and point to the "cases not covered" line. That is far more persuasive than "strong communication skills". A deployment is only truly finished when the customer's team can handle its first incident without calling you. These two courses teach you to write documents that make that possible. **Try this week:** - Open your most recent handover email and find every passive sentence that does not say who does the work. Rewrite each one, naming the responsible team or person. - Add three sentences to the top of a runbook in use: what this document covers, what the reader needs to know first, and what this document does not cover. - Finish the self-study part of Technical Writing One and apply it straight away to a real customer document. ## Sources - [Technical Writing Courses (Google for Developers)](https://developers.google.com/tech-writing) - [Technical Writing One (Google for Developers)](https://developers.google.com/tech-writing/one) - [Technical Writing Two (Google for Developers)](https://developers.google.com/tech-writing/two) - [Log of changes to technical writing courses](https://developers.google.com/tech-writing/for-instructors/release-notes) - [Free technical writing courses (Google for Developers)](https://developers.google.com/tech-writing/announcements) - [Audience (Technical Writing One)](https://developers.google.com/tech-writing/one/audience) - [Active voice (Technical Writing One)](https://developers.google.com/tech-writing/one/active-voice) - [Organizing large documents (Technical Writing Two)](https://developers.google.com/tech-writing/two/large-docs) - [Teaching the art of great documentation](https://developers.googleblog.com/2020/07/teaching-art-of-great-documentation.html) - [How (and why) Google teaches technical writing to engineers](https://www.tcworld.info/e-magazine/column/how-and-why-google-teaches-technical-writing-to-engineers-1172)