There has been a lot of debate in the tech community about working remotely and the willingness of employers to allow this option to their employees. At the very beginning of my career as a programmer, I had the opportunity to work on a distributed team. While the team was distributed, I was still working from an office and for almost half of the duration of my work on the team I had team members sitting beside me in the same office. Because of this, my scenario may not be representative of the population of programmers who work remotely. However, there are a number of things I learned from the experience that I would like to share.
Our day would start with the three of us in Bangalore splitting in to a pair and a lone developer and working on code. The other developer would join around 9:00 AM GMT (~ 2:30 PM IST) and the lone developer would pair with him. Later, as the work day ended in India, the lead developer would continue to work till his day was over.
We would have a short (~5 minutes) Skype call at the beginning of the UK work day, where we would discuss our progress and any thing else that needed to be shared. We later moved this to the end of the India work day, because this ensured the developers in India could discuss pressing matters and blockers with the lead developer and come back with this context the following day. We always had a private I.R.C. channel running where we could jump in and discuss things.
While pairing remotely, we almost always used Emacs running in the no-window mode inside a GNU screen session. This was great as it was a fast and glitch-free experience. Coding in an IDE and sharing the desktop was too slow. This is where I picked up my Emacs skills. While pairing, we were constantly on a Skype call talking to each other. Being glued to the computer screen for hiurs while talking to somebody over Skype with an earphone plugged in to ears can be a tiring experience. Fortunately, we made sure to take sufficient breaks in between. We used ThoughtWorks’ Mingle as our project management tool and card wall and it proved to be really useful for us.
Good code design
Extensive unit tests
Headless JS tests
None of these were done because we were a distributed team, it was the way we used to work.
It was great to have more experienced developers to work alongside in the same room as you. I got to pair with them and ask questions if I was unable to grasp something. However during the latter half of my work as part of the team, it was just me and the senior developer from U.K. While he took great effort to mentor me, the time difference made it harder for me because for the first half of my work day, I was coding alone and did not have some body experienced to ask questions.
In conclusion, I would say that with the right people and the right tools, you can make remote work a good experience for your team. However, if there is someone that needs to be mentored, having the mentor co-located would be a great advantage.
If you have questions or comments about this blog post, you can get in touch with me on Twitter @sdqali.