Lately, I’ve noticed posts making the rounds again on what it means to be a “senior” software engineer. Most of these posts center on two things:

  1. How fuzzy the definition of a “senior” software engineer is, and
  2. How unlikely it is that developers in their early 20s meet that definition.

Now, I’m not going to bother adding yet another definition to the mix, but instead I want to focus on the 2nd point mentioned above.

As someone who has been privileged enough to become a “senior” software engineer at LinkedIn with only a handful of years of experience under my belt, it is often frustrating to read these posts. Why? Because they come across as condescending and, in some cases, insulting. The implication is that due to my age or years of experience, I am not qualified to hold the title I do. Whether or not that is intended, is beside the point.

Aside from the fact that actual title and real proficieny/expertise are often tenuously associated, there is great danger in equating age and specific time frames with actual experience. There is the obvious trap that two engineers of equal age are almost entirely unlikely to have the same skill set, but there is also the subtle trap that two engineers with similar experience will have been exposed to the same problems and encountered the same experiences in solving those problems.

Thus, my point in writing this is to encourage discussions on “seniority” and “leveling” in software engineering to focus primarily on skill sets; not on age, years of experience, or even projects shipped. In doing so, you’ll avoid alienating up-and-coming engineers (many of whom already feel unqualified for their titles) and help clarify the skills which they should focus on developing.