Working asynchronously | Hacker News Reader

Working asynchronously

blog.remote.com

266 pointsmarcelo_lebre103 comments

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-time conversation rather than 3 days of back-and-forth e-mails. If the team is willing to fall back to synchronous comms when necessary, then defaulting to async communication for the other 95% of communication can work.

In my experience, the biggest pitfall is when developers try to force 100% asynchronous communication at all costs, no matter how slow and inefficient it becomes for everyone else. All team members must be willing to recognize when synchronous communication is necessary and carve out 15 minutes to an hour a couple times a week for those important, synchronous conversations.

Efficient communication is everyone's responsibility, and asynchronous communication is only a win if it doesn't create unnecessary extra work for everyone else.

This has 100% been my experience as well. All too often it's seen as an all or nothing thing, and it's the parts where discussions should be handled on calls that give it a bad image.

Agreed. Async communication doesn't belong in sync situations nor vice-versa. Trying to solve everything with one strategy is indeed an anti-pattern.

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 resource. It takes discipline to write procedures, policies, boring documentation, or to make sure that the authoritative source of truth for your project still reflects reality.

Those 3 days of back and forth emails, or the 15 minute working session, may need to exist for some situations. However I've found that people can work to reduce those 3 days to several hours as long as the answers to some questions are available in up to date documentation.

I have a couple of team members right now who don't want to write certain documentation, or don't feel they need to edit existing documentation to improve its legibility. The most often heard excuse has been "it only takes me 15 minutes on a call to do the task". Which may seem fine from that perspective. That person doesn't realize that they've spent multiple days worth of hours spending 15 minutes on something when if they had spent 2 hours writing the documentation, they'd be saving precious time and priceless context switching.

(I'm a new team lead. I'm enjoying it greatly, and find these sorts of inefficiencies both fascinating and revolting)

This is exactly where writing docs epitomises Larry Wall's "laziness" virtue.

http://threevirtues.com/

A lot of my "formative years" in IT were spent in several Perl environments, but it's been a while since I heard those 3 virtues so succinctly put. Thank you :)

Thank whoever put the website up!

The text is pulled verbatim from the camel book[1].

I somehow assume that "everyone" has used or had access to a well thumbed copy of the camel book, but realize that it's a product of place and time

[1] Programming Perl https://g.co/kgs/ZnNHTJ

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"

>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 anything, but because it's fuzzy, nobody remembers what it was exactly said, and usually ends up with people wasting each others time (like Diltert-style meetings).

I'd much rather people knew how to communicate effectively on chat.

But people don't, so you get messages like:

"The service is broken!"

"[panicked] What do you mean? Is it down?"

"It doesn't show anything"

[still panicked] Really? Let me see... Hmm, I see it working properly, loaded the first page and everything. What do you see?"

"I don't see anything"

"[???] On the first page? On some specific panel? Have you entered something?"

"Entered? I clicked and got nothing"

... and after 20 more minutes you realize they are on the third tab of a particular page, which nobody ever uses, have entered some search term people seldom enter, and got no results there, and everything else is working fine...

Better to figure that out in a 15-minute sync up than to get a pager duty alert from a Blocker level ticket that your "service is broken"

"I always hated "15 minutes of real-time conversation", not because of being an introvert or anything, but because it's fuzzy, nobody remembers what it was exactly said, and usually ends up with people wasting each others time (like Diltert-style meetings)."

I'd say the solution is to attack those problems directly.

There are some things that just work poorly asynchronously. I find heavy-duty explanations of something, where you need the highly-interactive back-and-forth is necessary, and honestly, even just trying to type something is wasting minutes vs. saying it, is a common use case for me. Getting 4 half-distracted managers who are lobbing emails at each other into a quick conference to resolve the matter is sometimes a really good idea, too, because the "lobbing emails at each other" is a political minefield. A lot of potential for hurt feelings and miscommunication that can be avoided just getting everyone in live voice chat, with their full attention, for even just 5 minutes sometimes.

4 managers to one dev is a ratio that warrants a very quick change of jobs.

No, I mean, some sort of cross-team functionality where you need broad agreement, not four managers all trying to manage literally the same thing.

I probably do more cross-team stuff than the average dev, but in anything beyond a trivially-sized organization, managers are doing it all the time.

I think the chat in this example still basically counts as synchronous, and the issue is more to do with people being poor at organizing their ideas in text vs. spoken conversation.

Truly asynchronous communication would force them to put their whole thought down on paper at once and perhaps organize it better, or at least allow you to skim. But then of course, async is poor for time sensitive issues anyway.

> I'd much rather people knew how to communicate effectively on chat.

> But people don't, so you get messages like:

So what you're saying is that you don't actually mind the 15 minutes of real-time chat, what you mind is that some people don't know how to effectively communicate.

This is one of those cases where a picture is worth a thousand words. It's amazing to me sometimes how many support requests I get where there is no information about what is wrong, no screenshots, no log files, not even a couple sentences about what they were trying to do and what they expected to happen.

Although it's almost worse when they send along a JPEG screenshot that has been downsampled >50%, so all the details are too blurred to make out.

It's especially frustrating when you're dealing with timezone shifts that make the average time to get a round-trip email reply from the other person take a dozen hours or more

I actually enjoy real-time meetings, as long as a few conditions are met:

1. A concise, realistic agenda is distributed to all attendees beforehand, and actually followed 2. A single person takes concise notes, with a heavy focus on action items and official decisions; the notes are distributed promptly at the end of the meeting (or better yet, real-time via a shared document) 3. Each action item is given a single assignee and realistic deadline

Your chat example seems like it could be solved with a 5-minute screenshare.

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.

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

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

Here's a helpful rule of thumb for when to use synchronous communication:

Is the conversation ambiguous and is there a high likelihood that you will be misunderstood?

An obvious tell for this is when you go back-and-forth over Slack/chat for a few minutes and people still feel like they are on another page.

I strongly recommend checking out media richness theory. It presents a helpful way to think about what communication medium is most appropriate for a given scenario.

https://en.wikipedia.org/wiki/Media_richness_theory

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

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.

How exactly would you identify such a situation when a real-time conversation is more productive? And do you think that everyone involved agrees in the same way on this?

It would be interesting to analyse such situations further, and maybe there are actually ways to resolve it in a more productive and efficient way which does not require real-time conversation.

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 just use existing tool X to solve this problem?"

Communication is hard. Engineers use buzzwords. Product uses buzzwords. Companies use buzzwords. Combine all these and you get a soup of overloaded terms e.g. "service," "connect," "access," "resource," "platform" that have a wide range of potential meanings.

You might be right but you also dont seem to be making room for the possibility of improving, learning, and making it easier to write those docs. You dont need to have a blank piece of paper and average engineers shouldnt need to guess how to fill in a memo.

This is tongue firmly in cheek, but I think it really drives home your "Communication is hard" point.

Have you tried reading the meeting agenda and minutes the average engineering manager 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 in the meetings e.g. "Why don't we just use existing tool X to solve this problem?"

Yeah, but the point is, I can ask all of those questions in the meeting if I'm there in person.

You could also read documentation and ask questions about it. And unlike meetings, everyone won't just forget the answer and have to have the discussion next week.

Agenda? Minutes? I've heard tell of such a thing, but I've yet to meet a manager that actually performs these arcane acts. I've gotten very used to walking into meetings with no more idea of what's going to happen than I can glean from the participants list and the subject on the calendar item...

Oh, cool, we must work together.

I pushed my team hard to get some discipline around meeting agendas. It lasted for a week or two. I threatened to stop attending meetings otherwise. My Director told me to knock it off. So, the signal is clear, right? We're all just fucking around and playing pretend at being professionals.

Ah ah! I did and I do. That's why well written documentation is more than a "good to have", it's as important as the code itself, same as good tests.

Communication is always a challenge and no big or small company has fully cracked it for sure. Average engineers - whatever that means - need training and meaningful tutoring. The team should aim at becoming better, not settle for whatever they have at the moment.

It really depends on the meeting. Meetings that revolve around basic information sharing (typically the recurring ones) like status updates or daily scrum can 100% be replaced with a written update. These are the meetings people hate.

A great meeting is when the right number of people discuss an ambiguous problem that requires a fast feedback loop (body language, tone, etc) in order to achieve the desired meeting outcome.

I'd also argue that poor documentation is a result of lack of structure (something asynchronous communication can provide much better vs. synchronous comm)

> Have you tried reading the documentation the average engineer makes?

Yes. Don't hire the average engineer.

Or raise your bar for average. If communication ability is important to your org, hire some folks to mentor and coach your engineers. Measure them on their communication and documentation abilities, and reward them when they meet or exceed the expected level.

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

A lot of engineers hate documentation and meetings. It's their managers job to make sure they do the boring stuff that the organisation needs.

If a manager says "remember to do some meetings" at the start of the year then never follows up on ensuring those meetings are actually effective, those meetings might be a waste of time. If they say "remember to do some documentation" at the start of the year and never follows up the documentation will be a waste of time.

If managers are spending more time making meetings a big priority, maybe it's because unlike documentation they get to feel like a real leader because they are running effective meetings. Maybe managers just like meetings more than documentation. Maybe it's higher value to the organisation as a whole, but I doubt it.

I feel like there is an insight here about working by yourself, too, that I cannot quite put my finger on.

Even if there is no team, you don't want to self-interrupt your own work. Well, we know that hence we invest in internet blockers etc.

However, if you are interrupted, it is best if you recover quickly. That is to say, if you can set up your own work so that it is planned in bite size components, and you know exactly where to pick up, you are better off.

This is like making an outline, and keeping track of where you are in the outline, except at the level of detail you need (say 5 min increments). Or perhaps you have a short hand of tracking where you are during an interruption.

So, if someone says excuse me, you take 12 seconds to quickly note what you were about to do, and if you are about to self interrupt, you do something similar.

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?

I'm not the person you asked, but I do the same using Emacs' org-mode[0], but there are many tools around such as the Leo Editor[1], or really, any editor with a decent markup language support will do.

I store all my org files in git repositories and sync them across devices, allowing me to work on multiple devices and worry less about losing a particular device.

[0] https://karl-voit.at/orgmode/

[1] https://leoeditor.com/

Tried this for a while, but unless I have the window open, I don't use it. I use Wunderlist to track the "projects" that I have in my head at any point in time.

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.

It's rude to interrupt someone without giving them the time to put down whatever it is they're doing. Even if it takes more than a few seconds.

That problem is solved through humility and social graces.

"Hold on a sec, I just wanna write down what I was doing so I don't lose my place."

If you want to add more, after writing it down, you can follow up with, "sorry to keep you waiting, but when I get interrupted I often forget some useful details about what I was working on, and I want to get that down before it leaves my head".

(The "when I get interrupted" is a bit of a cheeky way to point out "you are imposing on me, so the least you can do is allow me this".)

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.

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.

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

I agree with this, but there's a pitfall. Lets say you want to get conversation done at either the start/end of day or both. This is efficient because then you can work interrupted throughout the day. However, when you're not available to answer every ping right away or your "online" status isn't green, then it puts you in a bad light because the managers think you aren't working and/or don't care/aren't a team player.

I find I do much better at coming back to solo/personal stuff if I use an issue tracker anyway, even in the early stages where I'm not so much managing bugs as chunking into bite-size pieces as you describe, so I always try to do that now.

It makes me less likely to leave the repo with some staged changes, some unstagrd changes, and no idea what I was doing when I come back to it - but even if that does happen it makes it easier to work out.

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.

This is managerial nonsense.

> An even, swift and nimble pipeline produces exactly the right quantity of output for its requirements, and all its stages are balanced in terms of efficiency and speed. Resulting in no waste of time or resources.

Aside from containing neither a subject nor a verb, this last sentence is an impossible claim. Anyone who intends to hold the author to the quality of their reasoning would stop reading there. Only people who can say “upward revenue stream dynamics” with a straight face will read on.

A single logical sentence has more value than a page full of poorly written false claims and regurgitated platitudes.

I've been a manager of different teams for a while now and I must admit that every form of management or productivity strategy is nothing but written nonsense in good form - or common sense in fancy terms.

I spend several years managing an all-remote team that ranged from Perth WA to Seattle WA. We worked 90% pure asynchronously and 10% using video chat (or physical get-togethers from time to time). It was highly productive, and because it was all open source development any lack of productivity would have been obvious.

I now commute to an office where we all work asynchronously but are expected to appear to work synchronously, as is traditionally expected. It is less enjoyable, frequently subject to context switches (you need to synchronize with the dominant worker) and certainly no more productive -- although that's hard to tell since everything is secret and need-to-know.

I would say working asynchronously is better for intellectual workers. Most intellectual work places that claim to working syncronously are either working under an illusion or under a bad manager with a "my synchrony" attitude.

I work on a distributed team on an asynchronous video app (Marco Polo) which makes a lot of conversations easier (sharing bugs, non-urgent conversations, personal connection) but we still Zoom for many meetings. Asynch has virtues even for in person teams but it just isn't optimal for everything, especially discussions leading to decisions that can then be executed upon.

I get the idea that remote.com is trying to trademark the term "remote". F that. The best way to stop that is to prevent remote.com from getting a lot of brand recognition. I don't care how much they want to contribute to the remote worker community - there's no way it will make up for stealing the identity that we have for ourselves.

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 also other companies like https://remote.co/ that are already using the name remote, but remote.co is respectfully calling themselves remote.co instead of just remote. Having a .com shouldn't be a ticket to appropriate a common word and turn it into a brand.

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

Love that you feel so passionate about it! We are part of that community, and we're doing this so that more people can enjoy working remotely as well. It changed my life in many positive ways and there's nothing we want to take away from it, quite the opposite. We own the domain, we don't own something that is a way of life for which we have tremendous respect.

You own a domain. That domain doesn't give you ownership of the term remote. You seem to be trying to appropriate it and I hope that doesn't happen.

Remote to my grandmother is what she uses to change channel. To us is a way of life. It means different things to different people. There's no appropriation being done here, nor do we plan to do so. We fundamentally respect what it means to be remote and we're only a way to improve it and make it more mainstream, nothing more.

Nah it's just a lucky domain name, nothing more.

Do you feel the same about testingjavascript.com? It's just a lucky domain or they spent a lot of cash on it. Relax.

It's not the domain name I have an issue with, it's the brand. Other domains about an abstract concept such as care.com and art.com have .com in their logo. Some, unfortunately, don't. I've seen tech companies take over other terms and I don't want it to happen to the term "remote".

As for testingjavascript.com, it isn't comparable. It's two words and a lot more specific than "remote".

The way we've struck a balance at our company is to only allow meetings in the mornings. In the afternoon, everyone can be off Slack, heads-down, and programming or doing other deep work.

This halves the number of timeslots that are available to have time stolen from you, but allows us to get the empathy and quick resolution that real-time communication enables.

Ya that is a good one, we did something similar with meetings only on M/T/W, and any outside of that had to be directly product-related and engineer only.

I guess it's impossible to please everyone, but I would be miserable with this setup. I'm far more productive in the mornings and have managed to keep most of my meetings in the afternoon so they don't interfere with my productive time. Only allowing meetings in the mornings would probably cut my productivity in half or more.

This sounds great, and in theory should work on a well integrated team of autonomous individuals. I guess as in most things, common sense is the key requirement to make this a reality. Alas, common sense isn't very common...

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.

People hate meetings because they're in bad meetings. We spend so much time in meetings without giving them much thought to designing them. I highly recommend the book "The Surprising Science of Meetings: How You Can Lead Your Team to Peak Performance". It covers different types of meetings, including remote meetings and when not to have a meeting. This podcast interview with the author is a good introduction to the book:

https://www.gayleallen.net/cm-127-steven-rogelberg-on-making...

This is essentially the same problem schedulers run into. It's a latency vs throughput trade off. The article is underlining that blocking is bad, & lots of tasks may receive cancellation signals

I've worked in low latency environments, but I prefer high throughput. The latter is more conducive to flow state. It also means people aren't relying on my consistency, where some days my brain turns on & some days it doesn't

What I've discovered is your team needs to be fairly senior already for this to work at all. I once worked with a team where, shall we say, "talent" was extremely uneven, and it was pretty miserable. It was a very small team, only 3 people, and one of the 3 saw no issues with "synchronizing" threads with wait/sleep loops, paid no heed to coding standards, and just in general turned in shit code others had to waste their time to fix later. Worse yet, he was extremely defensive about any issues we brought up, to the point of not even hearing what we actually say. In his mind, any critique of his code was a personal attack and nothing else. Code reviews were multi-week affairs, leaving him extremely pissed off, and what got checked in was still below par compared to what the other 2 devs were producing.

If that person were in the same office, it'd be much easier to browbeat him into compliance and teach/mentor him. But he was halfway across the globe, so we suffered through it for ~6 months and then let him go, further reinforcing his belief he was being personally attacked. Not a good parting of ways.

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.

Async communication makes a lot of sense.

Their "async planning" bit doesn't mention context switching though, which is an important omission.

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 issue I take with articles like this is that they think of humans as robots. That walk in, or sit in front of their computer at 9, type for 8 and then go home/stop working.

But let's be honest here, If you can keep highly focused for more than 4 hours a day you are a superhuman. I know keeping this in mind doesn't take anything away from the article. Yes we should focus more on Async productivity, but work our work is definitely not single threaded. We are humans, If I hear my teammate 2 desks over signing for the 3rd time I can do 2 things. Ignore it, not getting out of my flow. Or stand up, talk to him/her and see whats up. Maybe it's only a complain about Entity Framework migrations being a b or perhaps just tired, and gets annoying by small things because something happened last night and its time to vent a bit.

recently I've started listening to this podcast https://hurryslowly.co/ . Although I do not identify with everything discussed, I do think there is source of truth in a few episodes. It just makes me consider, are we optimizing the right things first?

I really wonder, if all this no meetings, no distractions is really the key to making us more effective at our jobs. You can't really measure it, does the hour in a meeting really makes you an hour less productive? Is it more like 15 min? Or did the distraction actually helped instead of bashing your head against the wall for over on hour trying to figure out the solution?

I wonder the same about all those gosu vim/emacs users, it sure looks fancy dancing with your fingers doing edits. But where does the real work happen? Is is the amount of lines written or the amount of quality information processed in my mind about the solution I'm looking for?

In the end..

- Be human - Try to have clear borders about distractions in your team - Turn all slack notifications off - Don't have meetings that could have been an email. - Don't send emails about stuff that could have been a meeting

I'm really curious about working in a distributed team though, sadly I didn't really had the chance yet. I think working remote has it own con's and pro's.

I do applause the auther for thinking about this, I think reflecting on how to work better is always a good idea. But It could also easily be a recipe for a burnout.

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.

Everything we do professionally can be a recipe for burnout. We also have strong policies to prevent it but that's another topic altogether.

A "short-ish" article written in an afternoon has no hopes of being a tablet of truth, just some anecdotal examples and ideas I've experienced over the years.

I fundamentally agree with the "Be human..." part, that's all you need if common sense is common around your workplace. Unfortunately it often isn't and you need to offset the unbalance to find equilibrium.

Great now how do I convince my team this is a good idea, overcoming super ingrained and traditional working concepts?

One step at a time. And if that doesn't work, then you find another team ;)

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.

IIRC, remote.com is founded by a Gitlab alumni, funny to see this as #1 with all the Gitlab outrage going on.

Yep me, together with the author of the post, Marcelo.

I would love to, but my coworkers expect me to be synchronous. They do async, but I'm always supposed to be sync with five nines availability.

Looks like it's time to go job-hunting again, but I hate job interviews. Dammit.

At the end of the day your mental health is worth a lot more than a few interviews ;)

Interviewing generally has a significantly negative impact on your mental health... but at least it's temporary.

If only job interviews could be async!

Companies have actually done that, and it's worse: They're the "homework" interviews.

I don't mind "homework" interviews, they let me collect my thoughts and put together something representative of my work. It's easy to ship a complete (toy) product for a trivial problem, show unit tests, documentation, written communication skills, etc.

Much better than a timed coding challenge in my book. It's only bad when the problem isn't you know, a toy. Sometimes you have to reply with your consulting rate.

I wouldn't mind the homework interviews if they paid me to take them. In fact, on-sites should be paid also.

I'm hiring for our team. All of the feedback I've gotten from candidate was that it's fantastic because of the take home interview. No need to sweat and tremble over whiteboard questions.

Do you prefer those?

As a practical matter, I'd probably prefer a take home assignment OVER an in person interview. However, doing both would be a non-starter, that's too much work.

You should try and change their expectations. Often times it's not because they want to take advantage of you, they may just think you can handle distractions better than they can.

I recently tried to bring up the fact that our new management and various members of our team all seem to have different expectations for responses via different mediums and that maybe we should document some company or team-wide guidelines for expectations.

I was told it is not valuable by the new management.

Sometimes, they will take advantage of you, even if just through ignorance.

Good luck on the job search. You'll likely make more money in the end with the new gig. Start today!

>I would love to, but my coworkers expect me to be synchronous. They do async, but I'm always supposed to be sync with five nines availability. Looks like it's time to go job-hunting again, but I hate job interviews. Dammit.

I hate interviewing too, but don't let that stop you! Learning to be great at things we avoid/dislike improves us as human beings. It is important to be happy with the work we do.

Reply on news.ycombinator.com