Live data from Hacker News

Working asynchronously

blog.remote.com

101–110 of 110 posts

Re: Working asynchronously

#101
post #69

I've managed multiple remote, asynchronous teams across multiple countries. When people work in opposite time zones, asynchronous communication is mandatory. When it works, it's a great experience. However, async communication isn't appropriate for every situation, as the article admits. Some times, the most efficient way forward is to schedule a call where all parties can work out the solution in 15 minutes of real-…

"In my experience, the biggest pitfall is when developers try to force 100% asynchronous communication at all costs," In my experience, the biggest pitfall is when non-developers try to force 100% synchronous communication at all costs. I always had the experience that there is a struggle to get people to accept async work because everyone thinks it's normal to call everyone all the time.

I couldn’t agree with this more. My org is full of people who love meetings. On average it’s 30 hours of meetings per week, absolutely insane. I’ve been training people to not invite me so it’s down to 10, but still higher than I would like.

Re: Working asynchronously

#102
post #33

Earlier quoted context omitted.

I think that there is a tragedy-of-the-commons issue here that some teams or organizations just aren't very good at tackling. Everyone's time is a valuable resource. It's quick and easy to demand synced communication, but that depletes the time people can dedicate to longer tasks that should not be interrupted. Now take the team's collective time. That's the commons, and poor work discipline drains that shared resour…

This is exactly where writing docs epitomises Larry Wall's "laziness" virtue. http://threevirtues.com/

I know this is quoting a classic text, but "Hubris" bugs me here; it seems like the virtue being describe here is pride or ego, not hubris.

Hubris implies excessive pride and ambition; pride that is oversized when compared to your ability. It has a negative connotation.

Re: Working asynchronously

#103
post #98
post #69

Earlier quoted context omitted.

"In my experience, the biggest pitfall is when developers try to force 100% asynchronous communication at all costs," In my experience, the biggest pitfall is when non-developers try to force 100% synchronous communication at all costs. I always had the experience that there is a struggle to get people to accept async work because everyone thinks it's normal to call everyone all the time.

Balance. Chat on mattermost for all day noise, dm and open webconf for the Swarm on the problem, combined notes on ticket for historical.

Most is also cultural fit.

Some peole need three calls until they understand what I'm telling them.

For others it's three slack messages a week and we are all good.

Re: Working asynchronously

#104
post #101
post #69

Earlier quoted context omitted.

"In my experience, the biggest pitfall is when developers try to force 100% asynchronous communication at all costs," In my experience, the biggest pitfall is when non-developers try to force 100% synchronous communication at all costs. I always had the experience that there is a struggle to get people to accept async work because everyone thinks it's normal to call everyone all the time.

I couldn’t agree with this more. My org is full of people who love meetings. On average it’s 30 hours of meetings per week, absolutely insane. I’ve been training people to not invite me so it’s down to 10, but still higher than I would like.

This.

I don't think 100% async is the way, but I think it's easier to end up with too much sync than with too much async.

Re: Working asynchronously

#105
post #4

Earlier quoted context omitted.

I've learned to take a lot of notes, make frequent checkpoints (e.g., git commits), and break things down into small pieces, just to deal with interruption--minute to minute (people asking me questions), day to day (fire drills, bugs), and week to week (constantly changing priorities).

Do you use a tool for this?

Not the same person, but I keep a text file divided into two sections - "history" and "today"

The "today" section is a bulleted list of the things I think I'm working on today. I add to it through the day as I get shoulder-tapped, or as I realize another important sub-task.

As I finish tasks, or at the end of the day, I move them up into the "history" section under the current date. Thursday: A, B, C

This is basically all of the "head state" in the infamous cartoon of how you ruin engineers lives by interrupting them. I feel that it allows me to be interrupted without losing import state, and it's also a ready-made "scrum status" of what I did yesterday, and an augment to my memory when someone asks me "did you change X?" for some micro-task that was too small to ticket.

I feel this has helped me be a more effective developer, in spite of my decaying memory, than I was when I tried to keep everything in my head. :)

Example contents: https://imgur.com/a/VI64Jx6

Re: Working asynchronously

#106

Earlier quoted context omitted.

Many years ago, I did some volunteer work at a homeless shelter. The second highest person there was not tech savvy but had to fill out a lot of their paperwork. She once thought she had "lost" her entire spreadsheet because she scrolled too far down to a blank section of the spreadsheet.

Cool story bro

I feel like the people on HN have less humor than a bag of wet dog shit.

Re: Working asynchronously

#107
post #33

Earlier quoted context omitted.

This is exactly where writing docs epitomises Larry Wall's "laziness" virtue. http://threevirtues.com/

I know this is quoting a classic text, but "Hubris" bugs me here; it seems like the virtue being describe here is pride or ego, not hubris. Hubris implies excessive pride and ambition; pride that is oversized when compared to your ability. It has a negative connotation.

IIRC the camel book cautions about excesses in each of these "virtues.

I've always been amused by the concept of "excessive hubris"

Re: Working asynchronously

#108
post #19

Earlier quoted context omitted.

I'm not the same person, but I have a small notebook and pen. Any time I think "Shit, how am I going to remember this if I get interrupted right now?", I quickly scribble down as much as I can and continue working. This is invaluable when I do get interrupted. I do this basically any time I feel like my short-term memory is overwhelmed with facts, and as a result the notebook has effectively become NVRAM for my brain…

This is the closest to what I do myself -- I always have pen and paper on my desk -- but the real issue is that I don't take a note when interrupted because of social pressures (its rude to ignore someone for a few seconds). I don't even do it for myself for self interruptions because I forget to.

For me, a quick "hang on" or "sorry, one sec" acknowledges people enough that they don't feel ignored while I make my notes, and is also scripted enough that it doesn't usually knock the thoughts out of my head.

Re: Working asynchronously

#109
post #38

Earlier quoted context omitted.

> When it works, it's a great experience. However, async communication isn't appropriate for every situation, as the article admits. Some times, the most efficient way forward is to schedule a call where all parties can work out the solution in 15 minutes of real-time conversation rather than 3 days of back-and-forth e-mails. I always hated "15 minutes of real-time conversation", not because of being an introvert or…

"Hi" [says they're typing, work on something while I wait] [6 minute pause] "Are you there?" "Yes" "I'm getting an error when using [tool]" "What's the error?" [2 vague barely related lines in a long error message or traceback] "Could you show me the full error message and the command you tried to run, please?" By the time the full troubleshooting process is over (which usually amounts to "follow the instructions in…

This is the thesis of http://www.nohello.com/

Re: Working asynchronously

#110
post #32

Earlier quoted context omitted.

I dunno, it's just clever company naming, like Meetup. I don't think it's stealing an identity. It's also a risk for the company, because the trademark isn't defensible. Google's legal team doesn't like the fact that people use to google as a verb. The extreme form of that would be Microsoft being able to say, "Now you can google better with Bing!"

Being remote is a lifestyle, where as a meetup is an event, so I think it's worse than Meetup. The brand Meetup is problematic though. It makes it harder to talk about events without accidentally dropping the name of a company. Meetup may have gotten a pass because they've done pretty good, but they are now driving away their customer base ( https://www.theverge.com/2019/10/15/20893343/meetup-users-fu... ). There are…

> Having a .com shouldn't be a ticket to appropriate a common word and turn it into a brand

It isn't. You've got to have a great marketing team, too. Remember when UPS tried to make "Brown" synonymous with UPS? Having the domain name isn't a prerequisite for that kind of effort.

Post reply on HN