Carmen Chung
How To Write Tech Documentation That Will Save Your Career
Summarized using AI

How To Write Tech Documentation That Will Save Your Career

by Carmen Chung

In this RubyConf AU 2020 presentation, Carmen Chung delivers valuable insights on writing effective technical documentation that can significantly impact a software developer's career. She illustrates the importance of robust documentation through the story of Kira, a junior developer at Big Tech Co, whose first day was marred by confusing and outdated internal documentation.

The video begins by emphasizing the real-life consequences of poor documentation, referencing a Reddit post by ‘CS career throwaway 567’ who destroyed a production database on their first day due to inadequate guidance. Through Kira's experience, Carmen outlines key strategies for creating beneficial tech documentation:

  • Choose Appropriate Titles: Titles should be descriptive and easily searchable. Kira struggled to find information because the document was called 'Document That Explains Everything,' which is neither helpful nor specific.
  • Provide Clear Structure: Documentation should include an index or table of contents, and break down lengthy content into manageable sections with navigable headings. The absence of such structure made Kira’s 600-page document overwhelming and non-functional.
  • Regular Updates: Keeping documentation current is essential. Kira's document was outdated (from 2007) and led to compatibility issues. Incorporating documentation updates into regular workflows can prevent similar situations in the future.
  • Utilize Clear Code Examples: Properly formatted code samples can aid comprehension. Kira's confusion stemmed partly from poorly formatted commands which did not clearly separate instructional text from executable code.
  • Detailed Commit Messages and Documentation: Clear communication regarding changes, such as commit messages and pull requests, ensures that all team members understand updates to any project. Carmen illustrates this through Felicity's frustrated response to Kira's mistake, which could have been mitigated with better documentation practices.

Carmen concludes the presentation by reiterating that effective documentation leads to better communication, less confusion, and ultimately saves careers. She strongly advocates for an organized and collaborative approach to writing, maintaining, and updating technical documentation.

Carmen invites developers to prioritize clarity and structure in their documentation efforts, ensuring that both they and new hires are equipped to succeed.

00:00:00.329 Our next speaker is Carmen Chung. Carmen is a software engineer, writer, and conference speaker with a reputation for breaking other people's code. Prior to her move into tech, she worked internationally as a corporate lawyer for almost seven years.
00:00:07.750 During the day, she is a software engineer at Valiant Finance, and at night, she is the host and producer of a YouTube channel called CodeFights, which teaches people how to solve coding questions in 15 minutes.
00:00:14.400 She was also recently selected as a finalist in the Rising Technologist category of the 2020 Tech Playmaker Awards. In her spare time, she teaches flexibility classes, creates often absurd side projects, and fosters rescue dogs, currently mostly greyhounds.
00:00:20.130 Please put your hands together and welcome Carmen.
00:00:50.420 Thank you very much for the warm welcome, Caitlin, and thank you to Commencent for having me here. It’s such an honor to be on stage. Today, we’re going to talk about how to write technical documentation that will save your career. I know what you're thinking: that sounds pretty over-exaggerated, but I promise it's a real concern.
00:01:03.149 Let me take you back to 2018 when a junior software developer with the username 'CS career throwaway 567' posted this on Reddit: 'I accidentally destroyed the production database on my first day of work and was told to leave. On top of this, the CTO said they needed to get legal involved. How screwed am I?' Remember this headline; we’ll come back to it in just a moment.
00:01:22.310 But first, let me introduce you to the newest member of Big Tech Co. This is Kira. It’s her first day ever working as a junior software developer, and she’s super excited. She turns up at the office where she is greeted by her product manager, Franco. Franco looks a little stressed. He gives Kira a laptop and instructs her to log in and go to Google Drive to find a document that explains everything.
00:01:56.040 After he disappears, Kira turns on the laptop, signs in, and starts looking around in Google Drive. She searches for titles like 'new starter', 'new hire', 'employee orientation guide', and 'first day at work guide', but can’t find anything.
00:02:10.979 After hours of searching, she decides to send Franco a Slack message, asking if he can point her in the right direction of the Google Doc that explains everything. Over an hour later, Franco responds, indicating that she is still not set up and linking to a document called 'Document That Explains Everything 2007'.
00:02:48.359 Kira opens the document, and it’s 600 pages long. There’s no table of contents, no index, and no headings. As she looks through it, she discovers that Big Tech Co has a variety of repositories, some using Python and others using Ruby on Rails.
00:03:01.019 Finally, buried on page 362, she finds some terminal commands that she needs to run in order to get the repo. Feeling confident, she opens up the terminal and runs the first command only to encounter an error.
00:03:36.890 Uncertain of what the error means, she decides not to bother Franco after his last response. Instead, she sends a message to Felicity, her senior software developer, asking for help with the error she received while trying to install the repo.
00:04:03.380 An hour later, Felicity replies that Kira still isn’t set up because her machine has Python 2 installed. Kira needs to be on Python 3. Once she installs Python 3, she successfully gets the repo.
00:04:17.780 As her first day winds down, Kira really wants to finish her orientation checklist, so she runs the next command, which tells her how to create the database. It returns a URL, username, and password, just as the document said.
00:04:45.979 However, something seems off. The screen displays her name alongside some gibberish. Feeling nervous, Kira is unsure if this is correct. Not wanting to stray from the document, she decides to run the command to seed the database with the URL, username, and password provided.
00:05:06.440 After running the command, everything seems successful, and she thinks everything is fine. Kira shuts down her laptop and heads home for the day.
00:05:38.910 However, an hour later, she receives a call from Felicity, who is livid. 'You just wiped our production database!' Felicity shouts. 'Don't come back to the office tomorrow.' Let's pause here. I want to look at what happened and how things could have gone differently.
00:06:04.030 In doing so, I'll offer you some tips for writing tech documentation that may save your career—or the career of someone else. Tip number one: pick your document titles carefully. Remember, Kira searched for all the relevant titles, and she couldn't find the document because it had a very unhelpful title: 'Document That Explains Everything'.
00:06:29.610 Make your documents easy to find. If they’re not found, they won’t be read. Think of your document like it's going to be indexed by a search engine. Make it SEO-friendly. For example, 'How to Remove Columns from Our Database' is very clear and easy to find.
00:06:56.690 When I say search engine-friendly, I don't mean clickbait titles like 'Four Ways to Remove Columns from Our Database: The Final One Will Shock You.' This may be hilarious, but unless your developers are reading documentation like they're perusing a magazine, this is not the way to go.
00:07:22.230 Tip number two: provide a clear structure. Remember that 600-page document Kira was reading? It had no index and no headings, making it poorly structured and hard to follow. You need an index or a table of contents that is clickable, allowing users to navigate easily.
00:07:53.410 Additionally, offer an introduction, especially if your document is lengthy. This introduction should summarize what the document covers so that readers do not waste time if it doesn't answer their questions.
00:08:17.940 You could also include a 'to long; didn’t read' section for those who might prefer to skim. If your document is extensive, consider breaking it down into multiple sections and linking them together, just like you would with large codebases.
00:08:42.900 For example, a document titled 'How to Run Database Migrations' could provide an outline on the side with clickable headings. In the introduction, it could outline the specific migrations relevant to it. This way, developers can quickly find what they need in a lengthy document.
00:09:04.950 It's also nice to include specific errors, like a Postgres error stating that a column does not exist, as this can help readers troubleshoot common issues they're searching for in documentation.
00:09:30.360 Tip number three: update regularly. The guide that Kira found was dated 2007. That’s ten-plus years without updates, which rendered that documentation useless when Kira needed Python 3.
00:09:49.740 Encourage your team to incorporate updating documentation into standard practice. Where I work at Valiant, we have a pull request template that includes a checklist item asking: 'Have you written or updated any necessary documentation?'
00:10:17.030 If everyone does their part to keep the documentation current, it makes the whole process much easier. Here’s an example of a living document that has undergone continuous updates by several team members, making it an evolving part of our workflow.
00:10:53.780 Now, back to the situation at Big Tech Co. Remember that Kira ran the seeding script and ended up wiping the entire production database and filling it with fake data? Tip number four: make the most of code examples.
00:11:21.490 Remember, the documentation Kira accessed didn’t have any code formatting, which made it confusing. You need to format your code clearly, ensuring that it’s evident what is part of the command and what is just instructional.
00:11:51.950 It's essential to also explain what the code does. For example, stating 'Run pip install big tech code repo in terminal, which will install our entire repository in the current folder' makes it easier for less experienced developers.
00:12:14.300 And remember, never include your production credentials in documentation. They should be stored securely in a password manager, especially since documents can be easily shared externally with shareable links.
00:12:37.300 It’s crucial to clarify that Kira should have been told, 'Run the create database command, which will generate the credentials for you.' Instead, the document had her actual production credentials—incredibly risky.
00:12:47.600 Back to the beginning of the day: Felicity is already grumpy because she must review a crucial demo site being prepared for an important investor presentation. She doesn't have the details and the project was created by her ex-colleague.
00:13:05.160 Franco, the product manager, had asked Felicity for a final review of the pricing tier feature, but the project was built using Ruby on Rails, a language Felicity does not specialize in.
00:13:28.890 Diving into the codebase, Felicity sees the pricing model has associations with 'users' and 'accounts'. This confuses her since Big Tech Co primarily deals with companies, not individual users.
00:13:50.290 Asking Franco for clarification, he instructs her to review the specification, but she can’t find it anywhere. Meanwhile, production goes down because of Kira’s actions, which causes even more stress.
00:14:18.000 Felicity decides to remove all references linking 'users' with the pricing tier, not knowing that the pricing tier should actually relate to users based on recent changes discussed with Franco.
00:14:38.640 After pushing the code, Felicity gets a call from Franco, who is furious that she has disrupted his important demo. Neither of them knows how they got into this mess, which is a prime example of the fallout from inadequate documentation.
00:14:55.970 Now, let’s talk about refining your commit messages and pull request descriptions. Clear, concise commit messages help convey what was done without unnecessary noise, while detailed pull request descriptions inform others about changes.
00:15:25.880 For example, the commit message should summarize what has changed succinctly, while the pull request should detail what was done and might include a checklist of items worked on.
00:15:54.300 In the case of Donald's pull requests, they lacked clear descriptions and details. He should have specified the previous associations and what he intended to do with them.
00:16:23.000 Clear communicationin tickets is essential. For example, stating the specifics of what needs to be done, such as creating new pricing tiers and updating their associations, can prevent confusion and mistakes.
00:16:44.900 Equally important is keeping track of discussions in accessible documents or comments on tickets. If Donald had noted that Franco specified changes about the status of the pricing tiers, it would have prevented the miscommunication.
00:17:11.480 To summarize, clear communication in documentation impacts the success of projects significantly. Ensuring everything is noted down in an accessible way allows everyone to track changes and responsibilities.
00:17:42.130 Be precise and detailed in your specifications. Clarity helps tremdously in software development, especially in multi-faceted environments where many people are involved in projects.
00:18:12.960 Returning to the original story, Franco's critical demo failed because he did not set the pricing tier to the correct active state. His failure came from ambiguous communication and documentation.
00:18:43.510 Remember that cryptic comment, 'don't forget what we discussed about the status'? This should have been more clear in explaining that the active status needed to be reactivated.
00:19:09.310 In conclusion, when writing documentation, remember to pick accurate titles, provide a clear structure, keep documents updated, use clear code examples, and detail specifications.
00:19:36.780 Focus on who, what, where, and why for everything you write in project tickets, and maintain a living document atmosphere where all team members contribute.
00:20:01.420 Thank you RubyConf Australia for having me. It's been an honor, and I encourage you to look at the presentations from Nadia and Tekken from last year.
00:20:15.429 You can also find me on Twitter, where I will be sharing a sample PR template and a blog post recapping today’s presentation. Thank you very much.
Explore all talks recorded at RubyConf AU 2020
+15