Senior vs Junior Engineers

Junior developers usually just focus on getting something to work without taking the larger architecture into account or making changes. When they receive advice on how the architecture can be improved, they tend to fix the symptoms of bad architecture instead of fixing the actual issues. They often leave messy code lying around or leave mistakes and unhandled behavior in the code. They can end up taking a “someone else’s problem” attitude towards the messy code and shortcuts they left behind.

Mid-Level engineers can usually build features and fix problems on their own without any guidance. They are well versed in how to architect software but they can’t figure out when they are over engineering something and can’t seem to find a way to stop over engineering. Because of this, they often take longer than is reasonable to solve a problem. The mid-level engineer suffers from “shiny toy syndrome” and is always looking to introduce new technologies into the code base for them to tinker with and explore, sometimes these tools are inappropriate for the use case, or worse, become detrimental to the project. Mid-Level engineers often do not take the social dynamics and strengths of their team into account when picking up new technologies, this can also have the detriment of making junior and other mid-level engineers perpetually junior, as they do not have the opportunity to use a tool long enough to hone to their expertise. They might subliminally take satisfaction in being the only person who knows a new tool and may move away from it once others know the tool. A lot of their over engineering can result in ultimately unmaintainable code that can be a nightmare for the team to clean up later once the mid-level engineer has left the company. This is because that while mid-level engineers have a better grasp on how to draw boundaries and create abstractions, they have not progressed far enough in their journey yet to know “where” to draw those abstractions. Mid-Level engineers can be particularly dangerous to an organization. They are often mis-titled as “Senior” engineers, because their prowess and passion for shiny toys and over-engineering make them appear to be “high caliber”.

Senior engineers rely on their experience to identify where to draw abstractions. They know how to over engineer any given problem but have learned to exercise restraint and only introduce their engineering prowess when it is truly beneficial to the project and outweighs the cost of added complexity. Senior engineers focus on collaboration and leave behind code and documentation that makes it easier for the next person to quickly get up to speed. Senior engineers do not suffer from Shiny Toy Syndrome. They see the significant cost and stress that can be placed on their fellow mid-level and junior level engineers when forced to pick up a new tool or language and weigh that with their decision to pick up a new tool. They take into account the social dynamics and skill sets of the team to optimize to their strengths.

Levels of Seniority