I have been working as a remote developer fulltime, for the last five years. Part-time/freelancing for at least ten years, over this time, I have collected several tips and tricks on how to become better at it and how to succeed and deliver results under this environment. I am writing this post to share some of these tricks, while this is a brief list. I am always testing these things. I thought it would be useful to do this one and periodically create a new one to share some updates.

If you are a TLDR reader, I am sharing here the list of the subtitles:

• Secrets
  • Be Positive and Open-minded
  • Create a clean setup and neat workspace
  • Create a “before commit” secret message
  • Create a Pull request checklist
  • Address daily meetings like a diary
  • Tools you should use
    • 1. Grammarly
    • 2. Time tracker
    • 3. Skitch
    • 4. OBS (screen recording)
  • Take Notes, notes, and more notes
  • Work in the morning
  • Create a routine
    • 1. Wake up early
    • 2. Prepare coffee
    • 3. Workout 3 times a week
    • 4. Read
    • 5. Write
    • 6. Sleep regularly
  • Use Vim and Tmux (or at least master your Env and editor)
  • Create a Dotproject
  • Read these books
    • 1. The Culture map
    • 2. The Pragmatic Programmer
    • 3. Getting Thins done
• Conclusion
• Reviewers

Now, if you find something interesting, stay with me and let’s learn something.

Secrets

From the easiest to the hardest.

Be Positive and Open-minded

This may be cliche, and not everyone is a positive person (and does not need to be). Still, is cool to have a positive attitude upfront a challenge or request; I am not saying you should be a yes man, I am saying that when you get a request, try to think about it as if is a challenge rather than a boring request, or someone wanting to steal some of your time.

Be energetic and show what happens when you overcome some hard challenges, push the time to be more positive (for example). Being positive and expressing the success will increase yours and your team morale, and high team morale increases the chance of success.

Create a clean setup and neat workspace

My workspace has a significant impact on my state of mind and even my productivity; back when I started working remotely, my office was a mess. I had a lot of objects on my table, and lots of them I had never used or even touched. That all ended-up on a day that I got a massive allergy that lasted for over two weeks. I noticed that was because of the dust in my office. It was out of control, and it would have been easier to clean it up weren’t for all the objects I had on my table.

At that time, I also noticed I would work anywhere but in the office. After that day, I cleaned my office and removed everything from my table. In one week, I noticed a productivity-boosting and a much better sense of peace while working in my office. Then I started reading about all of that “clean-setup” movement, which immediately made sense. So I started the journey on how I could de more productive without working more hours, and I decided to go all-in. I stopped buying electronics that I rarely used and instead, I used the money to make my office simpler, cleaner, and more set to productivity. I bought two ergonomic chairs, started using a single and bigger monitor instead of two. I got a mechanical arm that suspends it and therefore I do not occupy my table with supports. I switched my wired mouse and keyboard for wireless, added a plant, and even a fancy lamp to my office table.

Here is how it looks now.

Since these changes, I’ve noticed an even more significant increase in my productivity and well-being while working. I am still working out of the office sometimes, like from the garden of my house, from coffee shops or libraries, but now I feel there is no more productive place than my office in the quiet hours of the day. And I have tested myself to see how to return to the old mess environment. I placed a single page of paper on my table next to my keyboard, and at the end of that day, I felt exhausted. That day didn’t feel productive at all. It amazes me how much impact can a little mess do to my well-being nowadays, and how could I possibly work on such a chaotic environment in a close past.

Create a “before commit” secret message

Before doing any commit, my secret is that I will have my editor asking me, Is it easy to change?. This advice comes from several coding or software design books. The most important factory of a useful feature, project, software, method, and commit is that it needs to be changed easily. The idea for that message came from the book Pragmatic programmer (This is an outstanding book I recommend for any programmer at any level). As soon as I read it, I knew it would be a good idea to ask my self that question from time to time, once every commit seems to be the best I have for the moment.

Create a Pull request checklist

In my daily notes, I have one checklist for each PR I will open for any project. This will help me making sure that PR will be good and will pass easily on review. I am also giving a grammar checking on Grammarly (I will talk about it in detail later in the Grammarly chapter). Check the variable names I have added in (You know how hard naming is), check the docs of the methods (So I make sure I’ve documented any critical information), check API docs (Changes in public APIs are usually rare, but when they happen you better remember to also update their docs). Smoke testing (of course, running the tests locally and seeing how they go). And finally, improve something I see that is bad (I try as much as I can not to rush on PR opening and to have this last step to improve something work for me like and “It won’t be possible to rush at this point”. The thing is, I usually find other small problem on the code in this step and consider it to be one of the most important)

# PR self review check list
- [ ] Pass grammarly in the PR body
- [ ] Pass grammarly in the test spec
- [ ] Revisit variables and methods names
- [ ] Check every public method doc
- [ ] Check API docs
- [ ] Smoke test everyting
- [ ] Improvement

Address daily meetings like a diary

Some people think that daily meetings are boring, but I think they can and should be fun and productive. I write my daily meeting notes every day as if I were keeping a diary, telling a short story about yesterday and this morning, as well as what I plan to do today and whether the plan for the week needs to change. I usually start working 4 hours before the next member of my team wakes up (I work from Brazil with a team located in the USA), so I write the notes of the daily meetings between 2 and 3 hours after starting work, which helps me to clarify how my day was yesterday, what should I keep doing, what should I avoid and what is blocking.

Also, the notes will give you a direct message to say at daily meetings, and I avoid starting the meeting by saying, “Let me remember what I did yesterday !!!” you will look professional, having the updates you need to provide at your fingertips. It also gives you a sense of how things are going over the days; you can look back at your daily notes and see if you’re making progress or not.

The time tracker is your ally when taking notes; this will help you not to forget any details, even if you take notes 3 days later, on a Monday. After a while, it will be natural, and you will not need to remember to do them, to start this habit, I recommend adding a task in your agenda 1 hour before the daily meeting to make notes this way once in the daily meeting begins you will be ready.

Tools you should use

1. Grammarly

Grammarly, for me, is one of the most essential tools for my day-to-day, whether as my text editor or email corrector. Writing for me is a superpower for remote workers and we have to make sure our text is reasonable; you do not need to proofread every single document you produce but it helps you not having any typos or structural problems. I do overuse Grammarly, and it has paid dividends for the last three years. Since I started my master’s degree, I had it verifying every single article and master thesis. Since then, I use to say it is the best investment I do every year.

2. Time tracker

Time tracking is a superpower that will enable you to see where you are putting your time on, even if your employer does not require it, I would recommend you to have one for many reasons.

• You will where you are spending most of your time in.
• You can avoid overworking by knowing how many hours you worked on that day and not trusting your sense of “have I worked too much or too few?”

Today I use Harvest but in the past, while working as independet contractor I have used Toggl, and I track my activities in real time, without caring about all about details (Like I will not stop the clock if I go out to grap coffee or to read email), but I would recommend using any if them that you like using.

3. Skitch

One picture worths a thousand words, but it needs to be good, because sometimes you need to explain complex subjects to people that will not have the same context you have about the topic you are talking about. In that matter, Skitch is a great tool to take prints and show critical points and do short explanations. Check out the next image, where I was explaining a chart just as an example.

4. OBS (screen recording)

As well as writing, showing information as video can be a superpower. Some subjects are much easier to demonstrate as a video than as a text. For example, simulating a bug or showing a problem needs to touch several services and multiple monitoring charts and sources. Recording a good video showing how you find the bug, how you made sure it was fixed, or even explaining the process you have implemented can save you several paragraphs of text, and save you from having a PR rejected. Any complex new feature or bug fix, I would advise you to come with an excellent text in the PR, great code comments, great self-review showing the critical areas, and a good video explaining the fix and showing how it was tested, debugged, and so on.

Why OBS? OBS is “Free and open-source software for video recording and live streaming”. It is a full-featured free, video recording tool. Quicktime is a prior tool I used to record my videos as fast as it is possible. Still, the videos seem much more “homemade” with OBS, and you can use multiple sources of cameras, screens, and media. Videos are usually boring, but people are much more willing to watch your video if it appears more attractive.

I like to use my cellphone as an external camera from the side, and if the video is too long, I add background music, so it does not get boring during the tests or build running time. I do not do any fancy edit in my videos, but the simple fact that I take the time to record them in a better-looking way makes my PRs much more welcome to be accepted.

It takes some time to master the video recording art, so I advise you to do it multiple times until you feel they are looking good. I started streaming when coding some personal projects to make my video recording better. It turned out to be a little bit of fun as well (checkout in Twitch), next I printed one my videos just showing how it looks.

Take Notes, notes, and more notes

Taking notes is one of the superpowers that not everyone has realized yet. I started taking notes seriously when I saw one YouTube video of one doctor that had being using Vim to take notes. That got my attention. I have been trying to keep a system where I can take notes of what I do daily and keep it. I have tried lots of different apps but never found any good about them. Using Vim made it fun and productive, so that’s what I do.

Taking notes have two support powers: reduces the stress of having to remember stuff, and exercises your mind thinking about the subject and how to put it in words. My note-taking system is simple, and that is what makes me follow it easily. For each significant project, I will have a folder in my .git. folder, and inside that, I will have another folder called notes/, inside it, I will add any important note with any naming. By default, I will have a file called ‘Day.md’ where I take notes for the day-to-day activity, the checklists for PRs, and so on. At the time I was writing this post, the notes for the more significant project I was working had 1454 lines.

Why using notes as text?

1. You can version them with git (and I do it :) ).
2. Text is the most portable format you can ever find, you can read it in any device with a screen, and you can easily predict that any new device or operating system in the future will support the text.
3. You can use markdown (I do) to make it sexy and pretty if you want to do it.

Work in the morning

I am a morning person (In fact, I am writing this at 06:54 am on a Monday), and working in the morning has made me deliver much more than I could have ever imagined. I started waking up 5m for over a year now, and after that, by 10 am, I usually already got done more than I used to do on a full day of work in the past. Why?

1. No noise, at 5 am, you can work in the silence.
2. You do whatever you want. No one dares to ask you at 5 am why you did not do the dishes before starting working.
3. Clean mind.
4. No social media, no notifications, no email, no slack, no phone calls from telemarketing, no kid running into your office, no deliveries arriving, no neighbors help. At 5 am, the world is quiet, and everyone is taking care of their own business.

Create a routine

I have a subset of routines. I do not have any evidence that they are the bests or that they are the only ones that you should follow. Even I, usually try out different routines on a weekly basis. For me, the most important for you is to have your own set of routines, to help you drive your day, or even more critical, to help you navigate your week. I will present to you an overview of my routines and how they help me in my day-to-day, and to deliver more results.

1. Wake up early

This is the first habit that has made a big difference in my life. I have started this routine during my masters while working remotely full time in a company (Tenfold). I needed to study quite challenging subjects to complete my credits and latter to write my thesis. I found a solution by starting my day at 5 am and dedicate until 10 am to my master’s. When I start doing that, I felt a significant difference in my master’s results. I noticed that I was getting much better results and more productive at my master’s activities than in my full-time job.

After my thesis defense, I kept working early, and I do the most important thing to my day I do in the morning. Today I like coding 4 hours of my day in the early morning, and generally, with that 4 hours, I deliver more than I used to compared to working the entire day before this habit, and the quality of the code and work I produce is much better.

I credit that not only to work in the morning, but also to some other tricks I have learned in this journey, but this is a big part of it. I never read emails before 10 am because I do not want anyone to change my day’s priority. If something needs my attention, it can wait for the second part of my day to unblock, pair, and work on the “other people” problems.

2. Prepare coffee

After getting out of the bed my first task for the day it to make coffee (if I am sleeping alone, the first one will be to make the bed, but this is rare nowadays once I’m married and most of the days my wife wakes up after me, every day I prepare banana pancakes and a v60 bottle of coffee.

Once I complete this duty, I start my day with success. I will eat healthier, have concluded a vital task, and now I can go to my day with energy and motivation. If no other mission is successful in my day, I will complete the day with one success in the checklist.

3. Workout 3 times a week

Usually, I work for 2 hours before going to the gym. I like to use the first boost of motivation to code the hardest thing I need to code for the day. After 2 hours, I want to go to the gym, so I will be sweaty for a while before going back to the code. I workout heavy and focused. I like going to the gym is because of 2 reasons.

1. Keep my body healthy and attractive.
2. To do an activity in my day where I turned off the mind.

Most of my other activities require my full attention and fast thinking. I spent 1 hour at the gym, almost meditating, focusing on the music and the exercise. Once I am back to work, the focus is usually much more prominent than before.

4. Read

You cannot learn everything in a video format. Today there are video tutorials for every single subject you want to know. I would argue that video is an excellent way to learn some stuff (like recipes), but not any subjects, complicated subjects, big concepts are most likely to be better learners in a reading format. Anyone that has already seen a movie about some book they have read will admit that, in the book, the author can go in much more detail about the environment, what the people were thinking and feeling. In the movie, even with all the images and with a face to the name you are already used to, it is noticeable how much detail is lost.

Moreover, a video with more than 1 hour of duration may be too much, and regular books will take you lots of reading hours. My point is, you should give up trying to find a vide to learn every single new thing you want to know. Do not expect that all knowledge in the world would be that digested for you in 10 minutes videos. Start reading more today!

I read on a daily basis, from blog posts (grab from Hacker News) to books (there will be a section here about some books) and academic papers. My intention here is not to drive you to read the same sources I do but to convince you that reading is a superpower.

From reading :

• I learn new things (what are people doing or giving up doing) (started to learn rust, Elm, and others from reading around).
• I learn what people have done that has worked, and even more important, what has not worked Why I’m leaving Elm, [PS]: I still like Elm as a language, but this blog post is quite good.
• I’ve learned the way to failure (You learn much more from other failures than from their success histories), RethinkDB: why we failed

For me, reading is a matter of learning, taking the time to think, analyze, and understand other people’s points, from your point of view.

5. Write

Remote working is a communication challenge. You gain lots in productivity once you can quickly turn off all distractions and focus on the important work at any time, and no one will poke you to tell theirs dogs have learned a new trick this weekend. But on the other hand, it is hard to make informed decisions, communicate informations and even knowledge can be floating around in the organization, because we work asynchornously. So how do we overcome this limitation? We write!

Yes, I strongly recommend sharing knowledge and decisions, writing them down, and making it available to the people that care about it, for example.

If you are opening a pull request to be reviewed by your pairs, comment on code the trade-offs you are making, and why you are making it. Point the critical points in code in the PR body bringing the person’s attention to the topics that matter.

Write down your daily meeting notes: Every day, take 10 to 30 minutes to write down what you did yesterday, what you are planning to do today, what blockers do you have, and if you need to do some re-estimation/re-planing. You may think, “I will lose other 30 mins of my day writing what I have already done!!!” but you will be saving you lots of time.

1 - Nevermore “Let me see what I did yesterday on daily meetings!!!” 2 - In the start of each day, you review your goal for the day in your notes, and that help you to drive your day and decisions (what meetings to cancel, what meetings to accept) 3 - You create a database of how your days are going. You will see clearly if you have been productive of only spending time on endless tasks.

Create an excellent readme for your private projects. Readme files are essential for any open source projects. Readme files have hundreds of commits, and people spend lots of hours trying to make them better and welcome, yet in closed projects, I have never seen they been taken into account like that. I like to use readme files to point to other sources of information (like onboarding, for example), and even to document macro decisions in the projects. Let us spend just as much time on out closed source projects in the readme as we do in our open source projects.

6. Sleep regularly

Sleeping is quite essential to you. Some years ago, I would sacrifice sleeping in favor of studying or working extra hours in personal or different projects. Even though I think that was absolutely necessary at that time, now that I have crossed a line of my personal goals, I will rather postpone a delivery a week in favor of a good sleep routine. As a result of that, I noticed that the quality of the work I produce had grown a lot after I started prioritizing sleeping. The number of bugs produced by my code has reduced, and the time to find/debug hard production bugs has reduced in orders of magnitude. In the end, working less has made me produce more. Now I rarely work more than 8 hours a day, or 40 hours a week on my day-to-day job, and I usually work from 2 to 4 hours a week in my personal projects (Like nun-DB) plus some extra hours on the weekends (before my wife gets out of bed, or when she is working once she is a cop that works every other weekend.)

Use Vim and Tmux (or at least master your Env and editor)

Vim is a great text editor I would advise any young developer to learn and master. I know it will not be every one that will like Vim as much as I do, or perhaps you may rather use Emacs. This part could be good for either of them or even VS code. Try to map these tips below on your own text editor, and you will be fine (I don’t think you can do these things as fast as in Vim because you will probably need to use the mouse. But if you do, let me know and I will update this post later with your tips :)).

The first tip is, set Vim to a better workflow, and make the right things easy to do, and repeat. For example, you want to test your code frequently, so you know you are making progress without breaking old things or introducing regression, or even better, when producing new code or features, you want to start doing the test and then start coding until you test passes and then improve your code and keep the test passing. This tip I call running the test frequently, and in my Vim, I have the “Run the closest test” and “Run the last test” on keystrokes away to be executed. Let me show you one quick example.

• Running the tests frequently

In this small demo

1. I run all tests in the file: <space>y
2. Find the broken test: /validate.
3. Run it individually: <space>t
4. Fix the wrong string causing the test to break: ci"invalid
5. Re-run the single test: <space>t this time it passes
6. Then I run all the tests again, and this time all of them pass: <space>y all that in less than 30 seconds (and of course, without touching the mouse).

Moving back to the file you were, like when you are doing TDD, and you need to go to the test and go back to your code and vice and versa. For that, I use these quick keystrokes that are <space><space> (pressing space twice) and I can go back and forth on those files, check out the demo:

These are some of the most significant improvements Vim brought to my workflow. Still, there are tons of smaller ones that at the end of the day, delivers an even more significant result, like logging a variable with <space>c, replacing with %s and much more, copying, moving, deleting text.

All together with Vim, comes to Tmux. I would advocate for any developer that does not use Vim to use Tmux at any time. Tmux is a great tool where you can have multiple terminal tabs and sessions. You can navigate, create, and do everything without using your mouse (:)). One of the most significant time wasting is to switch the context from one project to the other or from one workflow to another.

For example, in my case, I usually have three different contexts: one for my work at Radical, one for my personal projects at VilaRika, and one for writing these blog posts.

Create a Dotproject

A big part of being productive is not be unproductive. From time to time, you may have to switch machines or buy a new one. Not having to waist days configuring your new device will make you much more productive in the end. For that, having a dotProject on GitHub will help you to get up to speed once you pick a new machine. During the last five years that I worked remotely, I’ve switched machines three times, and today I have 2 Macbook Pro. I rarely use the old one, but it is good to know that if I need to use it, I am one git pull ./install.sh away from been productive again. Even if you do not use Vim or Tmux, I am sure you can make fair usage of the dot projects on GitHub. Here is mine so you can take a look at how one looks like: My OS X environment.

Read these books

Here I will share the books that have helped me to become better on working remotely until here. Over the last five years, I have read lots of books, blogs, tips, and even watched YouTube videos, some of them from developers, others from other kinds of workers that have mastered remote working. Here I will focus on these books, but I will suggest other sources at the end.

1. The Culture map

Once you start working remotely, it is almost inevitable you will have to deal with multi-nationality teams and projects. Just last year, I was part of a team where we had, 4 Devs from Brazil, a PO and Scrum master from the USA, the Director of the project from Japan, QE Director from Nepal, QE team from India, all that for a customer in Israel. I was the technical lead for this project, and as a result of that, I would have to deal with all of them, and all of them were a source of information to me and the team I was managing. Each of these cultures has differences, mainly in how they give and receive feedback. How do you identify the nuances in the feedbacks coming from each of these teams? How do you know they are happy with the result of the last delivery or if they get it or not? The key is the book ‘The Culture Map: Breaking Through the Invisible Boundaries of Global Business’.

The book is a masterpiece about global business. It has nothing to do with coding nor systems designing, but was one of the most valuable source of information for me in that project (that I just mentioned) and in many others. The book analyses many cultures (including most of the above mentioned) and shows you how they react to many different inputs and situations. I will not quote the text here, because I really want you to go there and read it, but here is a piece of advice from the book that you may wanna get out of this post with; Each culture has its own way of giving negative feedback, some of them are more direct (like Israelis, they will tell you what is wrong direct in your face without any preparation to it) some of them are less direct (like Brazilians, before a negative feedback a Brazilian will tell you everything they like, and then connect it with a “but, you could do xxxx better”), so a possible conversation between this 2 cultures on a demo of a relatively complex user interface could be Israelis: “The label for the button xxx doesn’t make any sense! Fix it.” what he means “It all looks cool. But the label for the button xxx could be better.” What Brazilian understand, “Is it all bad, and the label xxx is garbage!”

That is quite a simple example I created from the book, but that maps well with the day-to-day base interactions. Another great advice and an important one is “Do not try to emulate other culture” the book should serve you as a source to understand how to deal with different cultures. You will know what they meant with what they have said, but you should still act like you are used too. If you try to emulate other cultures, you will be in a significant threat of getting the nuances wrong and sound too aggressive or too passive. “Just be yourself” and use what you have learned from the book to deal better with them.

2. The Pragmatic Programmer

This is not a book about remote working (as you may already notice most of the books here are not), but this book has so many useful tips and directions to master the programming art when working remotely. The “butt in the chair” effect is gone, which means your managers won’t be able to control if you are working or not. The only metric that will matter is the work you deliver that is a significant change. It means that if you are super productive, you can dedicate a much smaller amount of time to the day-to-day activity and still deliver more than all people around you are expecting. Therefore, you may save the extra time to do work that delivers additional value, or dedicate to personal activities, or even study to become more productive.

There is where this book comes from. The pragmatic programmer is the book that I had read in my first years. It comes from the experience of programmers. This is not a book from mangers or “Architecture” that think they know how is it to be a programmer and try to convince you if you have or not the correct designs, the code will magically fit and therefore project will succeed and don’t get me wrong there are great tips on the book about software design. Still, they are much more close to the day-to-day activity and seem much more with a straight forward way to implement that you can take these tips and directions as time goes by and go implementing on your day-to-day work. Like I did with the “is it easy to change?”

3. Getting Thins done

Not only for people that work remotely but for any professional in the marketing or freelancing, this book is an excellent source of information. Again I will not quote the text because I am hoping you to go there and read it, but I will share a couple of tips that have helped me become better at remote working. For me, the most crucial small tip from the book is the 2 minutes rule. If one thing takes less than 2 minutes, do it right away to remove lots of stuff from your todo lists and give you much more mental clarity. You will only postpone the tasks that take time to do. This tip works even for your house cleaning and how to keep in your office clean.

That is just 2 cents from the book, but it is full of great tips that will help you have a much better day-to-day work and life, with less stress and less stuff to remember.

Conclusion

My goal with this article was to show some of the tricks and tips I use to improve as a remote developer. Most of the tips are generic and can be applied even if you work on the office on day-to-day basis, even if you can poke your college in the arm and bring him to your table to review your PR worth spending time writing a good PR so other can read it and get the context in the future for example.

On the other hand, it is harder to have secret todo lists (like the PR one) because others will see it and maybe ask you about it, or even create a tool to yourself to automate a process that may be harder in an “in-office” environment.

As you probably noticed, this post is about creating working habits. You may come up with your own list of habits that help you succeed in your job or company. The important thing is, try new things, try them for a while, change when you think they are making more problems than helping, review them from time to time. When trying new habits, commit to them for at least 60 days before calling it adequate or inadequate. Your work life is a marathon, not a sprint, go as fast as you can handle for an extended period, collect and share success, document failures, and learn from them.

Reviewers

@sergiogomes @andrebot