I think most places I work haven’t had good documentation or particularly good processes for onboarding people. For instance, at some start ups we were always

I think most places I work haven’t had good documentation or particularly good processes for onboarding people. For instance, at some start ups we were always chasing a demo for customer B this week and customer C next week and people were fuzzy about what path got us there. Other places saw software as secondary or tertiary to their main business, or had a lot of turnover, etc. Or maybe we bought a web site from so and so and nobody has any idea how it works. Or the guy who made the product was pretty smart but wasn’t a good finisher and his wife just had a baby. So I am used to looking at a mysterious code base and gradually figuring out how to safely change it. When I run into something that’s particularly dangerous (e.g. how does the auth system work?) I will document it myself, and I love writing “how do I?” runbook/procedural documentation if it is likely I’ll need it in six months or will need to hand something off to somebody else. In the AI age there is a lot to say for just loading up a project in an agent-enabled IDE and asking questions like “When I do X, the system does Y, why is that?” and “How would I do Z?” and having extended conversations “well, I like D but I am concerned about E?” Or “What if we did F instead?” Even if you write every line of code yourself you mind find an AI coding buddy is more talkative than your coworkers.