I work on Travel features at Google, where I lead a team of engineers working on a brand new product. I get to tackle business and technical challenges while also growing a great team.
Previously, I worked as a consultant in Europe, where I helped a number of companies across several different domains and technologies. I also learned a great deal about the human factors involved in delivering software projects. 😉
You can find out about my professional activity in the Experience section below.
Before starting my career in the industry, I spent some time at the Artificial Intelligence laboratory of the University of Milano–Bicocca and published articles on Genetic Algorithms, Neural Networks, Cellular Automata and Natural Language Processing.
If you would like to get in touch, the best way to do so is to email me .
A selection of popular articles
While issue trackers originate as tools to manage projects more effectively, during the last years of work I have been through some situations where their misuse backfired.
Tools originally conceived to improve workflows and project lifecycle became a significant burden for the team using them, occasionally making difficult situations even worse.
This post is a collection of bad patterns I have seen happening. It is not a survey of all the possible situations that can occur. It is not meant to be an argument against issue trackers (if it tells anything, it will probably be about the teams I was part of), but rather an overview of things that went wrong because of the way a particular team used those systems.
In retrospective, most of the problems were due to a lack of discipline and experience of the project teams, and they are less frequent – if present – in a team of seasoned professionals. But, while training and education can certainly help, I would love to consider a different aspect: the issue tracking systems were not helping as they could have.
As Software Engineers, we often tend to be overly optimistic about software. In particular, it often happens that we underestimate the probability of systems and components failures and the impact this kind of events can have on our applications.
We usually tend to dismiss failure events as random, unlikely and sporadic. And, often, we are proven wrong.
Systems do fail indeed. Moreover, when something goes wrong, either it’s barely noticeable, or it leads to extreme consequences. Take the example of the recent AWS outage: everything was caused by a mistake during a routine network change.
Right now, some days after the event, post-mortem analyses and survival stories count in the dozens. There is one recurring lesson that can be learned from what happened.
Things I built on my spare time
I love building software so much that I spent some of my spare time writing code, from algorithms and data structures to small products and web applications. Below some examples: some of them grew to become quite successful.
More on LinkedIn
Part of the Google Travel team, led several successful user-facing features from inception to launch and contributed to many more. Notable examples:
Currently managing a team of engineers working on a brand new product in Travel.
Technical lead responsible for the design and development of several enterprise applications based on a diverse set of technologies, ranging from pure backend to full stack.
Routinely worked with clients across several industries (finance, retail, media and others) both during the sales process and later on as analyst and advisor.