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

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.

> it makes me wonder if college has changed since I graduated.

Or how you have grown since you graduated.

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.

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.

Honestly, I feel like much of what you don’t like applies to other industries as well and is not tech specific... human nature..

It’s not human nature it’s management consultancy culture. Fuck agile

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.

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

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.

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

It varies widely by company and by person. The unhelpful senior trope is not a myth.

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.