Live data from Hacker News

Working asynchronously

blog.remote.com

91–100 of 110 posts

Re: Working asynchronously

#91
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?

Pen and engineering paper, chronological with bullet points. When the paper is full, I copy any items that are not already checked off or canceled to the next piece of paper (or to a note taking application--still looking for a good one, trying out cherrytree). Any item that gets copied gets a line through it. Canceling an item is putting an X in front of it instead of checking it off. Old pages go into a 3 ring binder.

Items don't have to be tasks. They can be ideas or general notes.

Re: Working asynchronously

#92

I think it’s armful to the idea of remote work that it’s being equated with async work.

Async work is but a tool, a methodology, remote is a way of life/work. I advocated async work when working office-based as well, the same principles still apply.

Agree, it’s also harmful to async that it’s being equated with remote.

Re: Working asynchronously

#93
Not directly related to the post, but something I've been thinking about a lot:

My life satisfaction and work productivity increased significantly when I stopped working from home and began working 8-5 at an office. There were so many things I took for granted:

  - Face-to-face interaction with co-workers.
  - Casual conversations to break up the day.
  - The rhythm of a commute.
  - Not struggling to find a spot in a crowded coffee shop.
  - The productivity boost of working alongside other people who are working.
  - The consistency and routine of normal working hours.
  - The ability to pair program, in person.
  - The ability to be productive with my team even if the internet is slow (or out completely).
I worked from home for six years, and I don't think I'd ever go back. I'm not saying remote doesn't have its place, but I've found that I greatly prefer working in-person with other people.

Re: Working asynchronously

#94
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…

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

Re: Working asynchronously

#95

imo think twice add a “bugs” channel to your slack/chat. it invariably gets used as a place to inject panicky statements, ask for status and features...just make sure whatever ticketing system you have is well understood by all stakeholders.

What you need is a form of moderation. An actual group of workers who's job is to collect data, validate a test case is reproducible, or at least that there's telemetry of a problem having happened. In edge cases they could at least collect some data and try to isolate where a problem might exist so that better tests / data collection can occur.

Re: Working asynchronously

#96
post #38

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

> 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 the error message"), I've lost track of whatever I was doing and wasted who knows how much time.

Re: Working asynchronously

#97
I find using an asynchronous-first chat platform like Zulip (as opposed to Slack) is crucial to my ability to work asynchronously. Without compartmentalization of topics into mutable sub-topics, it becomes a huge mental burden to log onto chat every day.

Re: Working asynchronously

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

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

Re: Working asynchronously

#99

I want to call BS on the statement "Most meetings can be replaced with documentation." Maybe in an ideal world, but no. Have you tried reading the documentation the average engineer makes? It's like a freshman essay -- lacking in cohesion, vision, context. It's usually completely unstandardized across teams. And 9 times out of 10 the most fundamental questions aren't answered by the documentation e.g. "Why don't we j…

> Have you tried reading the documentation the average engineer makes? Yes. Don't hire the average engineer.

Or be willing to train. It's a tough skill and seems to have few mentors

Re: Working asynchronously

#100
post #61

There are basically only a few things I agree with in this article, the rest is so shortsighted and heavily tunnel-visioning about some ideal world. The thing I agree with, yes being distracted takes time, focus and productivity. I'm all for being more into more deep work etc. Also the part of people need to be proactive rings true of course. But I fail to see how something that evident really needs a graph. But the…

I do think you can try to measure it, and we are taking a stab at it with an app that analyzes your online calendar app, you can see an example report here: https://app.shepherd.com/personal-report/sample/pages/my-wor... It isn't perfect but we try to show how the meetings split apart your day and your capacity to do deep work.

[deleted]
Post reply on HN