I dont. Ive gone down many rabbit holes thanks to, for instance, subtly incorrect or outdated docs in working cultures that valued not being interrupted and it's a recipe for anxiety and a huge waste of time.

Hopefully you updated the docs as you encountered them and figured out the most up to date context.

> Hopefully you updated the docs as you encountered them and figured out the most up to date context.

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

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

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?

> What did you do instead? It’s certainly frustrating to have people breaking docs that you fixed. But what else is there.

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.

[0] https://en.wikipedia.org/wiki/Cassandra

I dont think I even had edit rights. I was also under pressure to do my actual job.

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.

Yep, this is learning. Asking for help is a key part. Without trying first, asking for help is asking for someone to do it for you.

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.

The locality doesn't matter, communication can exist in either.

It's possible to foster a remote environment where Juniors do ask questions - I've worked in several, and am skeptical of this 'Think of the Juniors' concern. It's manageable.

> As such, I'm skeptical of this 'Think of the Juniors' concern. It's manageable.

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.

My skepticism isn't aimed at them

This can be prevented without more involvement, just better use of those existing sessions.

The definitions on that aren't clear - I expect a fairly guided mission, with reports on findings. Questions both ways, Socratic or not.

On the one hand, I agree from personal experience. Banging my head on the wall is how I’ve learned quite a lot of what I know and developed many helpful instincts.

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.

I myself have also learned a lot from this. But I also see people doing it whilst they feel more pressure and less space to ask for help. That can lead to a non helpful state of a very quick shallow search for solutions. Anything complicated gets dismissed as 'will take too long', and you end up with completely suboptimal bodged solutions that, if anything, taught the wrong thing.

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 bang my head into the wall all the time. You just have to know which walls have a pot of gold behind them.

exactly, the most frustrating type of behavior for any colleague (esp jrs) is those who just default to consistently ask for help instead of diving deep. That behavior is costly in slowing down others. People need to learn how to learn, otherwise they will just be handicapping team if they cannot function independently. At the same time, navigating large proprietary or new knowledge sources can be tedious and sometimes impossible, but I have found that starting from the ask first mentality to be a positive feedback loop for never diving deep.

> default to consistently ask for help

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.

I think if you have a good mentor or guide in a space where there might be a proprietary system, it’s a lot easier to start being able to do those deep dives. I found that when people were able to explain the larger context for the question I was asking, I would be able to move along faster and deep dive, but with brief answers that didn’t really go beyond my surface level questions, I ended up having to ask a lot more questions, sometimes finding certain information was never documented.

Totally agree. But with newbies I feel it’s very important to check from time to time if they are banging their heads on the right wall.

It is particularly helpful if the team answers using a text format that is easily searchable (e.g., Slack). Long-term written communication is better for building a team's institutional knowledge than verbal communication. I have saved hours of work just finding URLs and documents that I had posted, let alone others.

> the experience of banging your head against the wall (for a bit) can be valuable

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.

What's worse, you're actually hurting their future career by allowing (or encouraging) them to develop bad intellectual, work, and communication habits. Borderline abusive IMO because the junior doesn't realize they've been misled until much later.

It a useless exercise to have people do so for solved problems.

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.

> This is like letting toddlers struggle to learn how to tie shoes themselves

Junior engineers aren't toddlers. Hopefully they're a lot more competent. Nobody hires toddlers to do work.

It’s just an analogy. human progress is made from “standing on the shoulders of giants” not starting from scratch.

It wasn't a good analogy. For one thing, toddlers don't tie their shoes: the average age for learning to tie your shoes is 6 years old. And it's not clear that kids will learn for themselves if you give them a few hours. We're not talking about letting junior engineers struggle for weeks or months, but they can bang their heads for a few hours or maybe even a few days and figure out a lot of things for themselves. That's a useful skill to acquire.

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.

I don't think you get it. Letting a junior engineer bang their heads for a few days on something you could show them in ten minutes is just a waste of time and money. In my experience there are PLENTY of real problems for them to solve, things I DON'T know the answer for.

You can't just consider one question and one answer in isolation. The questions and answers add up. It's a waste of the senior engineer's time to spend ten minutes each answering every question of junior engineers who are constantly asking questions, seemingly incapable of helping themselves. The senior engineer becomes a glorified babysitter, and the junior engineers then never learn to solve problems for themselves, which will waste everyone's time in the future.

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.

Yes, what happens when the senior engineer leaves the company, having never shared his or her knowledge?

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.