Ask HN: Do you document your development process?

I personally have to write down things and try to convince everone else to do that but I have to deal with people who more or less actively seems to be avoiding leaving anything written behind.

I almost always document how to set up a good development setup (live code reloading, tests running, decent error reporting, you know the drill), and how to create a production build (these both should be a single line on the command prompt). Aside from these I tend not to document anything else about the development process -- not for any specific reason, though. I don't expect anything else to be a big time saver until I end up on a team with more than 3 people working on the same codebase.

When developing, I try to think what it'll be like to return to the project in several months and how hard it would be for someone new to start contributing to the project. I try to document everything I think that will help and, even better, automate those steps with scripts. For example, deploying to staging or production should ideally be a single command so if the documentation for this grows too lengthy I'll take steps to automate it.

We have an onboarding tutorial for new hires at work where we cover stuff like deployments, code review procedures, and coding style.

We intentionally keep this separate from the code and leave it in Confluence docs because it was important to both engineers and semi-technical (QA and Product) staff. The latter group is very concerned about how hotfixes are deployed but is unlikely to look at anything on github.