Skip to content
Home » Being Nice Asynchronously: The Discipline of Remote Working

Being Nice Asynchronously: The Discipline of Remote Working

Most tech workers work remotely these days, if not very regularly then at least once in a while. But how do we work with others when we work remotely? Do we even think about it? How can we make our communications more effective?

I find it slightly incredible that four years since the start of the COVID pandemic we are often still struggling to come up with new norms for remote-first working. As Devs, particularly slightly ADHD devs like me, we usually like to make progress in small repeatable steps. This is how we prove that going from one state of affairs enables us to go to another state of affairs in a controlled manner.

This, Baldrick, is the source of our power. Small steps that show us when things break.

So to that end, here are a few ideas that have popped into my head over the last few months as I work in a remote-first team based across two timezones.

Treat Your Human just like you would an AI

I recently sat through a GitHub Copilot demo where the presenter told us how a prompt engineering session is like a conversation. Then I was struck by this thought:

“A lot of my interactions with humans don’t have this much context. We seem to be showing our AIs more respect than we do our peers”.

Something could be inherently wrong there. Respect your peers and the AI. Give them both sufficient context.

Using Source Control

Source control is vital. Git is simple. If you don’t know it, learn the basics. Get used to committing and pushing regularly. Showing good discipline with source control enables you to share your changes quickly and simply with others regularly.

If you want quick feedback, put some work in to make your work accessible to others.

Your code is their context for when you have a problem.

Use Automated Builds

I originally called this point “Use Continuous Integration” but CI implies that we have tests. We don’t always have tests in our build pipelines. So, to begin with, don’t worry about CI and tests, just make sure that you have an automated build. Why?

Because when if someone is asking my help to fix a bug or configure a build I’m going to ask you:

  • What are you trying to do?
  • Where are you building this?
  • What have you tried already?

Having a build pipeline with your code in source control answers all of my questions. Thanks.

Be Specific with Your Question

If you’ve got a problem, then it’s good to have a specific question so that I can help you. Yes, knowing what a ‘specific question’ is, is not always easy, but you can prepare by thinking about it this way:

  • What question are you about to ask?
  • Does it make sense to you?
  • If you knew nothing about this problem would this question still make sense to you?
  • What can you do to make this question more likely to receive a good answer?

If you asked yourself the question you’re about to write to me, would it make any sense to you? Assuming I don’t know anything about your problem, what else would I need to know?

Google is Still Your Friend

It’s been true for the last 30 years and it’s still true. If you have a really specific question: did you already google it? Because a lot of the time when you ask me a specific question, I will google it. Because although it might surprise you to hear this, I often don’t know the answer off the top of my head.

Google is your friend.

Asynchronous Communication

The Good:

“I sent you an email summarising what happened after we got through that incident last night our time. Please let me know if you have any questions.”

The Bad:

“Good morning Richard”

The Ugly:

“Hi. Do you have 5 mins?”

Avoiding Placeholder Meetings

Respecting people’s time is the number one thing you can do. The number two thing you can do is to respect the work they have to do in between all the meetings your booking them into.

Please have an agenda and stick to it.

Always Prepare

I believe that the number one thing we can do before any meeting, before any interaction online or elsewhere, is to prepare a little for that interaction.

Perhaps this comes from me because, as a kid, I was a stutterer, and I had to prepare my sentences in advance. Maybe it comes about because I’m probably slightly ADHD, and without preparation and extensive note-taking, I get very easily lost. Or it could be because I want to be clear about what I know when I say something, and I want it to be right.

I like to think that it’s just because I want to show respect the people I’m working with. Therefore I try to turn up on time, prepared with all my ducks in a row.

Now, if we all did these things: would remote working life be better or would it just be boring and straight and icky?





Discover more from Richard Bown

Subscribe now to keep reading and get access to the full archive.

Continue reading