What is this? Where did this passion come from and when I started? Sometimes I'm thinking about everything I did in my career and what each step contributed to what and where I'm today.

Early Years

In the first years of my career, when I was a "simple" developer coding and learning all day long, I started going out of my comfort zone. To code with your team is "easy" (yeah, I know not always, but it is my story and I use the words I want 😂), but what about teaching others? What about going on short missions to help to fix bugs? This is what I did and, trust me, it was not so easy for the younger me.

My company at that time ( Bytecode if someone is interested in it) was RedHat partner and thanks to this share, I started teaching "everything around Java"; mostly it was the JBoss training, but RedHat has some other training in the Java panorama. And with the training weeks, I even started as a consultant. We can resume the job I did as "come and help us doing what we are unable to understand". At that time I thought both two activities were very stressful: you can't be prepared for the unknown, but today I know it was the best thing I could do to be stronger and to quickly enlarge my knowledge.

The Debugger

The missions were always about 1 week long with the same pattern:

• the first day morning: technical meeting to take information about the architecture, about the code and explaining the problem
• the first day afternoon: prepare the laptop with everything needed to help to debug the problem.
• Debug, Test, Check, Ask, ... it was my week.
• The last day: report about the solution, when found, or about a possible way to fix the bug by the company itself.

For sure each time, a "3/4 years experience guy" coming into a company with "much more veteran people" was frowned upon. And this was my feeling too. What do I have to teach these guys? This is the project they are working on every day, in a framework they master and they have more experience than I've today. Each time... everywhere in Europe. What helped me was to think: "they are skilled for sure, but if they called someone outside it is because they found nothing at all". So here we go...

In few hours I needed to understand how they code the project, how they configure the servers (Clouds were only in the sky at that time 😂), how I can access everything and starting making debug, load tests, code review, ... A "3/4 years experience guy"! I don't remember if each time I had a success, but I'm sure most of the time I helped the company fixing the problem or finding a possible solution. Each time, anyway, they were happy I could help them. Each time I was happy too and surprised to see how I could go far in debugging things and finding the root cause. Each time it was a real big pleasure. As a developer, it is the same when you find the code to fix the thing you looked at all day long, but 10 times more. Because I was a developer needing to understand even much more than just a piece of code: I needed to understand networks, servers and JVMs configurations, Databases, ... and everything related to applications developed and deployed by someone else.

Today

Now my job is a bit different, but when the situation arises I'm still always helping to debug things. Not with the same stress of the beginning, but always with the same pleasure and always with a big smile on my mouth in the end.

I'm managing technical people, the new generation of developers: the "Cloud Developers"... and I'm not always able to find a way to make them love this part of the job. The code is cool for sure, the code is what we can see and what our "customers" are using... but if we are not able to make it work smoothly in production, or even just deploy it in production, all we did became completely useless.

So, "younger developer", trust me: the production is not only a matter of System Administrators, especially today with everything managed by someone outside the company. In the same way, you are debugging your code, checking "step by step" each variable value, you can debug your infrastructure. Find at which step a call can block; understand from which components an HTTP call is coming to your webserver; understand how the application server is managing it; the memory and CPU interaction; the database calls, ... there is a ton of things to know 😱😅🤩. Don't look just at your IDE... the world can be even better outside.

And when you will then come back to your IDE you will know. You will know how your code will work in production. You will know how to write better and performant code.

Trust me: the whole IT is love and pleasure 😎