I've been working 100% remotely since 2018. In that time, I've been lucky to work with folks who have extensive telecommuting experience who have laid the groundwork for healthy WFH practices. I've also been lucky to have worked for companies that believed that remote working had distinct advantages to offer (rather than just a perk), whether they were remote-first or not. I think it's also no coincidence that some of the best engineers I know are seasoned remote workers, so here are 5 things that have contributed to my growth as an engineer.

1. Getting over the fear of the unknown and unblocking yourself

At my current company, we have over 250 repositories. In the past 2 or so years, I have committed code to 25ish repositories and used maybe 40. That's a lot of code, local setup guides, deployment processes, pull request etiquettes, cloud configurations, etc. Not knowing how to find/fix/do something is just an everyday part of the job. My onboarding experience covered maybe 3 of these repos/products in any length; much of the time, the first time I ever saw or even learned of a codebase was when I had to fix or implement something in that code.

And you know what? I think that's totally okay.

Give a man a totally comprehensive and up-to-date guide of X, help him for a day. Teach him how to find information on any service, help him for a lifetime, right?

I'm not saying that there is glory in doing something completely by yourself. But embracing the challenge of doing something new independently, defaulting to "let me see if I can figure this out first", and facing the aspects of software development that you are not familiar with or even afraid of (for me that was things like configuring a local db or working with an unfamiliar cloud setup), well, that is a highly useful super skill.

Figuring things out yourself versus asking for help is a delicate balance. This is something I learned through trial and error, and a big part of it was also that I've never been in the same timezone as the majority of my teammates, so sometimes asking for help wasn't an option unless I wanted to wait 3 hours for an answer. I would say, if something is taking more than 30 mins to an hour and someone else can help you, it's time to reach out. And when reaching out, ask them to show you how they found the answer, which you can add to your problem solving toolkit.

2. Prioritizing unblocking others

I've lost track of how many of these types of messages I've sent and received:

It's just a lot easier for certain things to fall by the wayside when everybody's working asynchronously. At least I found it easier to get other people to do things when I could casually drop by their desk.

And there are for sure processes that can help with this. But for me personally, this is also an opportunity to shift my way of working so that others can consistently and reliably count on me to get something done for them in a timely manner. To that end, the first thing I do at work each day is to see if there are any code reviews I need to do. I also block time in my calendar to check internal and external channels to see if anyone needs something from my team, and try to help them in the clearest possible way, including explaining how I found the answer if it was something that I had to look up.

3. Using Slack as documentation

Not as a substitute for actual documentation!! But at least at my current company, Slack is probably the most useful starting point for technical information, full of people sharing handy shell commands and how they fixed that ConnectionError. I often find myself pasting an error message into Slack before StackOverflow.

This probably isn't true of all companies. But there is always an informal, written medium where developers go to share and search for technical things. There are a lot of things we can do to make that a pleasant experience for everyone, including:

• Writing messages that are concise, friendly, and most importantly difficult to misunderstand for both technical and non-technical folks
• When you ask a question but then figure out the answer yourself -- don't delete the question! Update it with the answer and how you found it
• When answering a question, if possible, include how the answer could be found (in the code, in other documentation, etc)
• Updating old threads when you come across an outdated answer
• Sharing useful scripts, queries and configurations that might not make sense to be checked in to version control
• Sharing tips and "guides" for working with a particular technology (IDE setup, deployment steps, testing commands, etc)

4. Speaking up in meetings when I have something to say

Virtual meetings are harder to navigate than in-person meetings. Even with the video on, it's hard to quickly gauge interest or confusion or if someone has something to add. And with the video off it's basically impossible. It can be really hard to find the "right time" to speak, especially if other folks are not giving all participants the space to talk. I have interrupted and cut people off -- and felt horrible about it at the time -- but I've been thinking more and more that it's okay.

The fact is that if you wait for someone to ask for your opinion in a virtual meeting it likely won't come. It's not a malicious act -- simply just that we, in our in-person social interactions, find it much easier to see when someone has something to say, and when there's no delay from our audio packets going through the internet, it's easier to find that miniscule pause to interject. We just lose all that in Zoom.

So I gave myself permission to say what I want to say, when there's a reasonable time to say it. And I won't feel too too bad if it means that I do interrupt someone -- if it happens I will acknowledge it and encourage them to finish their thought after I've said my piece.

5. Consciously and intentionally inviting others to speak

Let's just all do this. I personally find that "does anyone have any questions" good but a bit boring, and no one likes to hear crickets if there are no questions. Some other ones I like are:

• Does that make sense? (Easy yes/no answer)
• Can I make anything clearer? (Easy yes/no answer)
• What can we do specifically about X? (Specific question)