Adding a new smart person to the team is one of those golden moments for a team, IMO. You get a tiny window of watching them struggle until the tribal team knowledge seeps into them by osmosis. During that time they don't yet know who to ask the questions to directly so they will post to team slack channels or the lead directly.
One must capitalize on this brief period because smart programmers are flexible and adaptable. Very quickly they will acclimatize themselves to the mess that surrounds them and they will become as blind to the deficiencies as the rest of the team.
Adjacent to this: ignore criticism as feedback, but treat questions as feedback.
People who don’t “get” the code ask questions that contain feedback they often don’t even register as feedback. By the time they distill it to an actual criticism, they’re often so wrapped up in the problem they can’t be constructive, or they present an XY problem. But if three people ask you the same question about your code? You have a design issue. Fix it. Fix it now.
That puts me in a weird relationship with FAQs. FAQs aren’t informational, they’re confessional. Here’s all the times I fucked up and won’t admit it. Let me explain why I am right and you are wrong.
Funny enough, many organizations will actually punish questions due to optics, noise, or RTFM (which fair enough do read it, but also don't presume the asker didn't just because you understand what you wrote. Being written down doesn't mean it's understandable by a new reader, or that it's optimally setup for discovery)
One must capitalize on this brief period because smart programmers are flexible and adaptable. Very quickly they will acclimatize themselves to the mess that surrounds them and they will become as blind to the deficiencies as the rest of the team.