Nowadays, due to the COVID pandemic, home office and remote work have become more common than ever before in various industries worldwide. It has become a normal way of work for many companies and work environments where, in normal circumstances, no one would think such a thing would be required or even possible.<\/p>\n\n\n\n
However, regarding the software development industry, remote work is not such a new phenomenon, especially in cases of nearshoring engagements. The fact that work is performed on computers makes remote work much more doable and natural, unlike in many other industries, such as manufacturing, repairs, sales, etc. Accessibility of high-speed internet connections and the advancement of video conference and collaboration tools bypass the distance barrier and provide an almost on-site experience of meetings and calls. Nevertheless, remote work, and especially its team-related aspects still have some drawbacks and pitfalls which should be taken into account and handled properly.<\/p>\n\n\n\n
Probably the main prerequisite for remote work to function properly is having at least some on-site experience. Without that experience, it would be difficult to get the idea of the whole picture: the software architecture, team members\u2019 responsibilities, details about internal procedures, the customers\u2019 perception of the SW and UI, not to mention the domain knowledge\u2026 The list goes on. In our company, we use the term onboarding<\/em> for the process of a remote developer getting familiar with the listed points. This process could probably be performed remote as well, but in a significantly more difficult and significantly less efficient way.<\/p>\n\n\n\n Once the remote work is up and running, there are some points that should be considered to keep it that way. Here\u2019s a short overview of some of these points.<\/p>\n\n\n\n Before the onboarding process can even start, it is necessary that the new developer and the existing team can understand each other. The best-case scenario is when the developer comes from same country, because this usually means that there is no difference in language. In most cases, the new developer speaks a different native language from the existing team. Of course, English is the lingua franca<\/em> of IT, and IT workers worldwide most often have a pretty good working knowledge of English. Nevertheless, it can\u2019t do any harm if the remote developer has at least some little knowledge of the language of the existing team (if it\u2019s not English). Sooner or later, the developer could stumble upon some code comments in the team\u2019s native language, which could be useful for executing their own assignments. It is not always practical to use tools such as Google Translate, especially in case of longer texts. It is also not always reliable.<\/p>\n\n\n\n In case of our remote engagement, we have regular synchronization video calls involving remote developers and the base team. Screen sharing during calls is practised. From the remote developer\u2019s point of view, it is important to be prepared for the call. It is advisable to finish the current coding stage some time before the call starts. Otherwise, it can happen that the software does not work properly or can\u2019t compile due to recent code changes. Therefore, it is better to finish a bit earlier and present the current work state in more detail, rather than perform last minute changes. It is also advisable to close any unnecessary windows and background apps in order to minimize distraction, as well as performance impact. Running a software development environment, database tools, text or spreadsheet editors, web browsers, various background services all at the same time as a video conference call with screen sharing can push the hardware to its limits.<\/p>\n\n\n\n Sometimes there is a need for longer remote collaboration, such as, for example, when something needs to be configured in a very specific way or if there is an issue which requires a more detailed analysis involving multiple team members. In such cases, it is good to exchange at least some basic information using more conventional methods such as emails and instant text messaging. Also, if some files need to be shared, this should be done before starting the remote session. These preparations can help the remote session to be smooth, efficient and not too long-lasting.<\/p>\n\n\n\n Usually, there is a need to share very large files or folders, i.e., several GBs in size. It is advisable to split the data into several archived files of smaller size \u2013 for example 1 GB \u2013 before uploading them. This makes the network transfer smoother, more reliable and more durable. In case of a network problem, the data transfer can be resumed from the point of the last successful chunk transfer.<\/p>\n\n\n\n It occasionally happens that something goes wrong with your Internet connection, which can cause problem propagation to your VPN, virtual machines, and maybe external devices which are relevant for your work environment. In the case of home office work, it is most often up to the remote developer to handle this issue. The solution is usually simple and common \u2013 a good old reset. Close all your foreground and background applications, close the VPN software, and then reset your network router. In most cases, things should go back to normal.<\/p>\n\n\n\n There are some aspects of on-site work which remote work can\u2019t match, such as spontaneous meetings right away, collaboration and brainstorming. On the other hand, remote work can provide some other benefits, like flexible work time, more free time because you don\u2019t have to travel to office, you can work from the park or other locations you prefer, etc.<\/p>\n\n\n\n With proper preparation and organization, remote work can be as efficient as on-site work, while maintaining all its benefits.<\/p>\n\n\n\n <\/p>\n\n\nLingua Franca<\/strong><\/h2>\n\n\n\n
In-Sync Video Calls<\/strong><\/h2>\n\n\n\n
Longer Remote Collaboration<\/strong><\/h2>\n\n\n\n
Sharing Large Files<\/strong><\/h2>\n\n\n\n
Handling Technical Issues<\/strong><\/h2>\n\n\n\n
Conclusion<\/strong><\/h3>\n\n\n\n