12 years mark

When I have started this website, nearly 4 years ago, I had an mind to use it as a showcase for my work and methodology.

At the time, I was heavily focused on improving the overall state of my career, heavily learning about FAANG career ladders.

In the meantime, it became a way for me to be accountable for my growth.

The structure of my plan was simple: each year of experience, I would write an entry (e.g., 10, 12, 15, 20, 30).

A few days ago, it was my 12 years of experience mark, and I would rather not write it anymore because the labor market does not seem to reward it anymore.

Today, in the latest LinkedIn discussions I had, there are two kinds of companies:

  • Those still writing code by hand, mostly “small” companies, which have two roles: SDE2 and Senior SDE
  • Those using LLMs to produce code, and as long as you have 5-7 years of experience, you fit the role

A few days ago, during a screening interview, my interviewer stated that they were looking for a 7-10 years of experience engineer.

I still do not know if he did not read my CV or if he tried to prepare for a lowball offer, but while I have always thought I was always too young, I have reached the point where I am “too experienced”.

It was my trigger to write this log, as originally planned. What has changed since two years ago? For me, the biggest event was joining LivTours.

I had to leave my comfort zone, becoming a freelancer, but it was really rewarding, even though leaving them grew my regrets list.

Something less flamboyant happened: a few weeks ago was also my 6-year milestone as a full-time Haskell developer.

More than half of my working years were dedicated to a so-called niche programming area, yet I was so fortunate to work with it in 5 different companies.

I cannot have a sense of how it has impacted my mindset, but speaking with other engineers, it changes my day-to-day concerns:

  • Very few runtime errors

  • Very few regressions during refactoring or adding features

  • Large refactoring sessions without fear

  • Ability to reorganize a system quickly

  • More time to focus on the architecture and the domain.Yet, I still have some issues:

  • Data coordination

  • Distributed and deployment challenges

  • Politics and company organization frictions

One important lesson of these is my inability to foresee the pace of the change of software engineering, doing my best to leverage my expertise in this evolving field, so I look forward to the next three years.