I feel just as much empathy for my colleagues. No one is wrong, or right in this situation.

You're exactly right that it ends up being, "do this, then that", and the problem with following those instructions is you learn almost nothing. You're running a playbook, and have no context as to why.

Before I did this, I followed that structure, and 6 months down the road, I had learned not nearly enough for the time frame.

So I've just stopped, and am following this approach. At the very least, I will (and do) know and understand a lot more. At the cost of being a complete deliverable sink.

The issue around communication is that, I really don't understand what is being said often. Essentially the things that people (rightly) assume is base knowledge, is not base knowledge for me.

So the only way to get there, is to really study, take courses, learn about and rip apart what these things mean. And that takes time. Lots and lots of focused, intentional time.

Now I'm building the foundation, and I'm learning a lot more, but I'm delivering a ton less. It's a challenge, but I will take responsibility for that, and just keep working hard to get better.

Another view: Fucking up teaches you _way_ better lessons that studying and coursework.

I often joke that the reason I get paid what I do is because of all the expensive mistakes I've already made on some other companies dime. A big part of my role as and older/senior tech guy, is to tell war stories carefully selected and curated to give very strong hints about how my less experiences junior devs are about to get things wrong.

Some people never learn from other's mistakes - but if you've got expensive mistake stories to share, try very hard to ensure the people smart/perceptive enough to benefit from them get to hear about them... Give them the chance to "stand on the shoulders of giants" (even standing on the shoulders of ordinary people is better than making the same dumb mistakes they've already learned from...)

I tend to agree with you that fucking up teaches way better lessons, but it requires a foundation.

I'm an older/senior guy as well. The difference is that, I decided to accept a role, that changed into a role doing something I had never done.

I was never a programmer, and I accepted a role that unknowing to me, ended up being a development role. I decide that it would be fun to become a developer, and explore this world.

I would be considered an expert in other similar fields, but not this field. The biggest misjudgement on my end was that I didn't understand how far behind I would be. I assumed it would take a lot of effort, and drive, but I completely missed how much it would take to become competent.

Still enjoying the experience, and am getting very excited towards a future where I can deliver and be relied on for critically important things.

Oh sure. Three decades worth of fuckups isn't something you can get in a bootcamp...

But I think understanding that the greybeard over in the corner has those three decades, and that even if they fucked up using Perl running on hardware they physically touched/owned - they probably learnt some critical lessons that directly apply to your $language-de-jour running on $cloud-platform-of-the-week...

Become the person who'll get told, and listen too, their war stories...

> However, either I overwhelm them or they don't want to put in the effort

I've seen both of these a lot. Eventually you end up classifying coworkers as "people who want to learn" and "people who try and get you to do any difficult work for them".

I will dial down the overwhelmingness and dial up the helpfulness a _lot_ if you land in the "eager to learn" group. If you regularly show yourself to be in the "do my work for me" group, I'll eventually just throw you some keywords to google and point out that I'm busy getting through my work (possibly while Ccing your boss if I'm in "a mood" or if you do this all the damned time).

I have a coworker who is similar to this. Not so much "do my work for me" group, but very much in the "will ask you for help and then turn down anything you tell them, while still getting it wrong".

Let's pretend our infrastructure is a home kitchen with a failing microwave oven.

"Hey, why isn't this button on the microwave working?"

"Because that's a refrigerator, not a microwave"

"No I KNOW it's not a microwave, but how do I get it to heat up my lunch?"

"Refrigerators don't heat things..."

"Sigh I know how microwaves work, why isn't THIS one working?"

I really wish I were being hyperbolic about this, but I'm not. Lately I've taken your tactic and just throw them keywords and proffer that I'll help them out when I can break away from other items. It hasn't failed that after a couple of cycles they'll say "Hey you were right about that microwave" and in my mind I'll say "no kidding".

On a darker note: there's quite a few of us who don't think this engineer is long for the company (they were hired only a few months ago).

So the company you works at wants to pay people to make them money. When people start at a new job there's often a ramp-up time until they become productive and usually a second period until they're stable enough to lead others, but if someone is stuck in that negative efficiency state then it is something you should pass up the chain. If you're an experienced dev who is spending four hours a day holding the hand of someone new to the company that's an investment but if it's still going on months later then your manager will want to help the situation so that you can use your own time productively.

It's a hard situation and I've been lucky that I haven't been stuck with anyone who can't overcome that initial learning phase, but if you find yourself there you should try and unload the problem to people more HRy and save yourself the stress.

(All the above, BTW, is not to imply that one-person rockstar programmers are a thing (they aren't) and skills vary, I am only talking about extreme scenarios)

Personally, I'll cut "the new hires" a lot of slack.

"A few months" is way within the "still trying to work out who the fuck they are and how they fit in".

If they haven't bailed on the company in ~12 months, but are still asking the same lack-of-understanding-questions they've been asking all along, that's when I redirect my effort/energy elsewhere and dial my help back down to just offering relevant search keywords and a "sorry, I'm busy, maybe ask my boss to schedule a meeting after the end of this sprint if you still need help?" response (In writing. With an auditable paper trail...)

Which is something I haven't yet had to do as it seems a lot of relevant people are picking up on this and there are mumblings going on of this person getting the axe soon.

There have been more than one occasion where I'd find a potential solution to an issue this engineer is having, send it over to them as a helpful gesture-and I'd watch as they pull up the link, scroll immediately to where the commands are, bypassing every bit of text that gives insight into what commands are about to be ran, dependencies to interrogate before, or considerations that may be unique to a specific instance, and start slapping away at the keyboard without a clue in the world what the command they're entering is actually going to do.

I think it's less a skills gap but an issue with someone who is baked into their ways and hasn't been shaken loose from them on a more functional team.

when seeking help from colleagues it is more beneficial to take the form of student instead of dictator, for the current task as well as future tasks.

edit >> (unless you work with assholes that see the student form as a sign of weakness)