After a year of work, revisions and changes, my first book in paper format is finally available on Amazon

:
Design Patterns – Practical Cards for Beginners

For now the book is in Italian, but I’m working on the English version.
At first I was undecided whether to add the word “beginners” in the subtitle. I said to myself that when you don’t know a subject or don’t know it very much, you are a beginner.

This does not mean that whoever will read the book is an absolute beginner with respect to software development. Perhaps they have never used the patterns or don’t know some of those described in the book.
In my small way, I tend to feel like a beginner. In this way I put myself in the mental condition of being open to accepting new ideas, new opinions and different points of view.
Criticisms, when they are constructive, are worth gold. They allow you to improve and enrich your cultural / professional background.

Writing this book was exhausting. I left full of enthusiasm thinking it would be a walk.
Then I realised that to do things well, and try to transfer their knowledge in a clear and simple way for those who are just a beginner, it was not easy.
Simple isn’t easy. To simplify it is necessary to remove, remove what is superfluous and get to the essential. To do this, you need to know what to remove and what to leave, in order to transfer the message you want to give.

I hope I have succeeded in this task. The greatest satisfaction for me will be to know that the book has been useful for someone to improve their software writing style.

Enjoy the reading.

Other posts that may be of interest

• The 6 habits to improve software development
• The 10 lessons I’ve learned to better communicate in a development team

The post New book presenting a practical approach on design patterns appeared first on nEraLab - Mobile and desktop Development.

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.

Photo by Joshua Earle on Unsplash

Presentation of the new site

The first article of the blog I wanted it to be the presentation of the new look of the site and the mission I gave myself starting from the name of my project: nEraLab.

I’ve decided that was the moment to change the previous site (plain-HTML) into one with the possibility to have also a blog. I would like to tell the reader all the experiences of this journey describing the birth of the developed applications. This will allow the clients (actual and potentials) to know better the products available into the site. I consider the user as the most important  part of a project. To have feedbacks and understand how a product can be improved giving the user more value is fundamental. This give me a big satisfaction.

I wanted for the new site a simple structure. It has a single initial page, so to enhance the developed applications and the last blog articles. Sometimes it’s difficult to summarize in an AppStore description the reasons that led to the development of an application or its strengths. This can be done instead with a blog post, which is designed to deepen and explain to users the choices made in the implementation phase.

The journey to nEraLab

We come now to nEraLab, when it was born and why. A few years ago, it was 2009, with a friend of mine we had set up the MitAPP project. It was focused on mobile development for the Apple devices. We had started almost as a game and within 6 months we found ourselves overwhelmed with requests for iPhone applications. All this without the use of advertising or paid marketing but simply through the word of mouth of the customers.

A couple of years later, MitAPP has been acquired by a small Italian company. Unfortunately, in just over a year everything ended with the definitive closure of the company.

I’ve continued to carry on my software development activity on C++, Python and Javascript/NodeJS. After another year, the desire to get involved in something challenging has come back overwhelmingly.

nEraLab (new Era Laboratory) is born. A new era of my life, in which to work on the development of applications designed by me. The idea is to develop useful products that make users’ lives more efficient and easier.

Brief description of the products

Font Studio is the first product developed. It borns from a practical need to choose the right font for a text. Instead of repeatedly applying different formatting to a selected text, Font Studio displays the text with all the fonts available on your Mac. This drastically reduces the time to choose the right font. Another example is the iPhone and Apple Watch application: What’s Happened On This Day. It was born at the time of the presentation of the first Apple Watch version. I wanted to create something that had to do with time and at the same time was informative. It shows the events that occurred in the past years corresponding to the today’s day. It is a sort of time machine that allows us to remember past events and anniversaries. I then devised the Kronos Time Tracker to keep track of application development time and costs in the easiest and most agile without too many frills. In applications and more in general in the software development, I’ve always believed that simplicity was a strong point and not a weakness. When things are simple, people learn them quickly, use them easily and developers manage them quickly.

Other posts that may be of interest

• New book presenting a practical approach on design patterns

The post nEraLab Presentation appeared first on nEraLab - Mobile and desktop Development.