Refactoring
to
maintainability

Communication

2022-02-10
Consultancy

The Setup

A big number of the people I know (including myself) started on the industry due the attractiveness of coding: getting in front of the computer and writing some instructions that makes the computer do something. But as you work in projects, interacting with people, you realize coding is not the most important thing you do.

The most important you do is communicate.

Build the right thing

We talk about the idea that we need to build the right thing, over building the thing right. Because no matter how well done is something, if that is not what the business/user needs, the value of what is built is 0. How do you know you are building the right thing? Because you talk with the business or users, gathering their requirements, talking with the project manager or project owner to understand what needs to be done

It goes beyond that. Once you have the requirements we talk with the rest of the team, because most of the time we don’t work alone, we work within a team. How we are going to write the code that fills the requirement is something that we do agree with the other devs and the architects. Making sure that the new code fits within the existing code, or that we are in accord that things need to be changed/refactor. That we know the possible consequences of what we are going to do.

And once that code is written we go back and show and talk to the business/users, to validate what we have done.

But what about the code once is written? Code is never written once and you are done. Code is written and then changed, and changed again, and again. Because the requirements change over time, or even our understanding of the requirements. And that means that there is communication happening through the code itself. Maybe with your future self, or with another colleague. Maybe you will be communicating with a person you will never encounter because they join the company after you leave. You are communicating with them through an asynchronous written medium.

Primary skill

Communication is the most important things you do as a developer. Communication should be one of your primary skills: doesn’t matter if that is verbal, or written through documentation, or through the code that you write, making clear the intention of the code written (there is always the caveat that some optimized code could be difficult to understand, but at that point comments come into place).

And I know is some difficult to do, especially if you are (like me) towards the introvert side. But improving your communication skills is a big (biggest?) factor on improving the work you do.

Tools

The tools used to communicate are, therefore, also important. Tooling that makes communication more difficult, get in the way of your communication. And the difficulty here could be because is more difficult to write or talk using the tool, or because the tool makes it more difficult for you to know that some one is communicating with you. Easy searches are helpful in looking for past communication. And tool are needed doesn’t matter if you are in the same room or different rooms.

Different types of communication also require different tools or actions. Something that needs to be fix as quickly as possible, benefits from face to face or video call synchronous communication. But that has a detrimental effect if the urgency is not as big, at which point maybe ephemeral asynchronous communication becomes the better choice. And there is communication that needs to be revisited in the future, so a more permanent option needs to be used.

For synchronous communication a whiteboard (or any equivalent software) is a must. For asynchronous communication your email system, chat system and documentation system are very important. To put an example, I have not printed anything related to development in years, therefore tools like Microsoft Word or LibreOffice Writer are tools that I consider now as pretty bad (context matters, in other scenarios are/could be good) as they get in the way of quick writing and collaboration.

Past experience

My first job in the UK, as programmer, was in a print company. We had printers below the floor me and my team were sitting. And this learn from my colleagues on that team: if something was wrong with the job (wrong colour, wrong orientation) the best thing I could do is to get downstairs and talk with the print operators and see what was going on. A few years later, while creating a system for the factory floor, as soon as there was a report of something not working, or the users having issues, I used to go down and talk to them and see with my own eyes the issues they were having. In both cases, communication was easier than through a written medium. Further than that, it help on creating a flow and understanding with the users. It creates trust in you, as you were showing you cared. My experience has taught me to go often into face to face (though following the rules of two paragraphs up).

With the pandemic I have discovered that face to face communication has no difference for me if presential or online. But I will leave that for another post.

The End

With all that I have mentioned above, let me repeat:

Communication is the most important activity you can do.


Return to Index

Unless otherwise stated, all posts are my own and not associated with any other particular person or company.

For all code - MIT license
All other text - Creative Commons Attribution-ShareAlike 4.0 International License
Creative Commons BY-SA license image