The power of a good habit
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
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.
