Funny, I just posted the exact opposite. And find that everyone reads my docs, and comes back to them frequently as they work in different areas of the codebase. Of course, we are a remote team who swaps people in and out often, so onboarding is not a one-time event where you have partners to hold your hand. If you really only onboard once and don't have a fast-growing team, I could see where the needs would not match up and we'd both be correct for our own situations.
And do you go back and update all documents whenever something changes? If you’re swapping people around every month I agree that you must keep everything written down, happens a lot in projects that bring consultants in. But if you have a core team of people and you get 2-3 new people per year then you should be more relaxed about it.
Yep, we do. It is part of the process just like testing. For the most part, it is not painful - most features are variations on existing patterns, and don't need updates. When we do code up a new pattern, we update docs.
And you are correct - we use consultants on the team, and hire in gig workers for small tasks on a regular basis. When I worked on a small core team without much churn, I did not do any of this.
