Something About me: I started to program computers when I was 11 years old, as a hobbist. Even if I only started to program professionaly at 16, I already had enough knowledge to be the one responsible for solving the "hardest" problems (at least in the view of others).

Differently from some programmers that apparently love complicated code and consider the "hardest to understand, the better", I always wrote code to transform hard problems into easy to use solutions, effectively allowing other developers to do what they originally couldn't do.

I am often asked if I am a good team player and I think that what I just said explains it all: I am very good in making hard to solve problems into easier ones, creating components to help others. So, yes, I am a good team player. But that doesn't mean that everything I write will be understood by every developer. That means that I can work with less skilled developers and help them be more productive. But as I also write programming articles, I can guarantee that I can teach those who are interested in understanding my solutions.

I am actually considered a Systems Architect or a Software Architect, or at least that's the more direct translation of Portuguese and French names to what I do. My main role is usually to identify repetitive points and hard to implement points, and to create libraries/frameworks that will transform those points in easy to implement code that also avoids the repetition.

I should also say that I am not the kind of architect that "chooses" the best existing technologies to create a new application. I am the kind of architect that creates the required technologies that best fit the applications need.

The articles with * are articles that present frameworks created by me.

They are my samples to show how I transform hard and repetitive problems into easy-to-use solutions.