If a workplace is split into different functions, and your coworkers in your function are not great, it can be difficult or seem bothersome to try to bond with coworkers in a different function
In companies with highly compartmentalized roles, too much work to do, and annoying co-workers, it's easy to say, "that's not my problem, go away." (With a bit more diplomacy, I'd hope.) I have always prioritized trying to be the stereotypical helpful person who might not know the answer to your question, but usually knows who to ask. The more your name comes up in the context of "who knows how X works?", the better your job security and future prospects through networking.
A lot of times that stereotypical helpful person is so helpful that junior people never learn to get rid of their dependence on that person. I know that because I've been that stereotypical helpful person. I realized something was amiss when a junior person who had been on the team for two years still came to me every other day to ask me questions. They spent minimal amount of effort thinking on their own, and then simply decided to ask me. And when I explained the solutions, they only remembered it for a short time and then one week later proceeded to ask me almost the same question again. I suppose this is the kind of proto-vibe-coder before the age of AI.
There is an amount of this that needs to happen when you onboard to a team, but as new hires become more aware of the stack and where things are documented it should happen only for genuinely complicated things and the occasional brain fart. I have a junior who frequently asks me where things live in the code when you could ctrl-f to find the answer and it's pretty annoying.
I think this falls into the category of learning how to be a good mentor.
In my case, this happened a few times. My solution to that is: whenever I get the impression that I'm becoming a critical path for someone else's day-to-day work, I start to wean them off the direct advice and start pointing them to where else they can find the answer instead. If they ask how to do X, I'll say, "Sorry, I'm a little busy with something else but here is the documentation for it. You might start by looking at Y or Z first. I'll check in later if I get a chance, let me know if you have any questions at that point."
That's when you give feedback that they should spend, say, 30 mins trying to sort the problem out for themselves before asking for help. And that they should take notes or ask over Slack so they can refer back to the answer.
