Stepping up in your career
You know… being a techie it’s not all about coding, design patterns, architecture, and funny memes while our project is being scrutinized by the CI/CD pipeline and running the tests. Part of it is also about progressing, evolving, and fulfilling our personal goals (and sometimes aiming for bigger salaries). So, if you’re working in tech, starting as an engineer, or having doubts about your career progression, I’ll dump here my honest and personal lessons. Take this as my personal changelog from my early days as a software engineer to currently managing engineering teams (let’s hope I don’t get aggressive comments on the PR [lol], this is just my contribution to your career repo!).
Understand what kind of software engineer you are
I don’t mean the stack but the way you know yourself. This topic impacts the way you face challenges as well as how you interact with others. You need to understand if you are (or want to be) a super development guru or simply have enough knowledge to stay within the development world. It seems a trivial/banal question, but especially when you’re younger or even facing imposters syndrome, it impacts the way you participate in discussions or simple tech talks. There is absolutely no problem saying “I don’t know” and it’s absolutely expected that you find people that know more than you (or pretend to). Ultimately, mastering your reactions and the awareness of your own engineering skills will help you make better decisions about the next step in your career.
Trends are something from the past
Back in my early days in tech, we were called everything but software engineers. Programmers, IT analysts, webmasters (my favorite), etc… our job wasn’t cool enough to deserve a decent name. Only after the IT market boomed, geeks began to be cool and soon the conversation topics weren’t which car is the best, but which programming language was the next big thing. I saw people fighting each other to prove their programming language of choice was the best (even when the same result could be equally achieved). Then JavaScript libraries are born every second, fattening projects all over the world (more trends to be googled if necessary). At the same time, I was debating with the same question as other engineers: “what technology shall I work with so I thrive in my career?”, not forgetting we were in a world where there weren’t yet <front/back> end or other sorts of engineers… we were IT people. I ended up following down the line of having fun! When Java and C# was taken by big corporates, I was doing PHP. When e-commerce exploded and demanded huge amounts of engineers, I was doing business intelligence tools within a Microsoft environment. When JavaScript turned into a one-size-fits-all, I was advocating for different technologies for client and server-side applications. The main aspect for me was ensuring I was becoming a software engineer, not a language/framework expert (and there’s nothing wrong with that). With that in mind, I could try different worlds and apply my experience in different scopes, the best suitable techniques from other technologies. Whatever is the technology you’re working on, be sure you master it. It doesn’t matter if it is outdated… programming languages change and go! After all (private joke) PHP is, since 1994, a temporary programming language, meant to be replaced. Your everyday choices will decide where you’ll be after 10 years of working in software development. The fact I didn’t follow down the route of trending, even with great and profitable opportunities, allowed me to be a versatile software engineer and many years later to embrace bigger and more challenging projects, “almost” be a language-agnostic engineer, and therefore, have more open doors when looking for new projects.
Being a senior software engineer is not something you can buy
I have to say: “Senior” level is something you deserve, is something you earn from your peers. You achieve it by experiencing many failures, by delivering tons of bugs, by failing deadlines, and after all… learning from it, so tomorrow you know what to do so your project is a great success. In one way, it is a great feeling when we celebrate our successes or we try new architectures, and our code is shining in a production environment remaining untouched for many decades. On the other side, it is fantastic when our peers feel safe by having us on their team, other engineers ask us for expertise and advice, when our impact on the project sets it for success, and the business reaches success for many decades even after you left. But the truth is: Reaching all the above aspects takes time, personal commitment, and willingness to learn! It shouldn’t be something you negotiate with a new job offer (because probably some company is desperate to hire a bunch of engineers). This sort of conversation gets harder when talking with young engineers (3/4 years of experience). With a very demanding and competitive industry, younger engineers are prioritizing the “senior” role title as their top objective and this can happen for multiple reasons: They want a way to distinguish themselves from their friends or peers in the same company, they want a bigger salary, they want recognition, or simply, because they know how to implement an if statement as no one else (once again, a private joke). As their manager, raising questions like “role title vs salary”, “responsibility vs compensation”, or “would the rest of the team respect your new role and are you prepared for it” in almost all the cases make them feel unsure and suddenly their awareness on the improvement points starts to pop up. So, if you want to become a senior engineer, please ensure all the above, and don’t rush it!
Leaders or Managers are expectation traders
By avoiding micromanagement and allowing engineers to design, plan, decide, and implement the solution, we will be creating a mature and efficient team. But what’s left? Leadership roles are basically the bridge between multiple parties. In this role, we are expected to (pick one or multiple) manage the project delivery, ensure technical excellence, manage people, manage roadmap execution, manage technical debt… and manage… and manage. That is why I summarise these roles as “expectation traders”. The expectations are created from the starting point of any action: The first day a new engineer starts on your team, career path expectations are defined; A new performance review cycle will be defined by expectations your manager has from you and your team; When a new project is kicked off, business and tech expectations are defined. For all of these (and way more of them), you are managing the expectation of reaching success! Avoid focusing too much on your comfort zone, never assume something is obvious, be transparent in all the decision points, and be the first one triggering the difficult questions! In a leadership role, the expectation is that your team succeeds in delivering success and you take account of failures.
