Tag Archives: Document


Developers tend to be really great at writing code but not so great at documenting that code. It’s not that they can’t or don’t want to, it’s that often times the effort to write that documentation isn’t captured within the scope of the requirements for the feature.

But as developers we shouldn’t let that stop us!

photo cred: Shahadat Rahman

I’ll share a couple of good reasons to document your code and some really easy ways to make it happen. While we’re at it, let’s stop using the gross word “document.” What you want to write is a solid README!

Why You Should Document Write a README:

  1. Writing a README gives you a means to not be the sole owner of that code. When you have notes around how your code works, what it intends to accomplish, and how others can contribute the project, it stands a much greater chance of getting additional buy-in from other developers and stakeholders. When you’re the only one who knows how it works, be prepared to be the only one whoever gets asked to work on it.
  2. Writing a README for your code helps you be able to come back to that code and remember that one piece of how you set it up originally. It allows you to go back 6 months later and say, “Why the hell did I do it this way… Ohhhh… right… here’s why.” Save yourself, write a README for your code.
  3. Writing a README for your code helps you think through the scope of your project and its functionality. It helps you take a step back and really consider what you’re doing and why you’re doing it. It helps you put that official stamp of approval that you’ve completed this version and it is DONE. Scope creep is dangerous, writing a README on the current state of the project and any potential future work can help keep that project from living forever.

How You Should Document Write a README:

  1. README, README, README… most source control services provide some extra functionality around writing README’s. Some really great ones like Gitlab and Github will display the contents of the README in a web browser making for easy access. If you’re not using source control, YOU SHOULD BE!. If you are using source control, you should be writing a README and including IT with your source code.
  2. There are some great README templates out there! Save yourself a ton of headache and find one that works for you. A template gives you a head start and helps you focus in on what you need to cover. It also helps maintain the scope of your README. Here’s one that I’ve used: https://github.com/othneildrew/Best-README-Template
  3. Don’t just rely on a template. Use the template as a starting point, but think about what is going to be important for your team, users, and stakeholders to know when viewing your README. Do they need to know how to set it up? Do they need to request any special permissions from anyone? Can you reference other documentation that might help give them a deeper understanding? Try to think of your README as being something you can hand to another person and they do not need to come back to you with questions.
  4. Maintain your README. As you do get additional questions on the project, update your README. Add a Frequently Asked Questions section or fix that typo. Include an area you may have missed from the first pass and encourage others to contribute to your README. Continue to build into your README as you add new functionality to your project and just remember to Keep It Simple Stupid.

README’s often get skipped over as we jump from project to project. I’ve been guilty of missing out on including them before but I’ve also seen the advantages of including them and I’m working to continue working on them.

The best place to start is to just start. Go grab a README template, paste it into your project and fill it out bare bones. From there you can build on to what you’ve started and the next thing you know, you’ll have a solid document around the who, the what, and the why.

Happy Coding!