3 Must Have Practices for Distributed Developers

During the last several years working in the global corporate world I have come across a repeating challenge for distributed coders to efficiently work together as early as the beginning of their ramp up. I’ve seen situations such as the following many times: A projects begins, the teams and resources are pulled together, on-boarding as a group with a mutual critical mission, but the harmony of work between the coders is still difficult to create. There simply isn’t a good solid ‘working together atmosphere’ among the coders whom eventually need to deliver one product with the same look & feel.What is surprising even more is the fact that distributed developers working on a mutual mission is far from being unusual these days. This has been going on for a long time and across many companies. Something though, keeps putting the problem of distributed coding in one of the first places when ranking the main challenges software projects are facing. The human nature for interacting well only when we’re physically near one another seems to collide with the long experience we have already in the industry for working remotely or distributed.The ‘how to’ lists are long for this subject, but choosing to rank both the quickest wins, along with the highest positive impact those can provide, I have come to share three top tips to allow every coder in any software project or industry to apply quickly and see great results.

Often have I have seen cases when developers working across multi-sites amend each other’s code, erase each other’s code, or duplicate each other code. All that when they have a common mission and product to build.

1. Mutual code reviews

And I mean not only between developers, but also between sites. Speaking in general, when we want to empower coders and teams, we should also encourage the guideline of all coders can push code to the master branch while the pull request can be approved by any developer. No need to assign senior developers to be the ones reviewing the code, or define development leads to be the only ones approving check ins. This creates redundant bottlenecks, removes the sense of ownership from coders that we want so bad to generate, and in any case there is no need to create artificial hierarchies where there is no need for it. The preferred way would be to establish guidelines where every check-in of code will be reviewed and approved by at least one other developer on the project, and at least one of those members is located at a different site.This enhances trust between far away developers, it engages between them and strengthens personal bonding, and this creates a situation where all the different locations have developers who understand the big picture. Even if they do not become experts in each other’s code, they can at least be familiar with a wider code base, know the product on a wider angel and even be able to support during their different time zones allowing flexibility in support coverage.

2. Handover e-mails

There is a clear need to handshake efficiently between the different sites developing for a certain product, and project. When one group of developers finish their work day and another step into the offices and begin their day of coding we’ll want to create continuity. One very easy way to apply that is with a ‘hand over e-mail’. Each team can summarize at the end of their day what version they were working on, what they have accomplished, which critical or P1 bugs are still outstanding, and what they expect the other teams and colleagues to take forward, and this way can leverage the different time zones. This will allow to leverage the experience of other coders to comment and suggest improvements to each other, without actually being co-located.

Status and assignments can be shared via handover emails, an agreed upon template, or a different solution. As long as you find a way to handshake between the distributed developers and leverage the different time zones.

3. Coders CoPs

Communities of practice have proved themselves in many occasions that I have been involved with. This should be a virtual, global based community of developers who share a common interest or product function. Maybe even the same component. If there are developers distributed across many locations working on the same product component they can, and should create a community. Once again, this will first and foremost enhance personal engagement between the coders who don’t meet or talk regularly during their day to day. But it adds further to that, they meet within their CoP framework about once a week to share information and knowledge, they run their own slack channel, and they help and share with each other feeling proud of what they build belonging to a global team with a critical mission, and part of a community.