13 ms·

This sounds great for experienced engineers, but in my experience junior workers often require bite-sized guidance in order to avoid going down rabbit holes. A

This sounds great for experienced engineers, but in my experience junior workers often require bite-sized guidance in order to avoid going down rabbit holes. A 10 second conversation could easily save hours of head-banging-into-wall type work for a junior SWE (not even exaggerating). Accordingly, during the pandemic I think it was mostly the less experienced engineers suffering from low productivity and lack of confidence (which feed into each other).

fsociety 3y ago
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.
x86x87 3y ago
Oh.. The poor juniors. Instead of properly adapting the onboarding and mentoring to the remote setting let's romanticize the good old ways that imho sucked. Let's cherrypick and pretend everything is fine. We went from offices to cubicles to open space and nobody stopped to think if it was a good idea. Wr transformed the office from a place where work actually is done to a placr where we "socialize". Work? Do that on your own time.
- whateverman23 3y ago
  > Instead of properly adapting the onboarding and mentoring But... how? Remote check-ins with juniors every 30-60 minutes? That's crazy. But that's basically the only way to replicate the in person experience. The best mentoring results for me as the mentee and for me as a mentor have been when we're sitting next to each other. The mentor can visually tell when the mentee is stuck, and mentee can tell when the mentor isn't focusing on anything important and is more willing to ask for help. No matter how many times you tell junior engineers to ping you at the first sign of trouble, they're not going to do it. They're going to toil for way longer than needed, unless you're sitting right next to each other.
  - malfist 3y ago
    Who suggested checking in with juniors every 30-60 minutes? GP certainly didn't. You're arguing against a strawman.
    - whateverman23 3y ago
      Sorry I edited to include my point there. If you don't have 30-60 minute check-ins with juniors, they're not going to have the same rapid feedback that they'd get from in person mentoring. And very importantly, I'm saying 30-60 minute remote check-ins are an absolutely insane idea that should never be implemented. I don't know any kind of remote system that provides for anything even close to the power of in-person mentoring.
      - 3y ago
ResearchCode 3y ago
Those "rabbit holes" are where you learn. Saving hours is more important if you bill hourly, less if you are salaried.
- throwawayfear 3y ago
  Indeed. There may be a toxic or stupid management culture at that company if they're worried about someone going down a rabbit hole to learn. In my experience this is usually in teams that are run by people who don't have technical ability.
  - FartyMcFarter 3y ago
    Going down rabbit holes and getting something out of it is fine, but that doesn't always happen. Sometimes people are just frustrated and spinning their wheels, or doing work that turns out to be pointless because they failed to understand something which would have been clarified by a short conversation.
    - throwawayfear 3y ago
      That can be measured by frequency of code commits. You can tell which juniors are making the most of a rabbit hole and becoming better versus which ones are mindlessly surfing because they don't want to think. The first group will have things to share or talk about if they go some time without committing code and their mentor or manager starts getting worried. If someone hasn't pushed something in a week or two, that's a good time for their mentor to initiate a conversation and see where they're at and when they think they will push something. Anything else is micromanagement by a company that has hired someone without giving them any amount of runway to actually work and learn the space they're in. You can also tell on company hardware and on company accounts if the junior's browsing history represents getting better or just resting on their haunches because they want someone else to do the thinking. Let's not pretend the micromanagement cultures where "fear of rabbit holes" exists are not already doing this.
      - 3y ago
nmridul 3y ago
In my project (30+ members) we have team members located in multiple locations (6+ cities in 4 countries). And for the last 2+ years I am the only one working from my country. While our company is 500+ strong in this country, for this particular project I am the only one. So interactions with the project team is fully remote. I am sure even pre-covid many MNCs might have a similar structure with members spread across different location. Though coming to office, but project work happens remotely. Also have juniors joining the team. It might be difficult for juniors to get started. But not impossible to handle.
- Aurornis 3y ago
  > Its difficult - yes. But not impossible to handle. The problem with “difficult but not impossible” is that it requires special personality types to handle it. Some people can do it, but now you have a secondary problem in that you need to find a way to filter those people in the hiring pipeline. You also have a risk of hiring people who can’t handle it and having to cut them and re-hire. This is why most “difficult but not impossible” conditions are reserved for special exceptions but aren’t useful for general policies.
  - seattle_spring 3y ago
    Isn't the same thing true about working in an office? Certain personality types thrive while others suffer.
  - freyes 3y ago
    > it requires special personality types to handle it. I agree, and I don't see a problem with it. > [...], but aren’t useful for general policies. offices are just optimizing for the loudest and more social people, this is a consequence of managers tending to be like that, I don't think that approach is useful for general policies neither.
- no_wizard 3y ago
  I disagree its difficult. When the culture supports mentorship, onboarding and first year experience as high priority items with solid guidelines / process around them, its pretty easy. but wait, that means changing cultural and such, that's not easy is the response I often get to this, to which I say preemptively: That I would agree with, because the US business cultural is surprisingly stiff to changing things that would have favorable impact to workers, but that is IMO a different and separate discussion to the fact that this is a readily solvable problem.
no_wizard 3y ago
It doesn't have to be this way though. This sounds to me like a huge gap in communication and on-boarding process, which indirectly is a cultural problem, its not a remote work problem. You can solve this, and many organizations have. It does mean re-thinking expectations around onboarding and the role of mentorship in the company though
ramesh31 3y ago
>A 10 second conversation could easily save hours of head-banging-into-wall type work for a junior SWE (not even exaggerating). Weeks, even. It took me a while to come to terms with the fact that this is the majority of my value to an org now. Not so much in my IC abilities, but in the ability to save endless amounts of time for lesser experienced folks.
dakiol 3y ago
That's why one should hire juniors based on how well they communicate and less based on their skills to invert a binary tree or design a URL shortener service.
- ResearchCode 3y ago
  There's an abundance of people that can talk but do less. Real tech talent are rare, not that you find them by algorithms quizzes.
throwbadubadu 3y ago
That's true, but I don't see how this relates to pandemic or being remote? Also not reaching out when getting totally stuck is a bad thing, but again unrelated?
- FartyMcFarter 3y ago
  > I don't see how this relates to pandemic or being remote? There was more friction to asking quick questions, compared to being in office. This may not be the case any longer at all companies, as it's possible that some of them solved this with new communication practices.
- sokoloff 3y ago
  There is a higher hurdle to setting up a zoom call than there was to waking up to a colleague who was at their desk and didn’t look obviously busy. Solve that, and you probably solve a lot of low-grade communication challenges that are made worse by being remote as compared to in-same-office.
  - throwbadubadu 3y ago
    A 10 second convo is a two liner question I can shoot of via chat any time, not even needing to look for (and still fail or mistake) unbusy persons (and with a small team chat even broadcast to multiple people to also solve finding the unbusy person)? There are always many perspectives.. I have also seen introverts cope much better that way than approaching IRL. Heck you can even combine, "let me know when you are not busy to quickly explain me X" providing already the question async way, and then have the call or real desk meeting afterwards? > There is a higher hurdle to setting up a zoom call than there was to waking up to a colleague who was at their desk Also just not getting that, hitting the call button (or a real phone call) was always quicker and easier than walking two floors down to another room just to find the person not at its desk. Where is the hurdle? Really, just not getting it ;) What's to be solved? I see it may be a problem or hurdle for some, but for others the bigger hurdle is the opposite way. Don't extrapolate, generalize and state it like fact, because that is imo not true for everybody and may be the other way round.
  - 3y ago
osigurdson 3y ago
I’m convinced the strength of the “rabbit hole detector” is what truly differentiates software engineers. While I do think experience has something to do with it, I have also observed very senior people with terrible RHDs.
donpark 3y ago
Pair junior developer with a senior, starting with an hour every other day. I had more problems with junior developers who think they're senior developers (some experience, high-confidence) bc they don't ask for help when they should.
bastardoperator 3y ago
A 10 second conversations sounds like a slack message to me, or providing the guidance before they go down the rabbit.
- jayd16 3y ago
  The difference is you can tell on someone's face whether they're struggling or cranking away without bugging them. "Give guidance before" is about as good a "just don't make mistakes."
  - bastardoperator 3y ago
    No you can't. Also, this could be a slack message. "Hey, I need you to take a look at #154, don't worry about the issues Jeff is mentioning, we just need you to fix the error in the form and write a test. If you run into any frontend issues, work with Mike, I already let him know you might be coming to him. This is basic manager, Sr. Developer stuff.
willio58 3y ago
This is very true. For interns and junior devs if the team is remote the seniors need to set aside time to help them out daily. I've started doing this as a senior dev on my team, basically setting time for office hours, and it's been great so far.
- jayd16 3y ago
  Office hours is an ironic choice of words.
coffeefirst 3y ago
Well, it was always true for EMs that you could have a junior dev quietly spinning their wheels and not asking for help. The difference is before you could sometimes see they were frustrated, and they could see other people asking for help and know that's just part of how you work. If they can't see it passively, you have to proactively show them. You can and should still have those 10 second conversations. We've got Slack huddles, screen sharing, VSCode Live Share for more complex pairing... the tools are really good now. That said, I tend to agree, a remote culture that doesn't respect the need for teaching and mentoring is going to be bad at it.
- pavedwalden 3y ago
  When I worked in an office it was much easier to casually ask for quick help. It was often pretty obvious whether a senior engineer was busy and focused or between tasks, checking email etc. and the overhead/friction of these ten-second conversations is higher when you have to wait for a response on slack, then launch a video call, share screen... instead of just making eye contact and saying "got a sec?"
eschneider 3y ago
Part of the job of a mentor/senior engineer is spending time helping get juniors up-to-speed on projects and getting them comfortable asking questions. And if they're not asking questions, checking in on them to see how they're doing. (Pro-tip: don't just ask them how they're doing, have them explain what they're doing and why. Problems show up a lot faster that way. :) Building an environment where junior engineers learn how to find things out on their own and when they need to ask questions is a company culture thing and has very little to do with remote vs in-office.
Tade0 3y ago
Dealing with frustration is part of this job. Also this is trivially solved through checking on the person twice a day and doing call reviews, thus making it at most a few hours. Actually, this is a regular part of successful remote team building. Meanwhile making the junior approach unannounced is counterproductive. I for one would rather have my interruptions at least scheduled if they can't be avoided.
manvillej 3y ago
I still think that is a culture problem. I have a team of engineers that frequently has a lot of junior engineers. I find it really REALLY important to reinforce the culture of "software development is a team sport" and provide concrete mechanisms to do so. Junior engineers need help as the same rate they did before. They still need to ask for help. Remote work lets it: - happen asynchronously & synchronously - creates visibility of asking for help - reduces this weird shame around it - allows us to correct bad answers - allows people to learn from others with the same questions - self manages by capacity because the people with time are the ones that can answer questions - produces an awesome collection of analytics: how many & what questions are being asked by who, Who is answering questions and about what? Remote work is a communication and cultural change that a lot of teams have done poorly. I think most teams decided when the pandemic hit: "oh we'll use teams or slack. That's enough" and never thought more about it.
- maestroia 3y ago
  It's always difficult for people to ask for help. The best thing senior engineers can do is set the example and ask for help when they get stuck on something--even if it's something they could figure out on their own with some time.
  - fsociety 3y ago
    100%. If your seniors aren’t asking for help or even casually chatting in channels, then why would the juniors be expected to start. Setting the example helps encourage it and make it no big deal.
- seadan83 3y ago
  Your team started out as in person? What kinds of things did you think about to transition to where you are? How did that transition happen?
fendy3002 3y ago
> A 10 second conversation could easily save hours of head-banging-into-wall type work for a junior SWE Agree, though sometimes the hours of head banging will benefit greatly to the skills of said junior. That aside, everyone should be encouraged to ask to company's developer forum (slack channel). That way, if the senior that's responsible to train the junior is busy, other less busy senior can help.
- mrits 3y ago
  Reminds me of when I blew up on my partner when I told her I'm not going to tell her how to switch from Playstation to Roku on the TV for the 1000th time. She spent 2 minutes trying to figure out and actually now understands how it works.
dinvlad 3y ago
I think it's actually better for junior engineers to go alone for long stretches of time. That is such a huge driving force for their own success, when they have to learn by doing a lot of things on their own, without external help, and without someone constantly micro-managing them.
- abalashov 3y ago
  I don't know. Really depends. Some of them are very independently-motivated and self-contained, but inexperience means they are still prone to rabbit holes. Others really will sit on their hands until explicitly told what to do, which doesn't mean they're bad or lazy, just that they require tight feedback loops. In both cases, it seems like quicker feedback cycles do more good than harm.
pnutjam 3y ago
A culture of good, clear documentation is critical.
m_0x 3y ago
Agreed. As a 10 YoE engineer working from home is a blessing. Interruptions are minimal and I can take a 15-20 minutes nap if I want. Before the pandemic my office provided a nap room so napping during business hours is NOT frowned upon. People still ping me frequently for a "quick chat" which is rarely quick, tho.
ravishi 3y ago
I had the opposite experience with junior devs on my team. The ones that knew how to communicate and ask for help thrived. It was easy to negotiate some head banging on the wall time while also pairing from time to time to discuss where they're going. I've seem them flourish in less than a year's time and be able to perform just like experienced devs.
- bluefirebrand 3y ago
  All of the junior devs Ive ever mentored, I would be as detailed as possible with my onboarding, demo the product from end to end, walk them through the codebase, and provide step by step instructions to start up their own dev environment. This usually took a couple of days, depending on the project and the dev. Then I give them a ticket and say "if you get stuck, let me know" For the first little while, I am super responsive with them and answer everything immediately and eagerly. After a while, I start to wait about 5-10 minutes before I respond to questions. Usually they figure out the answers before I even get back to them in these cases, and then I get to praise them for it.
  - ravishi 3y ago
    That's a great technique I would say! I stumbled on it by chance when I failed to make it to a client meeting with one junior dev I was leading. He was counting on my presence to support him, we had already discussed it before. But I got caught up last minute and he decided to go alone. And I know it was hard for him, but everything went fine. And from then on he was a lot more confident in his day to day.
gonehome 3y ago
Agreed, tools like gathertown can make a big difference in improving this problem for remote teams, but it requires buy in from the top and the right culture (everyone has to hang out in there during working hours).
grozmovoi 3y ago
Absolutely agree. I think remote engineering work is a skill that is hard to acquire when you're very junior.
gavmor 3y ago
I had the rare privilege of pair-programming 40 hours a week for several years early in my career. This follows the extreme programming ethos of "everything in the limit," where pairing is "code review in the limit" and "mentorship in the limit," to say nothing of the oral tradition it imparts[0]. Even pair-programming with my fellow juniors was both more productive and more educational than a rubber duck[1]. I had the opportunity to sit down to dinner with some very junior devs at a family gathering, recently, and to hear of their isolation due to remote-work broke my heart. They simply have no idea what they're missing. 0. https://www.youtube.com/watch?v=4PaWFYm0kEw https://www.youtube.com/watch?v=4PaWFYm0kEw 1. https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging
- mattnewton 3y ago
  As a counterpoint, I have a hard time coding with other people, it’s like part of my brain spends the whole interaction thinking about what they could be thinking and I usually can’t shut this off. It’s especially aggravated if the person isn’t very familiar to me. For leetcode style interviews that means I basically memorized hundreds of kinds of problems and pattern match to them because thinking deeply while supervised just doesn’t reliably happen for me. I know mentorship is important and spend quite a bit of time on it everywhere I work, including with pairing. But the costs to many senior people’s productivity are very real and can’t be stated lightly. Remote work has been a godsend, previously I would do my best work behind a closed office door, in the back of a company bus, or after hours at home and it’s like having unlimited access to that zone.
- breischl 3y ago
  I think it can work great for some people. I did it for a few weeks at one point, and found it thoroughly unproductive. 90% of my time was spent waiting for somebody else to type something, or trying to verbally communicate something that would be better done in writing/code. Even now I find it incredibly off-putting to have somebody looking over my shoulder when I'm trying to work, to the point that I basically just can't. People have asked to watch me do something, and my response is that you can either watch me, or I can do it, but not both. It's like Heisenberg Uncertainty for work output.
BeFlatXIII 3y ago
> but in my experience junior workers often require bite-sized guidance in order to avoid going down rabbit holes. A 10-second conversation could easily save hours of head-banging-into-wall type work This is why I more or less never go and "do my own research" before asking questions for hobby projects. I've gotten stuck in too many research rabbit holes and (hopefully) have learned my lesson. Ask first, then get mired in irrelevant details if the response to my bizarrely unique question is crickets.
okaram 3y ago
Have the 10 second conversation over video
patrick451 3y ago
I dunno, I was only a few months into my first job when covid hit. Going down all those rabbit holes alone was a massive learning experience. I'd much rather do all that head-wall banging and figure it out myself. I'd have felt smothered if somebody was checking in on my every couple of hours. But this does seem to be a fascinating difference with academia and industry. E.g, in gradschool I got 30 min a week with my advisor, and by some standards that is actually a lot.

fsociety 3y ago

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.

x86x87 3y ago

Oh.. The poor juniors. Instead of properly adapting the onboarding and mentoring to the remote setting let's romanticize the good old ways that imho sucked. Let's cherrypick and pretend everything is fine. We went from offices to cubicles to open space and nobody stopped to think if it was a good idea. Wr transformed the office from a place where work actually is done to a placr where we "socialize". Work? Do that on your own time.

whateverman23 3y ago
> Instead of properly adapting the onboarding and mentoring But... how? Remote check-ins with juniors every 30-60 minutes? That's crazy. But that's basically the only way to replicate the in person experience. The best mentoring results for me as the mentee and for me as a mentor have been when we're sitting next to each other. The mentor can visually tell when the mentee is stuck, and mentee can tell when the mentor isn't focusing on anything important and is more willing to ask for help. No matter how many times you tell junior engineers to ping you at the first sign of trouble, they're not going to do it. They're going to toil for way longer than needed, unless you're sitting right next to each other.
- malfist 3y ago
  Who suggested checking in with juniors every 30-60 minutes? GP certainly didn't. You're arguing against a strawman.
  - whateverman23 3y ago
    Sorry I edited to include my point there. If you don't have 30-60 minute check-ins with juniors, they're not going to have the same rapid feedback that they'd get from in person mentoring. And very importantly, I'm saying 30-60 minute remote check-ins are an absolutely insane idea that should never be implemented. I don't know any kind of remote system that provides for anything even close to the power of in-person mentoring.
    - 3y ago

ResearchCode 3y ago

Those "rabbit holes" are where you learn. Saving hours is more important if you bill hourly, less if you are salaried.

throwawayfear 3y ago
Indeed. There may be a toxic or stupid management culture at that company if they're worried about someone going down a rabbit hole to learn. In my experience this is usually in teams that are run by people who don't have technical ability.
- FartyMcFarter 3y ago
  Going down rabbit holes and getting something out of it is fine, but that doesn't always happen. Sometimes people are just frustrated and spinning their wheels, or doing work that turns out to be pointless because they failed to understand something which would have been clarified by a short conversation.
  - throwawayfear 3y ago
    That can be measured by frequency of code commits. You can tell which juniors are making the most of a rabbit hole and becoming better versus which ones are mindlessly surfing because they don't want to think. The first group will have things to share or talk about if they go some time without committing code and their mentor or manager starts getting worried. If someone hasn't pushed something in a week or two, that's a good time for their mentor to initiate a conversation and see where they're at and when they think they will push something. Anything else is micromanagement by a company that has hired someone without giving them any amount of runway to actually work and learn the space they're in. You can also tell on company hardware and on company accounts if the junior's browsing history represents getting better or just resting on their haunches because they want someone else to do the thinking. Let's not pretend the micromanagement cultures where "fear of rabbit holes" exists are not already doing this.
    - 3y ago

nmridul 3y ago

In my project (30+ members) we have team members located in multiple locations (6+ cities in 4 countries). And for the last 2+ years I am the only one working from my country. While our company is 500+ strong in this country, for this particular project I am the only one. So interactions with the project team is fully remote. I am sure even pre-covid many MNCs might have a similar structure with members spread across different location. Though coming to office, but project work happens remotely. Also have juniors joining the team. It might be difficult for juniors to get started. But not impossible to handle.

Aurornis 3y ago
> Its difficult - yes. But not impossible to handle. The problem with “difficult but not impossible” is that it requires special personality types to handle it. Some people can do it, but now you have a secondary problem in that you need to find a way to filter those people in the hiring pipeline. You also have a risk of hiring people who can’t handle it and having to cut them and re-hire. This is why most “difficult but not impossible” conditions are reserved for special exceptions but aren’t useful for general policies.
- seattle_spring 3y ago
  Isn't the same thing true about working in an office? Certain personality types thrive while others suffer.
- freyes 3y ago
  > it requires special personality types to handle it. I agree, and I don't see a problem with it. > [...], but aren’t useful for general policies. offices are just optimizing for the loudest and more social people, this is a consequence of managers tending to be like that, I don't think that approach is useful for general policies neither.
no_wizard 3y ago
I disagree its difficult. When the culture supports mentorship, onboarding and first year experience as high priority items with solid guidelines / process around them, its pretty easy. but wait, that means changing cultural and such, that's not easy is the response I often get to this, to which I say preemptively: That I would agree with, because the US business cultural is surprisingly stiff to changing things that would have favorable impact to workers, but that is IMO a different and separate discussion to the fact that this is a readily solvable problem.

no_wizard 3y ago

It doesn't have to be this way though. This sounds to me like a huge gap in communication and on-boarding process, which indirectly is a cultural problem, its not a remote work problem. You can solve this, and many organizations have. It does mean re-thinking expectations around onboarding and the role of mentorship in the company though

ramesh31 3y ago

>A 10 second conversation could easily save hours of head-banging-into-wall type work for a junior SWE (not even exaggerating). Weeks, even. It took me a while to come to terms with the fact that this is the majority of my value to an org now. Not so much in my IC abilities, but in the ability to save endless amounts of time for lesser experienced folks.

dakiol 3y ago

That's why one should hire juniors based on how well they communicate and less based on their skills to invert a binary tree or design a URL shortener service.

ResearchCode 3y ago
There's an abundance of people that can talk but do less. Real tech talent are rare, not that you find them by algorithms quizzes.

throwbadubadu 3y ago

That's true, but I don't see how this relates to pandemic or being remote? Also not reaching out when getting totally stuck is a bad thing, but again unrelated?

FartyMcFarter 3y ago
> I don't see how this relates to pandemic or being remote? There was more friction to asking quick questions, compared to being in office. This may not be the case any longer at all companies, as it's possible that some of them solved this with new communication practices.
sokoloff 3y ago
There is a higher hurdle to setting up a zoom call than there was to waking up to a colleague who was at their desk and didn’t look obviously busy. Solve that, and you probably solve a lot of low-grade communication challenges that are made worse by being remote as compared to in-same-office.
- throwbadubadu 3y ago
  A 10 second convo is a two liner question I can shoot of via chat any time, not even needing to look for (and still fail or mistake) unbusy persons (and with a small team chat even broadcast to multiple people to also solve finding the unbusy person)? There are always many perspectives.. I have also seen introverts cope much better that way than approaching IRL. Heck you can even combine, "let me know when you are not busy to quickly explain me X" providing already the question async way, and then have the call or real desk meeting afterwards? > There is a higher hurdle to setting up a zoom call than there was to waking up to a colleague who was at their desk Also just not getting that, hitting the call button (or a real phone call) was always quicker and easier than walking two floors down to another room just to find the person not at its desk. Where is the hurdle? Really, just not getting it ;) What's to be solved? I see it may be a problem or hurdle for some, but for others the bigger hurdle is the opposite way. Don't extrapolate, generalize and state it like fact, because that is imo not true for everybody and may be the other way round.
- 3y ago

osigurdson 3y ago

I’m convinced the strength of the “rabbit hole detector” is what truly differentiates software engineers. While I do think experience has something to do with it, I have also observed very senior people with terrible RHDs.

donpark 3y ago

Pair junior developer with a senior, starting with an hour every other day. I had more problems with junior developers who think they're senior developers (some experience, high-confidence) bc they don't ask for help when they should.

bastardoperator 3y ago

A 10 second conversations sounds like a slack message to me, or providing the guidance before they go down the rabbit.

jayd16 3y ago
The difference is you can tell on someone's face whether they're struggling or cranking away without bugging them. "Give guidance before" is about as good a "just don't make mistakes."
- bastardoperator 3y ago
  No you can't. Also, this could be a slack message. "Hey, I need you to take a look at #154, don't worry about the issues Jeff is mentioning, we just need you to fix the error in the form and write a test. If you run into any frontend issues, work with Mike, I already let him know you might be coming to him. This is basic manager, Sr. Developer stuff.

willio58 3y ago

This is very true. For interns and junior devs if the team is remote the seniors need to set aside time to help them out daily. I've started doing this as a senior dev on my team, basically setting time for office hours, and it's been great so far.

jayd16 3y ago
Office hours is an ironic choice of words.

coffeefirst 3y ago

Well, it was always true for EMs that you could have a junior dev quietly spinning their wheels and not asking for help. The difference is before you could sometimes see they were frustrated, and they could see other people asking for help and know that's just part of how you work. If they can't see it passively, you have to proactively show them. You can and should still have those 10 second conversations. We've got Slack huddles, screen sharing, VSCode Live Share for more complex pairing... the tools are really good now. That said, I tend to agree, a remote culture that doesn't respect the need for teaching and mentoring is going to be bad at it.

pavedwalden 3y ago
When I worked in an office it was much easier to casually ask for quick help. It was often pretty obvious whether a senior engineer was busy and focused or between tasks, checking email etc. and the overhead/friction of these ten-second conversations is higher when you have to wait for a response on slack, then launch a video call, share screen... instead of just making eye contact and saying "got a sec?"

eschneider 3y ago

Part of the job of a mentor/senior engineer is spending time helping get juniors up-to-speed on projects and getting them comfortable asking questions. And if they're not asking questions, checking in on them to see how they're doing. (Pro-tip: don't just ask them how they're doing, have them explain what they're doing and why. Problems show up a lot faster that way. :) Building an environment where junior engineers learn how to find things out on their own and when they need to ask questions is a company culture thing and has very little to do with remote vs in-office.

Tade0 3y ago

Dealing with frustration is part of this job. Also this is trivially solved through checking on the person twice a day and doing call reviews, thus making it at most a few hours. Actually, this is a regular part of successful remote team building. Meanwhile making the junior approach unannounced is counterproductive. I for one would rather have my interruptions at least scheduled if they can't be avoided.

manvillej 3y ago

I still think that is a culture problem. I have a team of engineers that frequently has a lot of junior engineers. I find it really REALLY important to reinforce the culture of "software development is a team sport" and provide concrete mechanisms to do so. Junior engineers need help as the same rate they did before. They still need to ask for help. Remote work lets it: - happen asynchronously & synchronously - creates visibility of asking for help - reduces this weird shame around it - allows us to correct bad answers - allows people to learn from others with the same questions - self manages by capacity because the people with time are the ones that can answer questions - produces an awesome collection of analytics: how many & what questions are being asked by who, Who is answering questions and about what? Remote work is a communication and cultural change that a lot of teams have done poorly. I think most teams decided when the pandemic hit: "oh we'll use teams or slack. That's enough" and never thought more about it.

maestroia 3y ago
It's always difficult for people to ask for help. The best thing senior engineers can do is set the example and ask for help when they get stuck on something--even if it's something they could figure out on their own with some time.
- fsociety 3y ago
  100%. If your seniors aren’t asking for help or even casually chatting in channels, then why would the juniors be expected to start. Setting the example helps encourage it and make it no big deal.
seadan83 3y ago
Your team started out as in person? What kinds of things did you think about to transition to where you are? How did that transition happen?

fendy3002 3y ago

> A 10 second conversation could easily save hours of head-banging-into-wall type work for a junior SWE Agree, though sometimes the hours of head banging will benefit greatly to the skills of said junior. That aside, everyone should be encouraged to ask to company's developer forum (slack channel). That way, if the senior that's responsible to train the junior is busy, other less busy senior can help.

mrits 3y ago
Reminds me of when I blew up on my partner when I told her I'm not going to tell her how to switch from Playstation to Roku on the TV for the 1000th time. She spent 2 minutes trying to figure out and actually now understands how it works.

dinvlad 3y ago

I think it's actually better for junior engineers to go alone for long stretches of time. That is such a huge driving force for their own success, when they have to learn by doing a lot of things on their own, without external help, and without someone constantly micro-managing them.

abalashov 3y ago
I don't know. Really depends. Some of them are very independently-motivated and self-contained, but inexperience means they are still prone to rabbit holes. Others really will sit on their hands until explicitly told what to do, which doesn't mean they're bad or lazy, just that they require tight feedback loops. In both cases, it seems like quicker feedback cycles do more good than harm.

pnutjam 3y ago

A culture of good, clear documentation is critical.

m_0x 3y ago

Agreed. As a 10 YoE engineer working from home is a blessing. Interruptions are minimal and I can take a 15-20 minutes nap if I want. Before the pandemic my office provided a nap room so napping during business hours is NOT frowned upon. People still ping me frequently for a "quick chat" which is rarely quick, tho.

ravishi 3y ago

I had the opposite experience with junior devs on my team. The ones that knew how to communicate and ask for help thrived. It was easy to negotiate some head banging on the wall time while also pairing from time to time to discuss where they're going. I've seem them flourish in less than a year's time and be able to perform just like experienced devs.

bluefirebrand 3y ago
All of the junior devs Ive ever mentored, I would be as detailed as possible with my onboarding, demo the product from end to end, walk them through the codebase, and provide step by step instructions to start up their own dev environment. This usually took a couple of days, depending on the project and the dev. Then I give them a ticket and say "if you get stuck, let me know" For the first little while, I am super responsive with them and answer everything immediately and eagerly. After a while, I start to wait about 5-10 minutes before I respond to questions. Usually they figure out the answers before I even get back to them in these cases, and then I get to praise them for it.
- ravishi 3y ago
  That's a great technique I would say! I stumbled on it by chance when I failed to make it to a client meeting with one junior dev I was leading. He was counting on my presence to support him, we had already discussed it before. But I got caught up last minute and he decided to go alone. And I know it was hard for him, but everything went fine. And from then on he was a lot more confident in his day to day.

gonehome 3y ago

Agreed, tools like gathertown can make a big difference in improving this problem for remote teams, but it requires buy in from the top and the right culture (everyone has to hang out in there during working hours).

grozmovoi 3y ago

Absolutely agree. I think remote engineering work is a skill that is hard to acquire when you're very junior.

gavmor 3y ago

I had the rare privilege of pair-programming 40 hours a week for several years early in my career. This follows the extreme programming ethos of "everything in the limit," where pairing is "code review in the limit" and "mentorship in the limit," to say nothing of the oral tradition it imparts[0]. Even pair-programming with my fellow juniors was both more productive and more educational than a rubber duck[1]. I had the opportunity to sit down to dinner with some very junior devs at a family gathering, recently, and to hear of their isolation due to remote-work broke my heart. They simply have no idea what they're missing. 0. https://www.youtube.com/watch?v=4PaWFYm0kEw https://www.youtube.com/watch?v=4PaWFYm0kEw 1. https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging

mattnewton 3y ago
As a counterpoint, I have a hard time coding with other people, it’s like part of my brain spends the whole interaction thinking about what they could be thinking and I usually can’t shut this off. It’s especially aggravated if the person isn’t very familiar to me. For leetcode style interviews that means I basically memorized hundreds of kinds of problems and pattern match to them because thinking deeply while supervised just doesn’t reliably happen for me. I know mentorship is important and spend quite a bit of time on it everywhere I work, including with pairing. But the costs to many senior people’s productivity are very real and can’t be stated lightly. Remote work has been a godsend, previously I would do my best work behind a closed office door, in the back of a company bus, or after hours at home and it’s like having unlimited access to that zone.
breischl 3y ago
I think it can work great for some people. I did it for a few weeks at one point, and found it thoroughly unproductive. 90% of my time was spent waiting for somebody else to type something, or trying to verbally communicate something that would be better done in writing/code. Even now I find it incredibly off-putting to have somebody looking over my shoulder when I'm trying to work, to the point that I basically just can't. People have asked to watch me do something, and my response is that you can either watch me, or I can do it, but not both. It's like Heisenberg Uncertainty for work output.

BeFlatXIII 3y ago

> but in my experience junior workers often require bite-sized guidance in order to avoid going down rabbit holes. A 10-second conversation could easily save hours of head-banging-into-wall type work This is why I more or less never go and "do my own research" before asking questions for hobby projects. I've gotten stuck in too many research rabbit holes and (hopefully) have learned my lesson. Ask first, then get mired in irrelevant details if the response to my bizarrely unique question is crickets.

okaram 3y ago

Have the 10 second conversation over video

patrick451 3y ago

I dunno, I was only a few months into my first job when covid hit. Going down all those rabbit holes alone was a massive learning experience. I'd much rather do all that head-wall banging and figure it out myself. I'd have felt smothered if somebody was checking in on my every couple of hours. But this does seem to be a fascinating difference with academia and industry. E.g, in gradschool I got 30 min a week with my advisor, and by some standards that is actually a lot.