My Motivations

Over the years, I have learned how and under which conditions I like to work, what drives me, and which criteria enhance my productivity and happiness.


Curiosity and eagerness to learn is a personal driver like no other. It applies to both the Domain and the underlying technology of the business. I usually find the most mundane activities exciting as long as there is some depth to them.

If you can provide me with a challenge and the tools to navigate the domain, you'll make me a happy engineer.


An open and diversified environment is vital to me. I thrive working in cross-functional teams, where autonomous people help each other achieve the best results. Waterfall and micro-management are not acceptable.


I work more effectively when the company shares as much of the long-term intentions as possible. It prevents misunderstandings, leads to better technical decisions, and encourages a trusting work environment.

Work-life balance

I am a workaholic. It is easy for me to end up putting work before everything else, my wife, and kids included. This is not a OK behavior. I'm consciously trying to cope with it every day.

While I am OK with putting in a few extra hours on rare occasions or getting paged when a critical system is failing, regular over-time is NOT something that I am willing to do, and that if recurring must be addressed.

I also value flexible working hours and occasional remote work.

Open Source

As an active consumer of many open-source projects, and occasional contributor, I value Open Source software. To be able to contribute back to the open-source community while employed is important to me.

If you have Open Source projects of your own or help maintain someone else, you'll immediately gain extra points with me.


I am conscious of where I am now and where eventually I want to end up. I have also learned to be deliberate about my career choices and to set up goals.

First, I am looking forward to taking more ownership of the back-end code.

My next goal is to learn new programming languages, the specific of which mostly depends on the business requirements. (Still, my candidates would be among the functional family.)

The long term plan is to keep climbing the engineering ladder without getting involved in any management or business role. (I like to code if it is not already obvious)

To achieve these goals, I need an environment where knowledge sharing is encouraged, pair-programming is the norm, and mentorship is made available.

Failing together

Given that I am primarily driven by the desire to learn and that my learning process involves making mistakes and learn from my failures.

It is of paramount importance to me to work in a safe environment where experimentation is encouraged, where mistakes are considered tools to shape up a better understanding of that specific context.


If these were the movies, then I would be that actor that always gets typed-cast, just because he played a role once and now nobody can't see him as anything else.

Being always typed-cast as a front-end engineer has the double implication that:
  1. you are forced to specialize in a specific area
  2. you are driven away from those opportunities that would enable you to acquire the necessary skills for other roles.

For me to emancipate from this label, I have learned to think of front-end and back-end simply as the interfaces to code to. Different contexts where the same clean code principles and good architecture designs apply.

I think of myself as a software engineer who can learn and use this or that API as needed.

My previous work experience and contact informations are available in my resume.