Habits are one of the most powerful things about the human being. These allow us to be super efficient and to perform actions even without thinking about it. Think about when you put your shoes in the morning. Put your right or left first? If you do not know how to answer it is normal, because by habit you are doing it without even thinking about it and you will do it, in the same way, every morning.

A habit follows the so-called “circle of habit”:

• A signal stimulates the habit

• The routine is activated (the usual action we do)

• Gratification arrives

… and so on until the next time the signal activates the habit.

Stay focused

The first habit that I created is to focus on the problem to be solved without distracting me with external notifications and noises. When I have to solve a problem, especially if complex, I try to focus on it and to immerse myself in the problem by visualizing it mentally.

This makes it possible to develop much more efficiently and effectively because you make fewer mistakes due to distractions. Another advantage is to solve quickly the problem or understand that it is appropriate to ask for help.

A good technique for training concentration on a problem is that of Pomodoro. This is about dividing the work into time slots within which one tries to solve the various tasks assigned.

Another technique is to focus on one problem at a time. Multitasking is one of those deleterious activities that give us the illusion of doing more work at the same time. This does nothing but slows us down because the human brain has a certain latency in getting used to the change of activity. In reality, we will spend more time than we would need to do the same tasks sequentially.

Compare with a colleague (Peer Review)

Another habit that I wanted to create is that of the PeerReview of the developed code. None of us is the best developer in the world. When it comes to software development there is always something to learn from someone else. Confronting with other developers in a constructive way is always an opportunity for growth.

Peer review should not become a more expensive activity than development itself, otherwise it will lose its effectiveness. In general I try to make it very slim and divided into these phases:

• Reading the documentation you must understand how the code works.

• Looking at the code you should check that

  • The coding conventions are respected.

  • There are no gross errors.

  • The structure is not complicated to understand. I believe that a simple code to understand is a strength, as anyone can get their hands on it. Furthermore its maintenance over time will be easier.

A paved road of good intentions

How many times have you said or heard:

“Oh well, this time we had to write the code quickly but 
next time we write the documentation and tests”

A good habit to cultivate is to do now what you would postpone to tomorrow. We know that the next time will be like the last one if we do not decide to change.

Most of the time it takes a few minutes more to add documentation or write a test a bit more meaningful to a piece of code. We must abandon laziness to its destiny and work hard to be consistent in carrying out our work in a professional manner.

Do simple things first

When I started developing software, I used to start from the most complex tasks so that I could stay the simplest ones at the end. This allowed me, once I had passed the biggest obstacle of the difficult task, to see the remaining road downhill and then finish the development quickly.

However, this approach has a couple of drawbacks:

• The results to show to the customer will only arrive after a long time from the beginning of the development.

• We will not see a task completed for quite some time, so psychologically heavier.

With the passage of time, I wanted to get used to reverse the order (less than essential dependencies in the development tasks): first the easy tasks and then the complex ones.

In this way, we can give the customer something to see in a short time. If he will change the specifications, it is not said that the complex task is yet to be realized.

Build the building blocks

Another habit that I wanted to look for is to analyze the code every time I finish developing a feature or a component. Before going on with the next task, I think if it is not possible to create a slightly more generic and / or reusable version of the developed component and that maybe it can also be used in other contexts.

If the answer to this analysis is positive, I take the time to create a modular and reusable version of the component that has the least possible number of external dependencies or none.

Document the code at the appropriate time

The documentation of the code is considered by many developers an extremely boring activity. To make it more pleasant and useful (not only to those who will read the code but also to those who write it) I have established the following habit.

Whenever I am about to insert a new feature in the code, I first write its documentation. In practice I try to describe with the documentation the new functionality, its parameters and the return value.

This causes the brain to move from the code writing mode in a compulsive to a more reflective way. In this way, I can understand if the new functionality is really necessary or if I can implement it in a different way.

The result will still be a code with a large percentage of documentation without having the burden of having to write everything at the end.

The post The 6 habits to improve software development appeared first on nEraLab - Mobile and desktop Development.

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.

The post The 10 lessons I’ve learned to better communicate in a development team appeared first on nEraLab - Mobile and desktop Development.