> most junior (for lack of a better word) developers often don't read documentation anyways Though there are many other factors that contribute to excess relia

> most junior (for lack of a better word) developers often don't read documentation anyways Though there are many other factors that contribute to excess reliance on tribal knowledge, I consider this a huge contributor to "bits and pieces" knowledge transfer. There are many people who ask others for help immediately upon encountering a problem, and they (as a group) reliably ask the same basic questions over and over. Many ask the same questions more than once, for years on end! My honest answer to these questions is "fuck off, read the docs and don't just dump error strings into chat and rely on other people to do your job for you. Come back if you're still stuck after reading the docs with an explanation of what you tried." However, these questions are often asked in public fora, and I feel that I'll gain a reputation of being surly and not a team player if I respond earnestly: I'll give a "bits and pieces" response that probably answers the question without explaining my thought process or giving context with the aim of making the question asker go away as quickly as possible. I wish I knew how to effectively guide people into the habit of trying to find their own answers first without coming off like an asshole, but figuring that out is harder than just providing the answer. There are, of course, plenty of things that /are/ poorly-documented. Giving bits and pieces answers for those /is/ harmful. But the same question pattern happens with public tools that are extensively documented (the Python standard library or Kubernetes, for example), and it's draining to babysit people that never learned how to, well, learn.