4 ms·

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 escap

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

pydry 3y ago
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.
- andsoitis 3y ago
  Hopefully you updated the docs as you encountered them and figured out the most up to date context.
  - CoastalCoder 3y ago
    > 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.)
    - prepend 3y ago
      > 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?
      - CoastalCoder 3y ago
        > 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 https://en.wikipedia.org/wiki/Cassandra
  - pydry 3y ago
    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.
bravetraveler 3y ago
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. 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
- travisjungroth 3y ago
  > 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.
  - bravetraveler 3y ago
    My skepticism isn't aimed at them 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.
eyelidlessness 3y ago
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.
rocqua 3y ago
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.
eddd-ddde 3y ago
I bang my head into the wall all the time. You just have to know which walls have a pot of gold behind them.
bfeynman 3y ago
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.
- commandlinefan 3y ago
  > 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.
- kritr 3y ago
  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.
rqtwteye 3y ago
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.
biomcgary 3y ago
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.
commandlinefan 3y ago
> 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.
- nerdponx 3y ago
  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.
newsclues 3y ago
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.
- lapcat 3y ago
  > 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.
  - twobitshifter 3y ago
    It’s just an analogy. human progress is made from “standing on the shoulders of giants” not starting from scratch.
    - lapcat 3y ago
      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.
      - jewayne 3y ago
        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.

pydry 3y ago

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.

andsoitis 3y ago
Hopefully you updated the docs as you encountered them and figured out the most up to date context.
- CoastalCoder 3y ago
  > 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.)
  - prepend 3y ago
    > 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?
    - CoastalCoder 3y ago
      > 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 https://en.wikipedia.org/wiki/Cassandra
- pydry 3y ago
  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.

bravetraveler 3y ago

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

travisjungroth 3y ago
> 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.
- bravetraveler 3y ago
  My skepticism isn't aimed at them 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.

eyelidlessness 3y ago

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.

rocqua 3y ago

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.

eddd-ddde 3y ago

I bang my head into the wall all the time. You just have to know which walls have a pot of gold behind them.

bfeynman 3y ago

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.

commandlinefan 3y ago
> 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.
kritr 3y ago
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.

rqtwteye 3y ago

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.

biomcgary 3y ago

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.

commandlinefan 3y ago

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

nerdponx 3y ago
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.

newsclues 3y ago

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.

lapcat 3y ago
> 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.
- twobitshifter 3y ago
  It’s just an analogy. human progress is made from “standing on the shoulders of giants” not starting from scratch.
  - lapcat 3y ago
    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.
    - jewayne 3y ago
      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.