Recently, I was promoted to the level of senior backend engineer. As much as I felt that this was a stamp of recognition on the work that I had done, I felt like an impostor when I compared myself with what is out there. I have been writing code professionally for about 2 years and I have been working remotely at this company for 7 months (probation period included.) Senior engineers usually have 5 years and above of professional experience under their belt. So what did I do?

After accepting the offer, I combed the internet for thought pieces on who a senior engineer is. I felt more comfortable after studying a large percentage of them.

Dear reader, you are fortunate because I will highlight the consistent themes I found in the resources in this article. I will also provide links to them. The good thing is that these resources were created by established senior engineers in the field so you can trust them. Before I highlight them though, I would like to state a couple of things that I did that I feel influenced the promotion. I cannot state which of them was the deal-breaker though.

How I worked

  • With minimum amount of input from my tech lead, I designed and implemented the backend of the MVP 2 products, and I finished building each one before the estimated deadline

  • I was as concerned about the business value of my work as I was about the ‘quality’ of my code. In doing this, I made sure that I delivered fast. The company is a startup and is in the testing ideas stage. I considered it important to move, fail, learn, recover and succeed fast

  • I engineered a more effective and costless solution to a challenge that we had been trying to solve through paid external services

  • I got involved in all parts of the software development life cycle. I was always asking stakeholders questions, trying to clarify the product requirements and also giving suggestions for improvements and features from a user’s point of view

  • I was concerned about the (technical) work of others, always providing reviews and suggestions for improvement. I got involved in setting up systems for not only my projects but also for others on the team

  • The language in my stand-up reports was less technical and clear enough for non-technical people to understand. I consciously made sure that they were memorable. If someone asked a stakeholder what stage we were in the project at any time, they should vividly remember

  • I focused on being trustworthy and dependable by updating everyone without being (micro-)managed and I kept communication open, empathic and simple

  • I intentionally praised and appreciated the effort of and the work done by my colleagues publicly

Who is a Senior Engineer?

What first comes to mind when this question is asked is the number of years of professional experience. Fortunately, this metric has been rebuffed by all the senior engineers that I have listened to. The emphasis is on the content of the years and not the number of years. What is the range and depth of problems that you have successfully solved? How deep is your knowledge of the technologies that you work with? Are you a leading expert in that tech field in the company?

Another idea that stands out is that even though the content and responsibilities of the senior developer role differ across companies, soft skills (empathy, [technical] communication, humility, leadership) and focus on the business value of engineering decisions (and code) are cornerstone characteristics of senior engineers.

Aside from these two, other characteristics I got from the resources I studied are that senior engineers

  • are more concerned about/would spend more time on the business value of code than on how ingenious their code (quality) is. They know that the best place to truly test code is in the hands of the user

  • are force multipliers within their teams. They are concerned about and have impact on the development and productivity of others on their team through leadership and teaching

  • can design and architect systems to achieve a product goal

  • communicate ideas effectively and efficiently to stakeholders

  • use ‘best practices’ based on context. They would not apply an Amazon or Google solution to a startup problem if it does not fit

In retrospect

I am proud of what I have achieved. I love responsibilities and that is why I accepted the promotion. That stated, I would not have been able to achieve this without the support of my colleagues, and I am grateful for the kind of working environment that I find myself in.

I appreciate the engineers who contributed to the resources I found. Blessings!

Cheers to doing more and being more 🥂

References

Books Recomendations from the References

  • Extreme Ownership by Jocko Wilnick
  • How to Win Friends and Influence People by Dale Carnegie
  • Thinking in Bets by Annie Duke
  • The Pragmatic Programmer
  • Clean Code by Robert Martin
  • The Lean Startup by Eric Ries

I recommend The Pragmatic Programmer by Andrew Hunt and David Thomas.

Illustrations by Storyset