The Worst Estimation Of Proficiency: Years

For companies it is hard to have a promotion path for software engineers. Some companies may have the option to promote to a leading role such as a team lead or a software architect. This promotion however contains a complete different role for the software engineer as he will no longer do any of the actual programming anymore. For some software engineers, among which I count myself at the moment, this is not desired, as it is the passion of the actual writing the software that drives us. This however means that some people will always be ‘stuck’ in the same role at the same level.

From this a different type of promotion path was created: the path of expertise. A software engineer with a lot of experience could use that experience and become an expert in some domain, giving him more responsibility for that part and decisions that have to be made. This is often indicated with the levels: “junior”, “medior” and “senior”.

The explicit expression of proficiency is not a problem, it is what it is based on that can cause problems. In the most common case the levels are based on the amount of years of experience:

  • junior: < 3 years
  • medior: 3 – 5 year
  • senior: > 5 years

As a junior myself, I have seen many more experienced software engineers (seniors) writing bad code. The cause is that just because you have been doing something for a long time, doesn’t mean you actually learned anything from all those years. It is very easy to keep doing things as you initially learned them, which causes someone to remain just as proficient as when first started.

Another big flaw in this system is that it ends when reaching the level of senior, which in this case is in only 5 years. Since most people will have a long career they will spend most of their life a senior and thus have no longer any career advancements, which was exactly what this system tried to avoid. Giving people who wanted to keep on programming a way of expressing how good they are. But with this mechanism it is implied that after 5 years you will have learned all required skills and not improve anymore. In a domain as software this is far from true, and if you do not improve your skills and participate in new technologies your skills that matter and thus your value may decrease.

Management however has no clue what proficiency as a software engineer looks like, and the years of experience is the easiest for them to understand. Moreover having someone who has less experience but is better have a higher title than someone who is older could cause conflicts within the team. Nevertheless, I strongly believe creating a framework that expresses the things on which employees will be evaluated and determines their proficiency.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.