> which reads like a potential issue with their own ego: where they didn't want to be shown up in an unfamiliar UI
> What there should be is shame ... those who don’t offer up their help to others
I read it more as, I don't want to be become L1 Tech Support for something I don't know either.
What happens when the GP runs into an issue themselves. Do their colleagues help him or return the same cold shoulder?
Computers are sufficiently advanced that there will always be blind spots in your team. Sometimes that means working together as a team to figure them out. Which is the kind of behaviour a good manager should encourage and the sort of attitude a good senior engineer should have already learned.
The issue isn't the technical complexity, it's the office politics.
If they fix it, do they then become responsible for fixing it in future? Is this now a "responsibility" the "company" (coworkers) expects of them, with no compensation? In addition to their existing responsibilities?
I introduced git to the company I'm at (previously on SVN running on an old beige box in the corner).
It made collaboration easier. I accepted the fact I'll get pinged whenever someone makes git do a weird thing, but I'm lucky that for the most part coworkers learn from these incidents rather than coming back each time with the same issues.
Again, it shouldn’t be a matter of office politics. If you have a healthy team then everyone will chip in their individual strengths. Yours might be git but someone else might be stronger with Bash, package management, or whatever. Eventually you end up with everyone helping each other. So while you might get interrupted occasionally for git queries, you’d save hours on another issue that someone else helped you with.
There should also be schemes in place to help people level up their own skills. Whether it’s organised training days or an acknowledgment that x number of hours a sprint is spent on personal development (A Cloud Guru or whatever).
If a company doesn’t set up those two pillars then they risk creating toxic teams and that’s ultimately more harmful for productivity than any lost time in a given day helping a peer with version control.
Source: been a hiring manager at several companies. Seen what works and what doesn’t. Ultimately a closer team almost always out performs one where individuals are only looking out for themselves.
I read it more as, I don't want to be become L1 Tech Support for something I don't know either.