[deleted]
Remote work requires communicating more, but less frequently
131–140 of 326 posts
Re: Remote work requires communicating more, but less frequently
#132I think gaming is very similar to remote working. You log in when you sit down, put in your headset and typically are available. Work isn’t much different. My team leaves zoom standup open all day, we break into conversations all the time. It both (a) keeps everyone engaged and (b) removes blockers fast. That said, we setup side “rooms” we can move in and out of. There is also the option not to be accessible, but it’…
How long have you been doing this? Curious, bc many teams tried something like this but it fizzled after 3-4 months.
(full disclosure, we're building a platform that integrates with Zoom to visualize all these rooms, and who is in them, so people can hop into the rooms where people currently are, and know when someone isn't available before joining, etc. would love to interview you for user research if you're up for it)
Re: Remote work requires communicating more, but less frequently
#133Earlier quoted context omitted.
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…
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…
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
Re: Remote work requires communicating more, but less frequently
#134in my current role at my current company, the opposite is the case. Daily sometimes hour long meetings talking about features and some crap and less time for the actual work. I hate it. Because I love to code, but I am constantly distracted. Everyone wants something from me... some people ask if I have time, some simply call, even if I am in another meeting already.
Curious: do you use DND in Slack or block your calendar in an effort to protect your focus time?
(full disclosure, we're building a platform that integrates with Calendar / Zoom / Slack to visualize who is available, who's in a mtg, and who is in Focus Mode - the idea being to help people turn to one another in real-time, but without distracting people who need to focus. Would love to interview you for user research if you're up for it)
Re: Remote work requires communicating more, but less frequently
#135This 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 confi…
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.
Re: Remote work requires communicating more, but less frequently
#136This 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 confi…
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).
> 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.
Re: Remote work requires communicating more, but less frequently
#137This 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 confi…
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?
Re: Remote work requires communicating more, but less frequently
#138This 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 confi…
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).
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.
Re: Remote work requires communicating more, but less frequently
#139Earlier quoted context omitted.
> 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…
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.
Re: Remote work requires communicating more, but less frequently
#140Earlier quoted context omitted.
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).
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 sometim…
> 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.