How not to work in the USA

As I mentioned in my last post, for the past few months I have spent some time working remotely. I work for a company in the USA that has been extremely flexible about letting me work remotely, and I am grateful for that, but working internationally hasn’t come without challenges. Granted, my stays overseas have been relatively short, so I can put off the hard stuff until I am local, but there are still plenty of discussions and collaborations that I didn’t defer.

So, without further ado, here is my checklist of important steps to take before leaving to work in another country:

  • Choose your communication tools and make sure you know how to use them! I rely on E-mail, IM, and Skype.
    • E-mail and IM are obvious and easy, in both cases my company had those set up.
    • Making video and phone chats really painless has proved to be an effective method of staying well-connected to my peers. I don’t think working remotely would be nearly as effective without this.
      • For international calls, I chose Skype because they seem reliable and have decent pricing. I set up a “local” (US) phone number that forwards to my Skype for a low, fixed cost. Calls in are free, and I pay a low rate when I call out.
      • The service isn’t enough, in addition I use a wireless headset from ASUS so I was ready to take calls at all times.
  • Plan ahead for getting real work done on a remote machine and also plan for what is going to be hard/impossible over a VPN.
    • One of my best remote tools is a Virtual Machine that replicates my server-based development environment.
    • Rsync-based scripts help me keep my home directory and infrastructure directories synchronized
    • For most things, I can work and develop in my local environment. But sometimes, just committing code to the remote SVN repository is insufficient and I need to run interactive jobs on faraway machines. For that, VPN + NX seem to provide the fastest model for UI interaction (even from the terminal).
  • Align your hours when possible.
    • Depending on how many timezones you are hopping, this may or may not be feasible. But, if it is possible to plan your free time so it lines up with when coworkers are sleeping, it makes work so much easier.
    • Whatever hours you end up keeping, be consistent and straight-forward with colleagues so they know what to expect and can avoid the kinds of nasty surprises that happen when you checkin broken code and then go offline for 8-12 hours!

    While this list is certainly not exhaustive, it captures at least some of the things that have helped to make my remote development experience reasonable!

This entry was posted in Technical. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s