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

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.

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

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.

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

Isn't the same thing true about working in an office? Certain personality types thrive while others suffer.

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

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.

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

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.

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.

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 is not already doing this.

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

Are you saying the mentor should actually go and check the browsing history of one their engineers to verify whether they've actually done "correct work" or what are you trying to say exactly? This sounds to me like micromanagement of the highest order.

What I'm saying is that they already do it and already have access to enough information to know who is making the most of a rabbit hole and who is not. Code commit frequency is sufficient in itself.

Generally agree that rabbit holes (or as my wife calls mine: black holes) can be conducive to learning. But I suspect that there's diminishing returns. At some point, you may end up spinning your wheels and reaching out for help does not distract from learning the valuable lesson.

If you're doing a PhD, that point is a weekly chat with your supervisor. I don't see why a few hour "rabbit hole" would be a problem in software engineering. If we're even discussing hours unless billing hourly, that's a red flag for micromanagement.

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.

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

I like to do virtual desk with Slack, where I will have a channel where I'm always in a huddle and they can drop by when they have questions, just like they would in-office.

I have to say as a counter point though that I've had a lot more trouble with coworkers coming to my physical desk for questions that they could have Googled than with Junior getting stuck for extended period of time remotely. It's all a matter of culture and relationships.

100% this. Keep an open channel for IM and setup regular shadowing. I've been on both ends, learning and teaching. It's way preferable to have your own computer, shared screen vs trying to look at another screen and taking notes. Remote is better for collaboration and training. Proper documentation is a big part of it, and open channels for IM, like slack.

> Remote is better for collaboration and training.

Oh come on... I get arguing that there are ways to make remote training good enough. Maybe even similar. Maybe even a net-positive when you look at the entire picture (including the productivity and happiness of your senior staff). But saying remote is better for training specifically? No way. That makes no logical sense.

Please elaborate how it's better in person? Remote: I can see and hear the person. I can see their screen. I can copy past back and forth (as can they) through the screen sharing app. I can invite others into the training pretty much instantly. I can send links and commands typed properly in the chat. User can record session for later.

In person: Usually have to face the person or the screen, can't see both. I have to write down commands and pass them, or type them myself. There is a delay finding others if we need to talk to them. More chance to transpose commands incorrectly by the user. Harder to record the session without losing parts.

Everything you can do remotely, you can do in person as well. I don't know why you think you can't screen share or send links and commands in a chat if you're in person.

So at minimum, in person would be the same. So I can't possibly see how in person could be worse.

So you're just ranting, no data and looks like no experience. OK

In person is worse. I've done both. It's noisier, you're crammed into a cube taking notes, etc. If you're going to use remote tools, what's the benefit of in person?

> looks like no experience

Got it, I see you're in the "make up stuff about the other person" phase of the discussion. No point in continuing here.

Sure, all you ever said was you could believe and you could do remote stuff in person. Way to support your statements.

It's really not an issue to have a junior bang their head against the wall for a few hours and then telling them that they should have gotten help sooner.

They won't do that every single time. At some point they'll realize that asking for help isn't an issue.

Yew, if only we could assign a senior engineer to watch over every new person that joins /s

Part of learning to be a sw developer is learning how to go about your work. Learning when to ask for help. If someone is doing this for you, you'll never going to learn.

Why the /s? I happen to agree with that statement.

Part of being a senior engineer is to use the mentorship skills you developed along the way and make judgements about how much struggle is right. Every new person should have a more senior partner with whom they can ask the dumb questions and not be made to feel dumb.

> learning how to go about your work

There are whole college degree programs designed to teach this, in fact.

The juniors will have to read documentation and spend long hours writing and reading code and understanding what has already been built. Just like all of us who did that and had to do it in order to move up. The idea of spending time "mentoring juniors" has always ended up being an euphemism. It's just a way for non-technical people, at the end of the day, to consume as much time as possible from other people so they can pretend to be doing work.

It's clear which juniors are motivated and will make the most of the mentorship and which ones are not. Some are just there for the check and you cannot compromise your senior and higher talent on people who don't want to learn and grow and just want the prestige and check of a high-tech job. It's the same situation with someone who is drowning not listening to orders and taking down their rescuer with them too.

If a junior needs someone to sit next to them because they toil for way longer than needed on clear simple requirements and goals, this may not be the field for them. I never needed anyone right next to me that couldn't have been a direct message or a brief remote call to clarify something specific, clear, and to the point. You're describing a reality where the people who don't do are just trying to take as much time for themselves as possible to hide the fact that they don't want to think.

Who suggested checking in with juniors every 30-60 minutes? GP certainly didn't. You're arguing against a strawman.

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.

Lol. Are those juniors in the room with us right now?

How about letting them figure it out and provide opportunities to chat and ask questions from time to time. Everyone wants superdevelopers but everyone expects that you're going to put a complete noob in a room with a senior developer, they're gonna rub hand and in 2-4 days you're going to have another senior developer. That's not how it works.

Agile environments are much better at this. Its inherent frequent touchpoints and "fail fast" mindset can help to ensure the juniors are getting as much information and direction as required.

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

We've used day long zoom windows or slack huddles. Keep muted until you want to say something. Slack is the same thing, just send a message.

Pair programming sessions.

Effective use of group chat works well. The most effective remote teams, there are little conversations happening in the team Slack, often more than once per hour that can go for 5-10 minutes. Some people are bad at communicating over text but some people are also bad at communicating in person and in-person just biases for the latter, it's not inherently better. It can be helpful to hop on video but there's a ton of ways to communicate, often more effectively and less disruptively.

To add to your point. Just because there's a tradeoff one way doesn't mean we shouldn't make that tradeoff.

Yeah, there might be some impacts to junior engineers. But if it improves the efficiency of your more expensive senior devs, isn't it worth it?

And just because your team has a problem with onboarding and mentoring junior devs in a remote environment doesn't mean A) Everyone has the same problem, B) you can't fix that problem yourself. Self improvement is the name of the game here anyway

> We went from offices to cubicles to open space and nobody stopped to think if it was a good idea.

People have been complaining about this development since forever. I'm not sure who that 'nobody' in your sentence is?

My point is that we are invoking this alleged benefits when it serves a narrative but just ignore it when it's convenient for the "bottom" line

Who is 'we'? Different people do different things.

That nobody is obviously within the people making the decisions. The people complaining were a whole different set of nobodies.

There's lots of different people making different decisions for different reasons.

Mark Zuckerberg might be a true believer in open plan offices (judging by his public comments). But your average Fortune 500 company might only be into it for the savings in office space expenditure to be had from cramming people tighter. And some companies, like SAP (at least when I did an internship with them ages ago), still have offices (shared amongst eg 4 people) instead of going open plan.

Nothing about what they said is socializing.

I was one of those juniors, the rapid shift to remote work ruined me. I had just moved to a new city where I knew no one to start a life doing the work I loved, and all at once I got told leaving my house was dangerous and to stay home alone all day staring at a screen to keep people safe, for 2+ years…

It’s great you value work life balance, but junior engineers suffered a lot (to different degrees), and you being on edge that remote work might be taken away from you is nothing compared to what I went through and haven’t recovered from.

We’re allowed to love our work and the people we do it with, that’s my ideal, just a because you hate it doesn’t mean everyone should

Look: except for a few months in high school, I have never worked for a stereotypical company where I would go into an office and do work with other people; I have always worked by myself or remote. I relish working alone and have never had an issue with it; I've even been quite fanatical about it, trying to make sure everyone knew how great this lifestyle was (one which I learned from my father, who worked for a company half a world away from him, from a home office where he was always accessible to his son: me).

But... the pandemic also broke me. Bad. I wasn't at all prepared for life trapped inside where my only interaction with human beings I knew was via video. There were like four months in early 2021 where I only had about four interactions with flesh and blood humans whose name I knew (like, not some entirely random person)... one of them was the guy who lived in a nearby park whom I normally avoid as it is so difficult to end conversations. I gained a ton of weight and at one point--end of 2020--I had given myself some kind of weird anemia (I think from lack of B12 in my stupid closed-in diet).

Like: I am someone for whom his entire life normalized remote work and who thrived in such an environment and yet the pandemic was so hard I still haven't really recovered... thinking about it makes me cry. (And like, yes: I could have better managed my lifestyle or better handled the loneliness. Whatever. That is also true for you, and I at least am not judging you for that.) It is one thing to not work in an office--you can work from anywhere! and there are a ton of people who you can get to spend time with--and it is entirely another thing to work explicitly from a small room in your home day in and day out for a year without human contact.

I thereby want to posit that maybe--just maybe--the issue isn't working remotely but being forced to stay at home and at times even fear going to the supermarket. There were periods during this thing when people were even afraid to meet up outside, and so human contact for white collar professionals outside of relationships was pretty much just verboten. The world was in a shitty place, and you shouldn't judge working remote based on the experiences you had during a pandemic without even trying to control for the existence of a pandemic as part of your analysis.

I vividly remember trying to meet up with the few people who stayed behind and didn’t move to their parent’s lake house during covid, one person in the group being concerned about even meeting up outside and everyone else not wanting them to be left behind, so we did virtual on zoom. Laughs and fun, then with a button press the screen flicks black and you’re alone again in your tiny apartment you signed when the plan was to spend almost no time there.

You’re right, I do still think there is value working in person, but remote work by itself isn’t what caused this, even if it’s still what happened.

Hindsight has made all this more clear, but imo loneliness is a silent killer around the world today, and covid threw jet fuel on the fire.

You need social in person interaction as a human being. Nobody is disputing that. Should you rely on your work to get that interaction and can you make the claim that it helps your work?

Considering that it delivers a feeling of productive communion, the camaraderie and esprit d'corps of solving problems together, and generally feeling useful, the answer might be yes. Especially if, as an adult, it's where you spend most of your waking hours.

Don't misunderstand me, I'm not romanticising the marriage of one's social life to one's workplace, nor overlooking the ways this "we are more than a company, we're family" rhetoric benefits employers at the expense of their employees' outside lives and broader well-rounded and fulfilment. But I think asking people to separate them in an extreme way is just as untenable.

I can sympathize, but you should not have let it ruin you. Take responsibility for your own life.

When you’re alone, someone telling you it’s your own fault and just take responsibility for it can feel really dark

My apologies. I know the pandemic was particularly hard on young people. This is the problem with old, comfortable and scared people making all the decisions.

I had the same timeline as you, but it was fine for me. Granted, I've never known anyone anywhere I've lived and barely leave home anyway. :p I'm grateful I seem optimized for the fully atomized cyberpunk existence which may only become more intense and universal in the future.

I've worked in cubicles and open space plans as well as remotely as a junior. It seems self-evident to me but maybe those who haven't experienced the various environments do not realize that in person it is much easier to ask a random question to a senior. You can poke them and have a small discussion that would flood a chatroom and take much longer to develop remotely, without feeling like you may be inconveniencing them or the rest of the team since you cannot see if they are busy, or you can follow them to the coffee machine and discuss issues that are not urgent but could use their input instead of just notifying them over chat at a random time that may or may not be convenient.

Working remotely I found myself constantly wasting time trying to figure things out on my own because I don't know if people are even online/active (spread out across the globe, another issue common with remote), if they are online I don't know if they have something more important to deal with at the moment, it is more difficult to extract information from seniors who are poor communicators - as good as they may be as ICs, most of my seniors will assume I should know every undocumented internal mess and it makes asking for more details intimidating. And I don't want to look like an idiot in writing! (lol, but I do feel that way sometimes)

If you want juniors to learn anything in a reasonable amount of time you have to give a bit of a shit and invest more time solely towards that especially in remote environments, seems that people just expect juniors to take the lead and force their way in though which isn't my style at all and if there isn't a common agreement and people are all just doing their thing it can come off as presumptuous to be bugging people left and right for the first months. Yes part of the problem is company culture not properly adapting to the environment, but I also haven't seen any change in the way we deal with communication since the Corona and of course seniors don't care because they got their job security.

As the person you kept interrupting and following to the coffee pot, I much prefer this new way of working.

To be clear, labelled as an 'IC' I have zero interest in training you. You will job hop at the first opportunity, and never lift a finger to help me in the future.

With that attitude yes I'm not surprised that people would be tempted to jump ship.

Hard disagree with random questions. If it's easy to ask a random question you're just going to keep asking random questions. How about you write down that question and try to formulate the answer or a strategy for finding the answer?

Here is a workflow I made all people I mentor go through: 1) what is the problem? 2) why is this a problem? 3) what are you actually seeing? 4) what have you tried to solve it? What are the results?

"Random questions" doesn't mean questions without any thought put into them. It just means anything helpful from workflow or environment related questions to code style or processes that are not documented or easy to find. vs. wasting time trying to find things that don't exist or reinventing the wheel, which is more tempting to do when you can't see what your coworkers are doing and don't want to risk offending people who have no interest in passing on knowledge, like a sibling of your comment.

Allowing a noob to spin their wheels for too long isn't just wasteful, it sets the exact wrong tone. The goal is not to "figure everything out for yourself". It's to GET THINGS DONE.

If your team penalizes you for "asking questions and looking like an idiot" then the team culture is poor.

Nobody knows everything. Everyone makes mistakes. The team should help those people but they need to ask.

Today I was looking in the wrong devtools tab for a token value. Because we've worked hard making our team a safe place in which to ask questions, I felt comfortable asking what I was missing. Heck it's give and take, I know way more DevOps and Linux-y stuff, the devs know more about their job.

Because we try to think as a team, we do better and have less interpersonal clashes. I still complain about things each dev does, that's natural, but our team does pretty well together.

> Today I was looking in the wrong devtools tab for a token value. Because we've worked hard making our team a safe place in which to ask questions, I felt comfortable asking what I was missing. Heck it's give and take, I know way more DevOps and Linux-y stuff, the devs know more about their job.

That's easier to do when you're more or less on "equal footing", but if you're a junior, it can take months to years to develop knowledge that seniors don't (depending on several factors). That's the problem, it takes much longer to reach a point where you have knowledge that is equivalent to that of seniors if the culture doesn't lend itself to frequent and high-quality communication and you have to learn about internal tools, processes, code bases and such largely solo. If you share a physical space with seniors you'll at least have some common downtime like a coffee or water break to "bother" them and it can save minutes to hours of tedium each time.

So either you end up being "that guy always asking stupid questions in the chat and interrupting my work" or you spend a lot of time spinning your wheels pointlessly for months/years on end. The first approach leads to unhelpful and delayed responses and the latter makes you so inefficient that you favor lower quality work so that you can actually deliver something.

This is such an important point I don’t think it can be overstated. Psychological safety is one of the key things to have a well-functioning culture and it’s one of those cultural things that I’ve tried desperately change in past positions. It’s hard, and in one place, almost impossible save for eliminating a few key people who hold onto that mindset and clean house a little bit.

There is no growth, no team cohesion in an environment where you’re berated for asking seemingly stupid or dumb questions. But I think people become numb and indoctrinated to it because “well, I had to endure this when I was learning” is such a demoralizing and abusive stance and nobody wants to change.

Things work so much better when everyone has a chance to pitch in, even if some ideas are dumb, just having the option is miles ahead of whatever bullshit people can justify from the “old way”.

Part of the process to change I’ve found is just leading by example. I’ll intentionally ask stupid questions that I know raise the ire of my similarly-leveled coworkers just to make the point to the more junior people that “hey, this staff-level guy is asking this, I might be able to too”. Junior people will gradually start to get the picture and ignore the rantings and ravings and toxicity of the debbie-downwers and the sticks-in-the-mud.

Well said. I am currently working my way through an unfamiliar codebase and even as a mid-career developer, I find it intimidating and inconvenient to continually ask for help over slack for "basic questions". People say the answer is to go deep and gain expertise, but in my experience you need to reach a certain escape velocity with the codebase before that kind of spelunking becomes valuable learning experiences and not just a confusing and messy waste of time. You need either:

* Documentation that is up to date and answers not just technical details but the "why" behind the architecture. Something that shows you where to focus and where the frontier is.

* Defined, limited scope (at first). Scoping yourself to the entire codebase is a good way to become an expert in nothing. You need a foothold where you can gain expertise and give yourself a jumping off point to adjacent areas.

The latter is easier to accomplish than convincing everyone to write pages of docs that don't exist.

Hate to bang the same drum over and over, however this very much sounds like a culture problem, based on

> if they are online I don't know if they have something more important to deal with at the moment, it is more difficult to extract information from seniors who are poor communicators - as good as they may be as ICs, most of my seniors will assume I should know every undocumented internal mess and it makes asking for more details intimidating. And I don't want to look like an idiot in writing! (lol, but I do feel that way sometimes)

Sounds like the company lacks good culture, process and guidelines on expected patterns of communication and behavior. There should be an onboarding buddy when things are implemented well.

Its not your fault, at all. Its the company. Its not inherent to remote work though

Can you please make your substantive points without fulminating, snarking, or posting in the flamewar style? This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.

I will try

Thanks!

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

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.

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.

Another (unrelated) problem with Remote work is how harder is to lose weight when you stop moving throughout the day.

Before the pandemic, I usually got up to make coffee, to ask for help or to make consensus with my fellow coworkers (other devs or even UX people, a few stairs away). I usually walked from work from time to time to clear up my mind. Now I barely move. I live in a small apartment. The fridge is 3 meters away from me.

Back then, I could somehow manage my weight by applying some casual restrictions, like eating fewer carbs and eat mostly lean cuts of meat. Now I need to apply some zen monk level of self control if I want to not gain more weight. And losing it is terribly hard.

Opposite for me, wfh means healthier lunches, more time and flexibility to be active . The short walk to transit (of not driving) doesn’t come close

It’s not for everyone, but people who don’t already have an entire life outside of work struggle to start one when the majority of your day is spent alone staring at a screen. The idea that socializing at work is a bad thing I think isolated a huge number of people who used to thrive on work relations and didn’t need a huge number of close friends outside of work to be happy.

My company is 90% remote in practice even though almost everyone lives is in the greater Boston area. It has a Monday meeting over Zoom that starts with socializing, typically discussing personal events from the weekend. This kind of conversation might help people (particularly junior employees) realize that it is possible to have a life outside of work and give some ideas about how to start it (e.g., organized bike rides).

I don’t think socializing at work is bad, but depending on it I think can be: you may not get along with your coworkers or have any common interests, and the ones you do might leave/depart anytime. you shouldn't expect or need them to reciprocate

Having a strong social life outside of work insulates you form this

For me it’s the opposite. I don’t have any junk food at home but when I was in the office I was constantly surrounded by pretzels, ice cream and candy bars. I also often do some work in the backyard while I am thinking about a problem.

I've actually gained weight since having to go into an office a few days a week, was much easier to exercise when working from home imo.

For me it's the other way. I used to drive to work. Now I walk before and after work.

Maybe for you.

Working from home means I make healthy lunches for me. It's a lot easier to eat right when you have a full kitchen and pantry at your disposal.

I made my lunch the day before and carried it on a small tupperware (how are these called?)

Wasn't as great as fresh food but at least I made sure it was healthy.

This is just a description of your lack of discipline. Since the pandemic, I lost a significant amount of weight and increased my fitness across all other parameters as well. This is because remote work facilitated that. If you need to work in an office in order to get up to make a coffee or to ask for help or to "make consensus" then that's a you problem.

A lot of people don't know how to cook. Maybe the company offered access to a gym too. The "you problem" could be doing a lot of lifting here.

I can cook but I appreciated not having to think about it, and the food was great.

If you don’t like remote work, it’s always “your problem” somehow. Everybody has to like remote work, I guess. And if they don’t it means they are flawed somehow.

It’s kinda nuts the lengths people to go put down those who simply hate working at home 40 hours a week.

Nobody is putting down people who don't like remote work. People are putting down the people who are telling other people why remote work is bad. Those people are trying to take it away. Go work in an office or find a place that is onsite if you think this way.

I struggle with this too. My usual exercise routine is to run alternate days. With WFH, I go on 1 hour evening walks on days I am not running. This makes up for the lack of walking at home.

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?

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

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.

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.

Slacking 'hey, can we do a quick huddle?' takes about the same time as walking to someone's desk (less if the desk is far away;)

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.

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.

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

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

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.

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.

Office hours is an ironic choice of words.

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.

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?"

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.

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.

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.

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.

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.

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?

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

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.

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.

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.

A culture of good, clear documentation is critical.

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.

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.

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.

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.

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

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

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

1. https://en.wikipedia.org/wiki/Rubber_duck_debugging

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.

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.

> waiting for somebody else to type

> trying to verbally communicate something that would be better done in writing/code

> somebody looking over my shoulder

At the risk of sounding flippant, none of these activities comprise pair programming. What's better written should be, and the simplest way might be "can I just show you?" or, from a particularly well-atuned pair, "would you mind showing me?"

"Waiting for someone else to type," in my experience, is either a good opportunity to finish a bit of thinking that'd I'd put off moments prior, or else premeditate on our next move. Sometimes, however, the typing is, as you alluded to, an attempt to communicate something, in which case watching them type is roughly equivalent to listening to a person in conversation, and therefore an opportunity to learn, catch bugs, etc. In other words, when I am pair-programming I am never waiting qua idling.

And, lastly, I completely agree that "somebody looking over my shoulder" is an unnerving condition to code under. As purely ergonomic concern, "over one's shoulder" is not a healthy position from which to operate a computer. ;)

But, seriously, it's not pair programming if you're not on equal footing (seating?), with equal access to mouse, keyboard, and monitor. Don't stand for someone standing behind you!

I am sorry for the unpleasant experiences you've had. As a practitioner, I would not have subjected you to them. I am, frankly, vicariously irritated with whomever did.

"Looking over your shoulder" was just a figure of speech, not a literal description. And I suppose I could have grabbed the keyboard, but there's social niceties to navigate, everyone likes their keyboard & IDE set up different ways, and it's generally a PITA.

Also the way I tend to code is never linear in a way that anybody else could follow. I write something, edit it, throw it away, put it back, rename it, hack out something I _know_ is buggy so I can see how it looks, and basically "thrash" my way to a solution that I like. That makes it essentially impossible for anybody to follow in real time, and having them try to point out errors would be counterproductive. In the later stages someone could help polish it, but even then I think it'd mostly be a waste of time.

That's before we even get to things like dealing with interruptions, or answering other questions quickly. Ideally interruptions don't happen, but in practice they do, and I don't want to be wasting someone else's time.

There's a lot I liked about XP, but I still think that (for some people) it's just a great way to make two devs produce the output of one intern.

* * *

> I don't think this is an intrinsic quality of working in the same space

It's certainly not.

I'd chew my arm off to have that 40h a week pair programming experience to be honest.

Sounds like my dream job.

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

Have the 10 second conversation over video

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.