A few things have to change as a software team grows.
Your code organization system might be entirely logical to you, but that might be because you were there when it was written. Do the module names re-use the same few words over and over? "Manager", "Handler", "Master", "Server", etc are commonly overused, meaningless identifiers but any over-used words is a symptom of the same problem: meaningless names. New programmers will have to do archeology with grep to figure out how the thing is put together. Re-using the name of the company in multiple parts of the module path to somehow distinguish two parallel code hierarchies similarly creates confusion rather than organization. If a module lacks a meaningful name, it lacks a clear distinction for what goes in there as opposed to somewhere else. Also, the module names will start to sound like Monty Python's "Spam" skit. "Oh, did you mean to edit Data Manager Manager Manager Data Manager or Manager Manager Data Manager Manager Data Manager?".
Using a chat channel is generally a good idea. However, if new programmers are supposed to draw on the entire dev team for help rather than having any sort of per-project or general mentoring system, you have a lot of broadcast overhead. You also put each programmer in an awkward position of deciding at what point to finally step and help rather than hoping another has more time and knowledge of the matter.
There's a whole code standards thing. This combines with the organization problem. A new organization system will develop for each new programmer's limited understanding of the existing organization system. More broadly, are future programmers going to be even more bogged down? And what's going to be the priority then?