Developer experience

Documentation

Keep your project and code base documented to make sure updates can be managed smooth over time.

Code comments

For the most of the time, code should be self explanatory. But of course, there are cases where some comments are appropriate. Think if you would return in a year to your code and where it might be hard to follow what happens.

// Keep comments short, start with a capitalized word and end with a dot.
// Write them in English and use a nice tone.

Readme file

Each repository should have a README.md file. This file should have information about:

  • Which Git workflow is used

  • How to get the project up'n'running for any developer

  • Any project specific information that is valuable for developers

  • How to deploy

  • Information on what keys are used and how to get them

Passwords and keys

No passwords or keys should ever be committed to the git repository. If a .env file is used, it should not be committed to the repo, but instead have a .env-example file (without real keys).

Any keys or passwords should be kept in a secure way and preferably with a service like 1Password.

It's important that all keys and password are stored somewhere to make sure future developers have access to them.

Project documentation

Other information about the project should generally be documented in a project management system.

To do

  • Project has a README.md file with developer information on how to get the project up n running.

  • Any passwords and/or keys are saved in a password manager.

  • Any general project information are saved in a project management system.