Now that you've made it as a remote developer, what do you
need to go that extra mile?
Hi, my name's Ting.
I'm a remote front-end developer here at Arc.
In this video, we're going to go over four tips to ensure your
success as a remote developer.
Onsite and remote may only seem to differ in where we work.
However, don't let that fool you.
Simply copying and pasting the way of onsite into remote work would not work.
There are aspects of remote that need alternative methods to be tackled with.
For instance, when developers move to remote, sometimes you lose out on a lot of
the development related watercooler talk.
What this translates into is opportunity lost with experimental technical
projects or just opportunities to spitball ideas back and forth.
These are the talks that organically occur when you're walking with your teammates
to go buy lunch or, you know, when you're just making a morning pot of coffee.
Unlike onsite, with remote, when you're pinging someone to discuss an
issue at hand, there's that inherent understanding that you need to have a
more formulated thought process rather than, hey, what do you think about XYZ?
I don't know.
While it's great that you're gaining back time from the lack
of commute, you have to be careful about your home and work boundaries.
Because if not, you might risk facing burnout from an endless grind.
So with these potential issues in mind, let's jump into four tips to ensure
your success as a remote developer.
Tip number one, you need a routine to maintain clear
boundaries between work and life.
Because if you don't, you're going to find yourself constantly
working from the moment you wake up to the moment you sleep.
This creates a negative cycle that leads to an endless grind, and
just the negative mental health.
Unlike onsite, there's clear boundaries.
When you're at the office, you're at work; when you're home,
it's time to unwind and relax.
However, when transitioning to remote, work and life happens in
the same location in your home.
This makes it hard for the human brain to comprehend when it's
time to switch off and rest.
You can start off with defining your physical work locations
and the rest of the home.
That way your brain can register when you're in the office, it's time for work;
when you leave your office then, you know, it's time to switch off and relax.
Asides from physical locations.
You'll want to create rituals to start your day and end your day.
This way it signals to your brain when it's time to start and end.
When to get into that scope of work; when to really turn off the mind and relax.
For instance, start off your day with a 5/10 minute walk around
the block, grab that extra coffee right before work starts.
Because getting your daily dose of sunshine in will boost your serotonin
levels, which helps increase your focus state and a state of calmness.
Remember, the brain only has so much capacity, so by having a sign on and sign
off ritual for work, you're able to signal to the mind when you're able to sign
off and recharge for the new day ahead.
While it sounds simple, it's important to be intentional about the time you spend.
Tip number two, document, document, document.
Documentation will be your team's best friend when you're remote.
When co-located, you can simply pull up a chair next to another
developer, ask details about a project.
That's not the case when you're remote.
Sometimes you might be facing teammates that are across time zones.
This means you might need to wait 10 hours plus for a response.
This is not sustainable and it becomes a bottleneck in the process.
Plus, it's super helpful to have documentation to look back onto to remind
you of certain architectural decisions that were made at the time, because
let's be real, nobody remembers the code that they've written three months ago.
Not only would this benefit remote teammates, but it's helpful to not lose
that valuable domain product knowledge when you have turnover within the team.
Simply documenting is not enough.
You need to have a proper system in place to ensure your teammates know where
to find information and how to use it.
Otherwise, this information quickly becomes obsolete when people don't know
how to find it or nor how to use it.
This was an issue that the Arc engineering team was actually facing.
We had information spread across GitHub and Notion.
However, teammates didn't know where to find the information they needed.
As we had existing information, we couldn't simply migrate
from one platform to another.
And plus, each platform had their strengths and weaknesses in terms of
demonstrating and showing the information.
Given these constraints, we had assessed the following factors to assess which
platform to use for certain topics.
These included frequency of change, ease of change, is this tool already built into
the developer's existing workflow, and expiring timeline on the documentation,
or did we need version control.
Between Notion and GitHub, we had deemed that Notion was easier and
updating, especially if documentation that was more frequent into change.
Just anything that had a shorter lifespan.
These would include process reviews, meeting minutes, retros on
features or onboarding materials.
Whereas with GitHub, we had dedicated it to more stable and constant information.
These include development guidelines, process guidelines, and just
front-end and back-end architecture.
While there are many collaboration tools out there, like GitHub, Notion,
Google docs, and so on, utilize these tools to their strengths.
But remember to have one central location that access a directory,
connecting all the information.
Tip number three, you need the right tools to support a remote
collaborative development.
It sounds like it should be pretty easy to find the right
tools for the job, but is it?
Having the right tools improves the remote development experience by
supporting the necessary collaboration.
Take pair programming for instance, it's known for its wide variety of
benefits, ranging from a better method of onboarding, a great way to share knowledge
and just higher code quality in general.
When pairing co-located, a developer would pull up their chair next to another, with
their keyboard in hand and you'll take turns alternating driving the session.
On the other hand, when transition to remote, generally video conferencing
tools are used for their remote access, screen sharing, and the video.
The Arc engineering team has tried that we tried Zoom, Google Meet, Around.
We've tried them all.
However, there's one major pitfall.
Think about this.
Every developer you have your own shortcuts.
You have keyboard shortcuts, customized shortcuts.
All these speed up your own development process.
However, this is something that most video conferencing tools aren't able to capture.
Video conferencing tools were not built for the sole purpose of pair programming.
So while using it, it works, but it may actually hinder the whole
development experience when using it.
This is why finding the right tools for a task is important in bettering the
remote development experience, especially when you're collaborating together.
My personal favorite is Tuple.
It was built by developers for developers.
It's a tool dedicated for pair programming.
All inclusive.
You have your keyboard shortcuts.
They've built it specifically so that there isn't that annoying lag that we
sometimes get when we're also doing screen sharing and remote control.
Or an alternate is there's a lot of extensions on code editors.
For instance, we have Teletype for Atom and Live Share for VS code.
Tip number four, don't forget your coffee chats.
When working remotely, informal communications are often overlooked.
These are the conversations about anything other than work.
And this is essential towards increasing trust, boosting team
morale, and in turn productivity.
Think about this.
When you're co-located, there's more opportunity for these conversations
to happen naturally, whether you're passing each other in the hallways
or you're walking out for lunch together, or just making your
morning pot of coffee by the kitchen.
These are the small moments that foster the relationships at work, whether it's
celebrating your teammates' kids first soccer wins or sharing that new pumpkin
pie recipe you'd recently just learned.
However, when switching to a remote, these informal conversations often disappear.
If we are not intentional about planning for them.
Coffee chats are a way to devote time to fostering friendship over
non-work topics with your teammates.
To sum up this video, we've covered the four tips to help you
succeed as a remote developer.
Tip number one, set a routine because it's hard to be productive
when you're not feeling your best.
Tip number two, documentation will be your team's best friend to close the
knowledge gap within remote teams.
Tip number three, find the right tools to support remote collaboration to improve
your remote development experience.
And finally tip number four, don't forget coffee chats with your teammates
to create trust and boost team morale.
That's all for today guys.
Let me know in the comments below what are some of your top tips for
succeeding as a remote developer.
Thank you so much for watching.
If you liked the content, don't forget to give us a thumbs up, subscribe and smash
that bell to get notified of new content.
Catch you next time.
Bye.