My professional experience in software development began after some years working as a Business Intelligence consultant. Back then, I had already worked on ETL processes, created some panels and reports. At that particular moment, I was using statistical models (mostly regressions and time series) to make forecasts.

We are talking about a deliberately imprecise point between 2010 and 2015. At that time, forecasting/statistical packages in BI software were not available to us. I don't know if they weren't globally well known, or if they just weren't affordable for my (really small) company. In any case, a big component of my work was to extract the data from the system, make predictions, and integrate the results into reports and panels.

That was the perfect entry point into professional software development for me. In addition, because of my personal interests, I was already into programming. And because of my experience as a consultant, I had an idea of how companies work internally. As a result, I pivoted to software development quite smoothly.

With respect to my career purely in software, I summarize it in three phases.

In the first one, I mostly remember myself reading and reading. Then building, failing, and trying again. Then learning and starting again. All day long. The knowledge I was gaining from the professional world, through colleagues' experience, perfectly matched my interests in programming. Somehow, this feedback loop between my personal interests and my job made me learn really fast.

At some point, I slowed down my dedication to that loop in favor of other interests. I had already built dozens of projects for several purposes. I had saved systems from critical situations a few times. I was able to more or less solve any common kind of errors in systems. I was used to doing/solving/fixing things I had never seen before. I was able to tell which designs were bound to fail, and where. If some years ago I learned how to do things, now I knew how not to do software.

More importantly, I had earned mutual respect from my colleagues. Within the team, my thoughts, opinions, and ideas were considered on the same level as those of the other experienced engineers. Only in retrospect do I realize how fortunate I was to have some extraordinarily talented colleagues from whom I continued to learn.

Finally, the last phase coincides with my last position, which deserves its own section.

On My Latest Position

I worked as the lead software engineer at a healthcare tech company with people based in the United States, Spain, and India.

When I first arrived at the company, I was already an experienced engineer. That experience in both frontend and backend development allowed me to fit into the team in just a few days. From there, I brought to the table processes and key ideas that:

• Stabilized the product by identifying and refactoring problematic components.
• Enhanced robustness.
• Established a clear and realistic development process.
• Reduced bug incidence with best practices.
• Improved security.

Overall, I think the most relevant contribution was the change of mindset among the developers. I worked consciously and diligently with the team to:

1. Think more, write less.
2. Take reviews seriously.
3. Before estimating, think about the whole system, not just the feature.

By applying these principles, the delivery of new features became much slower. However, within weeks, the time dedicated to fixing bugs dramatically dropped to almost zero. Overall, feature integration speed increased a lot. As a consequence, the product owners' confidence in the product grew significantly.

With these points achieved in a few months, I became the lead developer de facto. I was included in discovery, planning, and other management meetings as the representative of the development team and responsible for the product's technology.

It turns out this puts a lot of pressure on you. This burden on my shoulders included:

• Designing and managing technological solutions that addressed business needs and challenges.
• Upholding quality standards in both product technology and the development environment.
• Mentoring developers and standardizing development practices across the team.
• Ensuring team alignment with project objectives and deadlines.
• Communicating the technological status and challenges of the product to the broader organization.

I was new to some of those responsibilities, and while I did not do a perfect job, I did a good one.

Additionally, I was asked to transition from a monolithic to a microservices architecture. I won't go into details about why I was asked to do so, but it was a good decision. I prepared a year-long plan for a minimal working implementation. We successfully carried it out in a year and a half, with some additional resources.

Unfortunately, three months before we finished that last milestone, my personal situation was already requiring me to stop. So, three months later, just after delivering this transition and making the knowledge transfer, I left the company.