Are you a senior software engineer yet?

09 Jan 2022

As of writing this post, it has been approximately 7 years since I wrote my first hello world program. During this time, I have gained a lot of knowledge and been part of dozens of interesting projects. Somewhere in the middle of this career I felt and knew that I was no longer a newbie, but rather a mid-level engineer. The real question for me now is whether I am a senior software engineer or not there yet.

The following more or less sums up my career transition from my perspective:

I did find my answer, though. How about you? Are you a senior software engineer? Well, if you don’t know yet I am here to help you answer that question for yourself :)

I personally learned three things on this topic. First, if you are not sure you are a senior engineer, you are probably not one. Second, if you are not sure you are a senior engineer you are better off assuming that you are not one because the opposite could be limiting to your growth.

Third, if you cannot cross out the following checklist, you are probably not a senior engineer:

Debugging is an investigative work and software development is full of “crimes” — few committed knowingly, most unknowingly. As a senior software engineer, you should be able to debug pretty much anything and find the underlying root cause in a reasonable timeframe. Debugging is mostly done through the method of exclusion — just like Dr. House skillfully eliminating possible diagnoses using the patient’s symptoms and test results.

Code reviews are an essential part of a healthy software development cycle and are intended to improve the software quality by reducing those “crimes” mentioned above. It is easy to criticize a piece of work and we humans are so good at it. However, a senior engineer knows that code reviews != code criticism. Rather, it is helpful practical feedback on a piece of code. Let me stress those two adjectives there: helpful & practical. For example, a helpful review does not contain a suggestion without providing at least one possible solution. That is, “I don’t like this method name” is not helpful while “This method name could be improved. How about this and that?“ is. There is a whole culture around code reviewing, that you as a senior engineer should embrace and be an example of in your team.

Strong mentorship skills are another sign of a mature software engineer. Personally, the idea of mentoring is exhilarating. Imagine one knowledgeable, skillful, and confident software engineer capable of building amazing things. Say that person is you. Now, imagine two knowledgeable, skillful, and confident software engineers. What can they build together in a team? The answer is (amazing things)^2. This is why solid mentorship skills are highly appreciated in companies. For me, it is difficult to describe the traits of a strong mentor (maybe because I am not a strong mentor yet), but I am sure that your success as a mentor can be measured by how well your mentee is doing.

The skills mentioned above are quite overlapping. For example, code reviews and mentorship overlap over the idea of providing guidance to your fellow engineer. However, the most overlapping them all is communication. In fact, communication is central to all those items in the checklist. For a senior software engineer, strong communication skills (both technical & non-technical) are a must. The only practical way to improve your communication is by doing more of it.

I have been recently introduced to the interesting idea of a T-shaped engineer. It basically means that the engineer is an expert in one specific area of software engineering while being fairly competent in other areas. It begs the question of why you would want to be an expert in something. The answer is to have a greater-than-average impact. Being the best at one thing is always better than being good at many things. Being fairly competent in other areas is also important since you can still bring about good outcomes in a collaborative environment.

Understanding the trade-offs behind every design decision — SQL or NoSQL? UDP or TCP? Availability or Consistency? REST or RPC? etc — is an essential skill for a senior engineer, which is the reason why most companies thoroughly interview senior candidates on system design. The deeper you understand the underlying elements of those trade-offs, the better your design decisions are.

The last question to ask yourself before changing your title on LinkedIn to “Senior Software Engineer” is whether or not you delivered a feature/product end-to-end successfully. It is the part where all things discussed above come together to make an actual impact — to deliver something that truly matters at the end of the day. The end-to-end delivery of a feature consists of several different stages: gathering requirements, designing solutions, implementation, testing, releasing, and maintenance. Delivering a feature is usually not a one-person job, but if that is the case you should be able to do all those stages independently. Delivering a feature is usually teamwork and as a senior engineer, you actively contribute to requirements gathering and solution designing while guiding the rest of the work.

As you see, these things cannot be acquired overnight. Rather, these skills are formed over many years — thus the word “senior”. However, having 10 years of experience does not necessarily mean you are a senior either. It is very possible that you have spent those 10 years just doing pure coding. You might be a tech monster, but that is not enough to be a senior software engineer.

Earlier I said I found my answer to the question and my answer is that I am not a senior engineer. This is actually a good thing for me because it means there is a lot to learn and a lot to do. And, I love learning and doing.

Happy learning and doing, my fellas!