4 ms·

At one of my old gigs, I asked my then-colleague a bunch of questions about the codebase for a task I was assigned. He was always like "you are a senior resourc

At one of my old gigs, I asked my then-colleague a bunch of questions about the codebase for a task I was assigned. He was always like "you are a senior resource, you should not ask such questions; if you want to find answers, look into the code itself." This is how he keeps his status and job at that company, and he is still there now. When I enquired around about how he got that tribal knowledge of that codebase, I got a fascinating answer: he asked his ex-colleagues at the same company, the same kind of questions I asked. Unless one joins as an intern at some company, there are gatekeepers in most of the companies, who don't want to train you at all. Instead, they criticize any attempt to find answers as "hand-holding, fake, inexperienced, etc."

throw14082020 6y ago
> there are gatekeepers in most of the companies, who don't want to train you at all. This is fear mongering for the juniors. Most people don't help because they don't get asked. Juniors, reach out and I will help. I'm the kind of person that is sociable and helpful anyway though.
- phlipski 6y ago
  There are plenty of people who have "closed the drawbridge behind them once inside." They don't want to help, or think that you should figure it out yourself or should already know the answer etc.... They forget that they were newbs once too.
- cosmodisk 6y ago
  It goes both ways,I suppose. I'm more than willing to teach anyone who is willing to listed what I know, but some mutual respect is needed. I remember a meeting, where I got asked to get someone up to speed with some core concepts. I thought,OK, that's fantastic.I prepped the plan, go to him and tell it'd take him about 20h of his own time to go through the stuff.. 'Oh no, I thought we'd be done in 2 hours'.. Sure, I can teach you in 2 hours what took me 5 years to learn..
- oblio 6y ago
  It varies widely by company and by person. The unhelpful senior trope is not a myth.
splithalf 6y ago
Learning “on the job” is an anachronism from the days when companies invested in their employees and employees stayed in the same organization for their entire career. We’re moving towards the gig model, even calling programmers “rock stars” to sell it.
- totalminimalist 6y ago
  This is profoundly true. It's also one of the reasons I want to get out of IT after 20 years. I'm past the point where I'm tired of the meetings, false niceties, and desire from management to submit to the hive mind. Nothing worse than stand-ups, Teams or Google Meet meetings. No one wants to be in them. It takes time away from my job where I could actually be productive. This is why I really like the videos from Patrick Shyu on YouTube (Tech Lead). He gives the skinny on working for companies like FAANG and in general. I don't always agree with everything he says, but I've seen much of what he says.
  - deleted 6y ago
    [deleted]
  - Blackstone4 6y ago
    Honestly, I feel like much of what you don’t like applies to other industries as well and is not tech specific... human nature..
    - mrcartmenez 6y ago
      It’s not human nature it’s management consultancy culture. Fuck agile
- gofreddygo 6y ago
  Surprisingly a lot of folks on my past and current teams haven't figured this out yet. They still think the manager who promises them a promotion next year is going to be around by then.
Rule35 6y ago
It depends. Sometimes the answer is obscure because of our setup - like you'd need to know to look in the other repo. I'll always tell you that, and point you to the doc and the problem-list to update in case the doc is wrong. But, if you ask me a question where the answer is in the code, the proper answer you seek, in the detail you need, then I'm going to ask you to read the code first and only ask me what's left. Perhaps the story is true as retold, or maybe the original guy asked about the right things and read the code for the rest, but people watching from the outside couldn't tell and conflated it all, turning it into a story of ladder-pulling bitterness. That doesn't really ring true for me because I want coworkers taking responsibility for these odd systems (that they have to find me to ask about). But I don't want to be stuck in the role of their System-X guy who they get to do their changes. This guy's incentive would be to walk the line, educate and hand-off.
wing-_-nuts 6y ago
>you are a senior resource, you should not ask such questions; if you want to find answers, look into the code itself. You should never tell anyone they 'should not ask such questions', but I will absolutely tell you 'hey, go read this code / documentation and it will help you understand'. Mainly, I just want you to show me that you've at least attempted to solve or research the problem yourself. If you've done that I'm happy to help. Unfortunately a lot of Jrs straight out of school seem to expect to be spoon fed answers, and it makes me wonder if college has changed since I graduated.
- worker767424 6y ago
  > it makes me wonder if college has changed since I graduated. Or how you have grown since you graduated.
- hindsightbias 6y ago
  Most work knowledge now is google deep, but even back to the 80’s I encountered a lot of college grads who did not want to read the code. A lot of it is intimidation, they’d never seen a printout stack of 50 or 100K eslocs. Kids today never start with monolithics like that but they do get swamped by the fifty layers/packages that change every year.

throw14082020 6y ago

> there are gatekeepers in most of the companies, who don't want to train you at all. This is fear mongering for the juniors. Most people don't help because they don't get asked. Juniors, reach out and I will help. I'm the kind of person that is sociable and helpful anyway though.

phlipski 6y ago
There are plenty of people who have "closed the drawbridge behind them once inside." They don't want to help, or think that you should figure it out yourself or should already know the answer etc.... They forget that they were newbs once too.
cosmodisk 6y ago
It goes both ways,I suppose. I'm more than willing to teach anyone who is willing to listed what I know, but some mutual respect is needed. I remember a meeting, where I got asked to get someone up to speed with some core concepts. I thought,OK, that's fantastic.I prepped the plan, go to him and tell it'd take him about 20h of his own time to go through the stuff.. 'Oh no, I thought we'd be done in 2 hours'.. Sure, I can teach you in 2 hours what took me 5 years to learn..
oblio 6y ago
It varies widely by company and by person. The unhelpful senior trope is not a myth.

splithalf 6y ago

Learning “on the job” is an anachronism from the days when companies invested in their employees and employees stayed in the same organization for their entire career. We’re moving towards the gig model, even calling programmers “rock stars” to sell it.

totalminimalist 6y ago
This is profoundly true. It's also one of the reasons I want to get out of IT after 20 years. I'm past the point where I'm tired of the meetings, false niceties, and desire from management to submit to the hive mind. Nothing worse than stand-ups, Teams or Google Meet meetings. No one wants to be in them. It takes time away from my job where I could actually be productive. This is why I really like the videos from Patrick Shyu on YouTube (Tech Lead). He gives the skinny on working for companies like FAANG and in general. I don't always agree with everything he says, but I've seen much of what he says.
- deleted 6y ago
  [deleted]
- Blackstone4 6y ago
  Honestly, I feel like much of what you don’t like applies to other industries as well and is not tech specific... human nature..
  - mrcartmenez 6y ago
    It’s not human nature it’s management consultancy culture. Fuck agile
gofreddygo 6y ago
Surprisingly a lot of folks on my past and current teams haven't figured this out yet. They still think the manager who promises them a promotion next year is going to be around by then.

Rule35 6y ago

It depends. Sometimes the answer is obscure because of our setup - like you'd need to know to look in the other repo. I'll always tell you that, and point you to the doc and the problem-list to update in case the doc is wrong. But, if you ask me a question where the answer is in the code, the proper answer you seek, in the detail you need, then I'm going to ask you to read the code first and only ask me what's left. Perhaps the story is true as retold, or maybe the original guy asked about the right things and read the code for the rest, but people watching from the outside couldn't tell and conflated it all, turning it into a story of ladder-pulling bitterness. That doesn't really ring true for me because I want coworkers taking responsibility for these odd systems (that they have to find me to ask about). But I don't want to be stuck in the role of their System-X guy who they get to do their changes. This guy's incentive would be to walk the line, educate and hand-off.

wing-_-nuts 6y ago

>you are a senior resource, you should not ask such questions; if you want to find answers, look into the code itself. You should never tell anyone they 'should not ask such questions', but I will absolutely tell you 'hey, go read this code / documentation and it will help you understand'. Mainly, I just want you to show me that you've at least attempted to solve or research the problem yourself. If you've done that I'm happy to help. Unfortunately a lot of Jrs straight out of school seem to expect to be spoon fed answers, and it makes me wonder if college has changed since I graduated.

worker767424 6y ago
> it makes me wonder if college has changed since I graduated. Or how you have grown since you graduated.
hindsightbias 6y ago
Most work knowledge now is google deep, but even back to the 80’s I encountered a lot of college grads who did not want to read the code. A lot of it is intimidation, they’d never seen a printout stack of 50 or 100K eslocs. Kids today never start with monolithics like that but they do get swamped by the fifty layers/packages that change every year.