Communication is one of the first forms of transmission of information between living beings. In its various forms: oral and written, it has contributed to the cultural growth of people.
In this article, I would like to share the lessons I have learned working in different software development groups.
Share your knowledge
The first rule is to share what you learn or know about a given topic. Many times I did not share what I had learned because I thought that others already knew. Nothing could be more wrong.
Sharing what you learn allows you to create growth opportunities for everyone. In other words, reporting what I had learned served me also to validate what I had understood.
Keep your team in sync
I have worked with developers located in different cities. I appreciated some Agile methodologies that promote, among other things, the exchange of information. It is important to keep everyone informed about who is doing what. This should not be seen in a negative way. Knowing that has allowed me to better organize my work. For instance, I will know who to contact for comparison or ask for an opinion. Another advantage was to avoid duplicate work or proceed in a disorganized way.
For this purpose, I have found very useful the use of some activity management tools: Kanban, Scrum boards…
“Adopt a developer” game
Many times I have worked in teams composed of figures that cover very different roles. Communication can be difficult or even interrupted, creating difficulties until the failure of a project.
This can happen because every professional figure has his own technical language / vocabulary that he uses every day. Moreover each of these figures must face and solve specific problems of his activity.
One experiment I did was to spend a day with a member of the UI Design team. We both exchanged information on how we worked and what was the most important information to have. We exchanged information on the work tools at our disposal illustrating the limits and strengths of each one.
Thanks to this we were able to find a better communication model to work more efficiently and effectively.
Learn to ask for help, do the right questions
None of us knows everything about every subject. When You are stuck on solving a problem, after some time you should ask for help. You would risk spending whole days without arriving at a solution delaying the deadline of a project.
Therefore, the most productive and wise thing to do is ask for help. Ask to a colleague or the whole team as soon as possible, perhaps at the daily stand-up meeting.
But how do you ask for help? Be careful, because otherwise, the help we receive may prove to be ineffective or completely useless.
I learned that you must describe the problem from the starting point (which was the specification to be implemented). Don’t describe only the point where you are stuck (ex: the button that does not update a form).
It is necessary to describe the context. Therefore illustrating the solution we have chosen that has led us to the insurmountable problem.
This is fundamental because maybe the chosen path is completely wrong. So even if we solve the single blocking problem, we would not arrive at the end of the project.
Listen to help requests
The downside of asking questions is to be available to respond to requests for help from others. When a colleague is in trouble and asks for help, he could be told:
“Give me another 5 minutes and I’m from you …”
and you probably know what will happen. The colleague will wait hours before receiving help. Over time I have understood that this risks making us unreliable. In addition, a person who cannot keep up with his job stuck. The result is, therefore, double damage for the team.
Being available to others (obviously in a healthy way, without anyone taking advantage of it to download their work on others) brings to the team a climate of mutual support and sharing that will bear fruit over time.
Conversely, not being available will create a climate of distrust and low stimuli for information sharing. You will come to create sub-groups in the team and you will lose the strength of the group.
Remember when you were a young developer
I noticed that being patient and spending time making young people grow has an enormous value.
Having the patience to drive younger developers in the right direction will allow them to be more productive and collaborate more effectively with the rest of the team. So when someone asks for your help or simply wants an opinion on the code he wrote (because he may be less expert) give her/him the right attention.
Invest 5 minutes to gain 5 millions
The first time I worked in a team of developers and I was given a problem to solve, I started with my head down and implemented the first solution that came to mind. This solved the problem, but the solution was not always robust and / or elegant so that it could be easy to maintain over time by myself or other team members.
Over time I learned that it is very important to do an initial brainstorming with other developers who have worked on similar problems or who have a level of seniority in writing the code equal to or higher than their own.
Investing time in an initial analysis of the problem, and comparing oneself with others, helps to see the problem from multiple points of view, even completely different from each other, giving rise to solutions that were not thought of initially. This has the great advantage that the sum of experiences is not an algebraic sum, but generates much more value.
When the client … “doesn’t know how to say”
Sometimes it happens to deal with customers who do not have clear ideas from the beginning, so we start with specifics and throughout the course of development we “continuously adjust the shot” following a tortuous path of new requests to be satisfied.
The first few times I was dealing with this type of customer, I started like a rocket to develop every specification that was required and every time it was a small defeat, because there was always something that had to be changed or added.
Over time I have adopted a different technique: when you understand that you are dealing with a customer who does not know what he wants, the right approach is not to say yes to everything and develop every request, but to do questions.
Ask the motivation of each specification if you have doubts. This approach helps the client to think about the reason for his request, and tries to draw out the reasons for change of direction. Those specifications that don’t have solid foundations will disband themselves, while the others will be those that will actually be implemented.
Another technique that I have adopted with these types of customers is to illustrate one or more possible solutions to their request and to highlight their costs and benefits. This will help the client to evaluate a request and figure out if you actually worth the cost or whether it is better to postpone it to a future release. Most of the time will be accepted with a lower cost solution and further benefits that generally corresponds to that with low development time.
Keep your client in the loop
When you are not dealing with customers in the first person or you are not using an Agile development methodology, it happens that you see developers who are starting to work on a project and disappear until they have almost completely implemented the project.
This lack of control over the progress of work generates anxieties on the customer side and a high probability of failure to achieve the project objectives.
A periodic check of the progress of the work with the customer or with whom we are interfacing is essential to have very important feedback and to make it clear that the work is progressing smoothly.
The thing will growth…
Many times I have dealt with customers who come to ask to do a job by starting the sentence by saying:
“It’s a small job, we want to validate an idea”
Designing and developing the application thinking that everything runs out there, in 99% of cases it is a mistake. Most of the time it happened to me that the customer was passionate about the project and wanted to make it grow adding functionality, making it a job that was expanded even with subsequent projects.
I learned that even if you start with a small project, it is better to structure the software in as modular as possible components so that they can be replaced and re-engineered later so as to easily follow the changes of the route introduced over time. If you implement a software concept that only serves to demonstrate the idea you need to be willing to throw away what you wrote and rewrite it in a modular way if the project likes and will grow over time.
Conclusions
I have understood a couple of fundamental concepts for me:
The readability of the software is worth much more than its compactness.
Teamwork and the diversity of ideas brought by different professional cultures is priceless.
