Between the lines: communication between developers

Armand Bour

Back when I was studying Computer Science and Application Development, apart from having to take the obvious mandatory technical classes, it was also oddly mandatory to take communication classes. During these classes lecturers tried really hard to make us realise the importance of communication in general, but we never tackled the subject of communication applied to a development project. I only truly understood why it was so important when I started working on projects at GearedApp. I want to talk about the importance of developer communication, the correlating processes we go through at GearedApp, and what a developer can do to improve their communication processes.

The matter of documenting or tracking the human-side of our code is so difficult to teach, which is why this is not fully taught by universities. Being able to see it in practice is so much more informative. In my opinion, no matter how well you think you understand these communication classes, we eventually tend to forget the impact that the other things we do, besides coding, can have on the project. Good code is useless if you are the only one that knows about or understands it.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
Martin Fowler, Refactoring: Improving the Design of Existing Code, 1999

This quote really stuck with me because, in my experience, I noticed that a lot of developers believe that their performance depends on how many lines of code they can churn out in a given time. But what about teamwork? What about collaboration? What about maintenance? What is the point of engineering an absolutely amazing data system if you are the only one who can understand and use it? This is what makes me believe that the success of a project depends equally, if not more so, on the effective communication of the team as it does the actual coding proficiency of it’s developers.

It’s not really about oral communication, or communication on a chat; at least not only. When starting a project, as developers we have the responsibility not only to select the technical tools that we are going to use, but also to plan our approach to the project communication. Just as we use different libraries and frameworks to build our projects, we need to use multiple tools to share information in different ways and at multiple levels of granularity, and essentially build a communication system for the project.

For example, the following tools can be used:

GitHub – A platform where users can commit and share their code, collaborate and find open source code projects
JIRA – An issue and project tracking software
Zeplin – A tool to allow collaboration between designers and developers.

To give you an insight into how we might use these tools to aid communication, the standard process of development is that it starts with tickets (tasks) which are set on Jira. These tickets are all prioritised based on project sprints. We use these tickets as a guide when we start development and all details regarding a feature are added here. We will start writing the code, and as we do so this code will then be committed (saved) on Github (currently the most common platform). When code is committed, the developer’s job does not end here.

What should also happen is that developers should document their steps and explain what the commits were about. By following this process you provide other developers with enough context and explanation to understand the task and what happened, without being part of it. Both of these tools provide so much opportunity for team communication and as developers it is important to utilise these platforms effectively. This means that when a new developer looks at your code, for a moment they can step into your mind, see your thought process and understand why you took the steps you did when solving the problem.

Care should be taken to make sure the comments relating to this code are clear, and easy to read. Some developers have come up with innovative tools to convey communication, such as Gitmoji which can be used to quickly add emojis to code that give context at a glance. This is very visual and can make things even clearer. It’s important to find a system that works for you and your team. Be creative and even forge your own tools; but also make sure that whatever you adopt will stand the test of time. Who knows when an issue may happen in the future, and the quicker you can get to the route of the issue the better.

Despite the initial time it takes to add these explanations, this will pay dividends when it comes to maintenance. Documenting tasks significantly reduces the time required when it comes to bug fixing. For example, if I find a bug while working on a task that I can fix very quickly, even if it was resolved straight away, I will create a ticket on the issue-tracker to indicate that I found a bug, why it occurred and what was done to resolve it. Tracking these small bugs leaves a reference for yourself and other developers, so that you can quickly find the source of potential problems in the future. This is particularly pertinent in projects where you have a separate environment for development and another for the live, production version of the platform (which is good practice for all of your projects). In this instance, you could have a situation where the client finds and reports an issue that has already been resolved. By documenting each small bugs you fix in the dev version, you are able to quickly check Jira to see if the issue has already been resolved, and push an update to your client. Tracking bug fixes reduces the potential repetition of tickets issued to fix the bug. This not only helps keep a clear record of issues that could help in the future, but also allows us to release smaller updates quickly. This improves our internal workflow, and keeps the clients happy as we’re able to deliver results faster.

Leaving a clear history of your actions on a project is the key to efficient teamwork. Again it’s not about what you have done, since those tools manage that part for you, but more about why you have made those changes, because this is where confusion can emerge between developers.

Communication is absolutely crucial when it comes to development. It allows us to bridge the gap between code and humans. Us developers (the ones who can write and understand code) play such an important role in building those bridges, and it is our job to make sure that those who don’t read code understand what’s going on. These extra steps that we should take as developers to better communicate our actions to each other really goes a long way to achieve this. All it takes is spending a little time to write a few words about your thought process as you code. It may seem like unnecessary extra time initially, but I promise it will pay off.