32 ms·

I get you disagree with the GPs post but “noob” isn’t offensive. What’s offensive is their lack of support for colleagues (which reads like a potential issue wi

I get you disagree with the GPs post but “noob” isn’t offensive. What’s offensive is their lack of support for colleagues (which reads like a potential issue with their own ego: where they didnt want to be shown up in an unfamiliar UI). But their post reads exactly the same if you substituted “noob” for “newbie”, “junior”, “inexperience” etc. What we need to do is get passed this ridiculous mindset some have that not knowing something is a bad thing. We all have to start off somewhere and “noob” is just a common term for describing that. Case in point: I’ll readily post “noob question guys, how do I…?” on Slack to give context that I’m asking a potentially basic question and basically don’t really know what I’m doing. For reference, I am the most senior on my team and yet I have zero issue highlighting stuff I don’t know when asking for help. And that’s exactly the way it should be. There’s no shame in being new at something. What there should be is shame in wanting to mock newbies and shaming and those who don’t offer up their help to others. Being a noob should be celebrated as someone new joining the team rather than added to our dictionary of inappropriate terms.

hedora 5y ago
I don’t think they meant noob as a pejorative. Anyway, I’ve been the “resident git expert” before, and even just supporting competent CLI users is miserable once the team grows beyond 30 or so people. I can’t imagine trying to then reverse engineer and debug a half dozen crappy GUIs. Optimizing everything around developers that can’t figure out the CLI sounds like a great way to attract bozos (both by admitting bozos and by chasing non-bozos out).
- crazygringo 5y ago
  > Optimizing everything around developers that can’t figure out the CLI sounds like a great way to attract bozos What about people who have totally figured out the CLI but still prefer to use a GUI? I don't get why people act like it's either/or.
tehbeard 5y ago
> 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.
- laumars 5y ago
  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.
  - tehbeard 5y ago
    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.
    - laumars 5y ago
      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.

hedora 5y ago

I don’t think they meant noob as a pejorative. Anyway, I’ve been the “resident git expert” before, and even just supporting competent CLI users is miserable once the team grows beyond 30 or so people. I can’t imagine trying to then reverse engineer and debug a half dozen crappy GUIs. Optimizing everything around developers that can’t figure out the CLI sounds like a great way to attract bozos (both by admitting bozos and by chasing non-bozos out).

crazygringo 5y ago
> Optimizing everything around developers that can’t figure out the CLI sounds like a great way to attract bozos What about people who have totally figured out the CLI but still prefer to use a GUI? I don't get why people act like it's either/or.

tehbeard 5y ago

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

laumars 5y ago
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.
- tehbeard 5y ago
  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.
  - laumars 5y ago
    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.