_A poor developer always blames their tools._ Well, let’s talk about the best tools for remote work so you can’t blame them! This blog post outlines 5 tools that come in handy when you don’t work in the same physical space as your co-workers.
There are three types of remote work—in an office with colleagues in another office, you in your own home office, or as an on the go _digital nomad_ working from wherever you find WiFi. No matter your ilk, the information below should help you stay communicative, responsive and on top of your craft as a remote Android developer.
##The tools
Remember: the tool gives you the means to the end but it’s also important to understand why you are using the tool and what that end goal is. Take lessons to improve your remote capability from this blog post, not just a list of tools.
###ScreenHero
Not being able to just grab someone in the office to point and show them the problem on your screen is a real pain for remote workers. Similarly, explaining to someone how to fix something via a chat message is just not the same as fixing by example in person.
> Screen sharing for collaboration in teams; Code with others remotely; You each get your own mouse cursor, and you’re both always in control. Screenhero works with your favorite IDE and makes remote pair programming or debugging effortless.
[Screenhero](https://screenhero.com/) really makes you feel like you’re sitting next to the other person. You have an open voice channel and you can both see the same desktop. It’s like having two keyboards and mice as you can both type and click at the same time (which sometimes does require a bit of etiquette to avoid battling over the cursor position).
Screenhero was bought out by [Slack](https://slack.com/), and although they have said integration is coming soon it is not there yet, right now Screenhero has stopped allowing new sign ups. _However_ if you know someone who has already signed up _e.g. us_, you can get an invite off them and it’ll work like normal. Ask anyone at Novoda we will happily share.
###A physical device
Working remote can mean you are not plugged into an external power source so every lithium % counts. Using a real test device, rather than an emulator, keeps your laptop going that little bit longer.
> Android Device of your choice, be together not the same
Plugging in a real device really does save you laptop battery consumption. If your computer is plugged in to the mains [Genymotion](https://www.genymotion.com/) works just as well, but coding on a plane, train or a beach you need all your juice for as long as possible.
Always have a dedicated development device with you. Make it a low end device as well – a Samsung Galaxy S3 mini is my current preferred device. Having a development device means you aren’t worried about using your personal phone battery and vice versa – you can still develop if you have been catching Pokémon on your phone all morning. Using a low end phone has two benefits:
1. it means if you make your app work and run well on this device it’ll run well on other more powerful devices
2. the battery will last longer if it doesn’t have to run a powerful CPU or power an amazing screen.
###Vysor
After you have shared your screen and are pairing with another Android developer, you need to ship your code to a device. Unfortunately the other person, being remote, won’t be able to see the device, tragedy.
>Vysor puts your Android on your desktop. Use apps, play games, control your Android.
An easy install Chrome app, compatible with all operating systems.
[Vysor](https://www.vysor.io/) allows you to share your device with the person you are pairing with by displaying it on your (shared) desktop. They can even control the device, swiping and clicking buttons.
Another reason for using Vysor can be the processing power of your machine. Using Vysor and a real device is not as CPU intensive as running up an emulator whilst also Screenhero’ing and compiling.
###Git
Not being guaranteed a stable internet connection is a fact for any digital nomad. Even if you just plan to code on a flight between offices or a commuter train, you need to plan for no internet connection.
> Most operations in Git only need local files and resources to operate – generally no information is needed from another computer on your network. If you’re used to a CVCS [centralised version control system] where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. Because you have the entire history of the project right there on your local disk.
[Git](https://git-scm.com/book/en/v2/Getting-Started-Git-Basics) is taken for granted in this day and age but being able to commit your code when you have no internet connection saves you from a world of pain when bug fixing or working on multiple code areas at once; you’re able to move between/revert changes at any point, all while offline.
Always remember to get all the code pulled that you are going to work on before you go offline. This online prep can also include ensuring Android Studio IDE is up to date and Gradle has run at least one `clean build` which makes sure you have all dependencies needed.
###Communication skills
Working remotely can be a lonely and isolated experience. Your closest human contact could be only through commit messages and you won’t bump into people in the corridor for that ad hoc chat that is sometimes needed to resolve issues. You need to know how to communicate. Your own brain is the tool for this problem and all it needs is a small upgrade.
> Great code check in
> Great code check in…
> Great code check in … 😀
The benefits of good communication is far reaching, and for you personally it will mean more enjoyment of work, better opportunities for more work, and a sense of a team and belonging.
You really do need to know how to communicate as a remote developer and the explanation of this one point could be a whole blog post. For now here I will keep to the short version:
– Make sure you correctly organise your calendar events, invite the correct people and add an [agenda](https://www.effectivemeetings.com/meetingplanning/agenda/agenda.asp) (ask for an agenda if there isn’t one) so everyone who is attending knows why to attend and what is going to happen. This also helps stop meetings going off track and helps to finish them on time.
– Keep git [commit messages](https://chris.beams.io/posts/git-commit/) perfectly formed to allow you to read them back when things go wrong, also for your colleagues who can’t ask you questions face to face.
– Keep your inbox under control (_perhaps try [inbox 0](https://www.43folders.com/izero)_) and ensure you always [reply to all emails](https://gettingthingsdone.com/). You need to keep up communication and ensure you are organised with giving people prompt feedback via email, you won’t bump into them in the corridor to just say _”yes I got your email great thanks”_.
– Always consider the correct use of [emojis](https://www.webpagefx.com/tools/emoji-cheat-sheet/) in conversation (the emotion is lost in textual discussion) and remember that, being remote, people may not know you personally therefore not know your personality too well. Always add more communicative emotional context.
###Conclusion
The world is becoming more connected and the need to be _physically_ face to face is lessening. The future lies in remote work. The important point to take from this blog post is remote work is not an isolated process, you need to train up and evolve your handling of your working relationships. There are many people facing the same problems out there and there are a wide range of tools to investigate and adopt and don’t forget to share your learnings with others (_online_), because hey, I won’t see you in the office for you to tell me. 🙂