Recipe for a good readme
Tags: codenewbie, beginners, writing, webdev
Published: 2020-05-08 23:12:36

Good project readme is a good practice in code documentation and also helps you stand out when looking for a job. Here are some tips & tricks for writing one.

***

## Table of contents:
- [Write it well](#1-write-it-well)
- [Include title, description and table of contents](#2-title-description-and-table-of-contents)
- [Explain setup and stack](#3-setup-and-stack)
- [Know your audience](#4-know-your-audience)
- [Mention the license](#5-license)
- [Shout out contributors](#7-contributors)
- [Invite contributions](#6-contributions)
- [Explain next steps](#8-next-steps)

***

## 1. Write it well
Good documentation isn't boring or unapproachable. Quite to the contrary —  good docs will make it easy for the user to follow what's being written. You don't need tech vocab — in fact, you are better without it. Plain English will suffice. In fact, the reason why people **love** [React docs](reactjs.org) is because they are so well-written: split in digestible chunks, written in plain English, with good links. 

You can also allow yourself to find elaborate analogies. A student of mine was really excited to find [this bit](https://ruby-doc.org/stdlib-2.6.1/libdoc/date/rdoc/DateTime.html#class-DateTime-label-When+should+you+use+DateTime+and+when+should+you+use+Time-3F) in otherwise pretty boring and technical Ruby docs. 

## 2. Title, description and table of contents
They should be concise and reflect what the project is about. Here is a readme I wrote for [Covid-19 risk calculator](https://github.com/sruti/covid19-riskfactors-app), one of the projects I worked on. You know from the get-go what to expect from the project. Moreover, the attached table of contents makes it easy for the user to navigate to the appropriate section.

## 3. Setup and stack
Don't assume that everyone is familiar with your app's stack, or that they remember how to get started in it. Describe how to clone the repo, how to install the dependencies and how to run the project locally. Include links to the docs of the technologies used so the user can be more independent in navigating your code.

## 4. Know your audience
Who are you writing the readme for? Is it for another dev who will take the project over? Is it for another dev who will take the project over? For recruiters? Or just for good documentation for later? Here are some examples of the `readme`s I've written with different demographics in mind:
- [for other devs](https://github.com/luanesouza/backend-lets-change-the-subject/blob/master/README.md)
- [for general documentation](https://github.com/sruti/covid19-riskfactors-app/blob/master/README.md)
- [for beginners to follow along](https://github.com/sylwiavargas/lifecycle-methods-workshop)
- [for recruiters](https://github.com/sylwiavargas/Gentrification-Map-Frontend)

## 5. License
Even though you always have full rights to your project, it's good to be explicit about it. This page is helpful in [choosing an appropriate license](http://choosealicense.com/).

## 6. Contributions
If your project is Open Source and you envision a future in which people would like to contribute to your project, specify how to do it. This is how I usually phrase it:
> Pull requests are welcome. Please make sure that your PR is [well-scoped](https://www.netlify.com/blog/2020/03/31/how-to-scope-down-prs/).
For major changes, please open an issue first to discuss what you would like to change. 

## 7. Contributors
This is handy when you collaborate with folks. I recently noticed that [Kent C. Dodds](https://kentcdodds.com/) has a very beautiful way of dealing with presenting contributors in his projects and I took inspiration from him. This code snippet:
```html
<table>
  <tr>
    <td align="center">
      <a href="https://github.com/sylwiavargas">
        <img src="https://avatars2.githubusercontent.com/u/45401242?s=460&u=2efe4366e8a6c7e8732daaaf8373250e7c8cfdd9&v=4" width="200px;" alt=""/><br/><sub><b>Sylwia Vargas</b></sub>
      </a><br />
      <a href="https://github.com/sruti/covid19-riskfactors-app/commits?author=sylwiavargas" title="Code">💻</a> 
      <a href="https://github.com/sruti/covid19-riskfactors-app/commits/master/README.md" title="Documentation">📖</a> 
      <a href="https://github.com/sruti/covid19-riskfactors-app/issues/created_by/sylwiavargas" title="Bug reports">🐛</a>
      <a href="#ideas-sylwia" title="Ideas, Planning, & Feedback">💡</a>            
    </td>
  </tr>
</table>

```
Results in this table:
<table>
  <tr>
    <td align="center">
      <a href="https://github.com/sylwiavargas">
        <img src="https://avatars2.githubusercontent.com/u/45401242?s=460&u=2efe4366e8a6c7e8732daaaf8373250e7c8cfdd9&v=4" width="200px;" alt=""/><br/><sub><b>Sylwia Vargas</b></sub>
      </a><br />
      <a href="https://github.com/sruti/covid19-riskfactors-app/commits?author=sylwiavargas" title="Code">💻</a> 
      <a href="https://github.com/sruti/covid19-riskfactors-app/commits/master/README.md" title="Documentation">📖</a> 
      <a href="https://github.com/sruti/covid19-riskfactors-app/issues/created_by/sylwiavargas" title="Bug reports">🐛</a>
      <a href="#ideas-sylwia" title="Ideas, Planning, & Feedback">💡</a>            
    </td>
  </tr>
</table>

## 8. Next steps
Or "known issues". Describe what you wish to implement or fix next if time allows. This is an opportunity for you to show that you are a self-aware dev who knows that no project is ever finished or perfect.

***
Photo by Lucas Ettore Chiereguini from [Pexels](pexels.com)