I've documented how to onboard to my team and start doing dev work, and have received positive feedback from new team members as well as people who have been around a while and are starting to work in my area, saying that it was easy to follow and they went from 0 to coding in under 15 minutes.
So it can be done. The how is less about tools and process and more about simply making it a focus. I consider documentation of how to work with the codebase to be as much a core feature of the product as anything customer-facing. It is maintained, tested, and updated as deliberately as any other feature, and we log bugs on it and call out missing updates in PRs.
I use the README in our primary repo to be the starting point, and link to other places as needed. I include all the pre-reqs and instructions to get running, without assuming anything is already on their system or they know anything about our organization. Or even what OS they are running. And I include a goal-based list of FAQs - How to add a model, create a new API endpoint, change front-end routing, create new front-end components, tie everything together into a new feature, etc. How we branch, how we interact with PRs, team standards and norms, etc.
Exactly what your docs say will vary based on what type of work you are doing, but the key is to make documentation a primary feature of the product, and treat it as such when testing and reviewing code.
So it can be done. The how is less about tools and process and more about simply making it a focus. I consider documentation of how to work with the codebase to be as much a core feature of the product as anything customer-facing. It is maintained, tested, and updated as deliberately as any other feature, and we log bugs on it and call out missing updates in PRs.
I use the README in our primary repo to be the starting point, and link to other places as needed. I include all the pre-reqs and instructions to get running, without assuming anything is already on their system or they know anything about our organization. Or even what OS they are running. And I include a goal-based list of FAQs - How to add a model, create a new API endpoint, change front-end routing, create new front-end components, tie everything together into a new feature, etc. How we branch, how we interact with PRs, team standards and norms, etc.
Exactly what your docs say will vary based on what type of work you are doing, but the key is to make documentation a primary feature of the product, and treat it as such when testing and reviewing code.