> would only give out knowledge in bits and pieces, enough for you to do your job, but not much more.

I'm curious as to how they would do this. I ask because I've seen both sides: as someone new to the company trying to understand the lay of the land and being frustrated at the lack of documentation, and on the other hand being asked for more documentation about things but not having the time to do it because of being pulled into doing other things and simply not having the time.

It also seems like most junior (for lack of a better word) developers often don't read documentation anyways, so it seems like a waste of time to go above and beyond to write docs.

HOWEVER. It is completely and totally inexcusable to build products without code review, regardless of how senior you might be. If its a spike or POC, fine. But if you're going to productionize it... you better have someone else review your code. I did see this happen and its a horrible problem: these "Senior" devs build totally unstable systems and offload them to another team to maintain; the poor team then spends most of its time putting out fires...

> 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.

I have faced the same dilemma and don’t have a good solution either. An interesting twist is that people that ask basic questions that can be looked up then “DM” me on slack. My approach has been to ignore such questions; often I legitimately lose track of them anyways, but I don’t like the approach simply because it seems anti social. Then again I am only a human; it’s hard to provide one on one assistance to everyone that asks.

> I'm curious as to how they would do this.

No documentation, testing or code reviews, selective knowledge sharing (only to some people at some times, the others might get yelled at), code that is not easy to understand on its own (not impossible of course, just hard enough that you won't bother understanding unless you really had to).

Big decisions were not really discussed with anybody except a select few. The regular developer would simply have things communicated to them e.g. from today we're using Git instead of Subversion, from next week we're doing weekly instead of monthly releases etc.

Of course, if you were persistent and really interested you would get to know more about the platform. It's just that things were made hard enough that most people wouldn't really want to do it.