I think the experience of banging your head against the wall (for a bit) can be valuable. As long as the culture of the team encourages this and offers an escape hatch after a few hours (or whatever timeframe is appropriate for the problem).
Yes. This "get it done as fast as humanly possible whether or not you actually understand what you're doing" is the most detrimental attitude toward beginning software developers I can think of. "Going down a rabbit hole" is a dismissive way of saying "actually figure out what the computer is doing" which is what actually makes you valuable to the team. If you just wanted somebody who can type in what they're told to type in, you're wasting a lot of money hiring computer science graduates.
In office, remote, whichever - I've been ignored. It took a while to learn to ask questions.
People will help, but "the squeaky wheel gets the grease", and all. There's movement [or an attempt] implied with this.
The locality doesn't matter, effective communication can exist in either.
It's possible to foster a remote environment where Juniors do ask questions - I've worked in several. As such, I'm skeptical of this 'Think of the Juniors' concern. It's manageable.
It's also worth pointing out, Junior and Senior aren't diametrically opposed. It's relative and nebulous depending on context.
I'm a Senior Architect, but know very little about the specifics of our network devices - for example. I'm Junior to our 'Network Engineering' team, making an Ouroboros of Seniority
Recognizing where strengths are helps greatly. Productive environments have their Seniors evangelizing this awareness
The top comment is saying how to manage it. TFA isn’t saying no remote work, it’s saying less frequent communication. That doesn’t work in all cases. Struggling for hours without getting much done or understanding more isn’t effective for productivity or learning by definition. These cases can often be prevented with quick questions. “Send me an email, I check it every Monday and Thursday” doesn’t support that.
This can be prevented without (net) more involvement... with better use of those existing sessions, perhaps splitting them.
The definitions on that aren't clear - the comments around seem to expect the worst, absent employers abound.
I expect a fairly guided mission, with reports on findings. Questions both ways, Socratic or not.
Don't necessarily blame the developer - there's a _lot_ of pressure from the PHB that doesn't understand the difference between HTML and Linux to "get it done right now" and they think (for no reason) that nagging somebody else to do it for you is the most efficient way to do that.
But on the other hand, I think that value comes from more than the persistence alone: it depends a lot on what you hope to get out of it. And I also say this from experience. Banging my head to “make it work” has almost always been an enormous waste of time and effort, but to “learn how/why it works [or not]” has been the exact opposite.
Learning to do things properly by banging your head against the wall is great. But only if you feel like you have the leeway to figure out how to do things properly. Without that leeway, you need the space to ask for help.
I would have loved to have been working in an environment where I could work with the system maintainers to fix their docs collaboratively but alas it was more of an "I'm busy go away" type environment.
I think this type of dysfunction was fairly common during lockdown WFH.
I've been in an environment like this, and it really burned me out.
People broke docs faster than I could fix them, and it was an accepted part of the development process.
My conclusion was that fixing the docs was simply a waste of time. My resulting despair for the software and the company surely destroyed my productivity. (I'm not saying this is a valid excuse; just an explanation.)
What did you do instead? It’s certainly frustrating to have people breaking docs that you fixed. But what else is there. You just figured it out on your own and left the docs broken?
I concluded that it was a fatal and unfixable flaw in that community / product / company. This sapped my motivation, and I'm sure resulting burnout was a factor in eventually being laid off.
One thing that sucks about being a senior dev is you're subject to Cassandra [0] syndrome. In a tight labor market, that gets painful.
Sure, reinventing the wheel every time is a valuable experience, but it's not efficient to relearn how to do things every time.
This is like letting toddlers struggle to learn how to tie shoes themselves, sure they will eventually figure it out, but it's better to just teach people have to do the basics, and let people bang their heads against hard problems.
Junior engineers aren't toddlers. Hopefully they're a lot more competent. Nobody hires toddlers to do work.
Here's my analogy: if you want to learn how to ride a bike, you've got to take off the training wheels, and sometimes that means falling over.
Not every problem is going to take junior engineers days to solve for themselves. I was stating an upper bound of how much rope to give them, not an average.
Besides, what happens when the senior engineer leaves the company? Sometimes "institutional knowledge" walks out of the institution.
It sounds like you are trying to address issues during mentoring that should have been addressed during the hiring process. In my experience, all the juniors I've worked with come in with the idea that they can solve every single issue themselves, and part of my job is to show them how wasteful that is, that a simple question can save the whole team days if not weeks worth of time.
If someone walked through the door who is not enthusiastic about solving technical issues themselves...your hiring process needs work.