A software developer’s career ladder consists basically of three rungs: junior, middle, and senior. The industry applies this terminology to better understand and assign a degree of qualification, as well as determine both salary level and responsibilities.
Being aware of the developer seniority levels will help set more accurate expectations for a particular engineer. Also, this distinction will not only improve internal communication, it will also enhance communication between customers and vendors, making all interaction more effective. By distinguishing these job titles, a client will get a better understanding of the competency levels in the IT industry.
In this article, we will analyze software developer’s seniority according to the following criteria: technical knowledge, day-to-day duties, independent work, interaction with the team, and vision.
Approaches to the expertise evaluation in software development
As part of the seniority level analysis, we’ll describe several existing approaches to evaluating a programmer’s expertise. Applying them to the given gradation will provide a broader perspective of seniority in software development.
The Dreyfus model of skill acquisition identifies 5 stages of attaining and mastering skills. Andy Hunt in his book Pragmatic Thinking and Learning: Refactor Your Wetware applies the Dreyfus model to software development. The author uses the Dreyfus model to structure fundamental changes that occur throughout the learning process. This allows him to juxtapose how programmers at different stages perceive the development process and approach problems, as well as, how they form mental models.
The five Dreyfus model stages illustrating the most important changes on the way from Novice to Expert Source: Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt
The Seven Stages of Expertise in Software Engineering. This is another approach to classifying expertise in software engineering by Meilir Page-Jones. The classification breaks expertise down into seven stages and uses productivity as the key criterion. Although originally used to evaluate software engineering in the ’90s, the approach can be easily reapplied to our reality.
The Productivity Curve Source: The Seven Stages of Expertise in Software Engineering by Meilir Page-Jones
Programmer Competency Matrix. This matrix of the programmer skillset was developed by Sijin Joseph, a technology leader with over 15 years of experience in designing and building software products. The matrix has a three-level structure that correlates with the Junior-Middle-Senior role distribution. The matrix also includes Level 0 which, in our opinion, equals a Trainee-level Software Engineer. We are going to refer to this source while describing the tech knowledge expectations for each seniority level.
Approaches to expertise evaluation compared
Trainee: fresh out of school
Some companies have internship programs where they take entry-level engineers who have basically only theoretical knowledge and no work experience. In this case, a beginner’s job title will be a Trainee.
Applying Meilir Page-Jones’ stages of expertise, we chunk this early period in developer’s career into three stages: Innocent, Exposed, and Apprentice.
Initially, engineers have little to no exposure to real development. Exposed developers make the first steps towards coding in a professional way. Finally, an apprentice is already minimally equipped to tackle a real project.
Speaking of technical knowledge, trainees are primarily limited to using IDEs as text editors for coding without leveraging their additional features. They rarely deal with APIs and often have to consult the documentation. Apart from the core platform they specialize in, trainees are not familiar with any frameworks and have only a vague idea of what a database is.
Junior Developer: through trial and error
Getting your foot in the door as a junior developer is difficult because they often come and go. Employers tend to hire junior devs for freelance or short-term contracts with an eye to reducing the contract cost.
Nevertheless, a junior’s trump cards are the motivation and energy that many senior people no longer have. Juniors know the effort they put in will pay off by enabling them to move sooner to the next level.
Alternative approaches. Referring to the Dreyfus Model, we may divide the junior level into two phases: Novice and Advanced Beginner.
To get the ball rolling novice developers need universal context-free rules. Being impatient, they want immediate results. At the same time, mistakes can paralyze them, since they do not know how to handle them.
Advanced beginners start departing from following fixed rules and formulate general principles based on similar situations they’ve dealt with. The main issue is that they overlook the larger context, perhaps considering it irrelevant.
Using the Meilir Page-Jones’ gradation, we may refer to a junior as Practitioner. That is when developer productivity sufficiently increases as they begin to adopt new techniques through trial and error and apply them to corporate projects.
Junior technical skillset and duties
IDE. Juniors navigate the interface and operate IDEs efficiently using the taskbar.
API. They know how to handle the most frequently used APIs.
Frameworks. Junior devs have worked with some frameworks and know about the popular ones that are worth using within their language stack.
Database development. A junior knows DB basic design techniques, ACID properties, and transactions. Also, a junior can write simple, select statements to retrieve information from the database.
Programming languages. Junior developers are usually familiar with one programming language. They will pick it right away and implement a semi-stable solution that solves most of the problems in certain use cases.
Platforms & tools. Juniors have professional experience with about three platforms. Their knowledge of platform internals is only skin-deep. They are aware of alternatives to popular and standard tools.
Day-to-day duties. Juniors usually get the least complex tasks, those with little impact on the final product.
Junior teamwork and perspective
Independent work. Certainly, juniors need close supervision. They need strong mentoring to grow their skills.
Working in a team, a junior must stay engaged and absorb from the team as much knowledge as possible.
Vision. The problem with juniors is that they are code-focused, rather than development-focused. This prevents them from getting the big picture.
Middle Developer: workhorse of the programming world
Junior devs with generally more than three years of experience can leverage their skills out to become mid-level specialists. Mid-level devs, sometimes referred to as “the workhorses of the programming world,” deliver the most impact with routine code.
Alternative approaches. The Dreyfus Model describes the middle developer as Competent. At this stage, they can also do a decent job of troubleshooting and debugging.
Competent programmers are highly initiative and resourceful. They pursue leadership roles on the team and can mentor novices. However, competent devs still lack the experience to prioritize the focus of their attention while working on the project, and they are barely able to reflect on their mistakes.
In terms of the seven stages of expertise, we can consider the middle developer a Journeyman. They work on honing their skills and enhancing productivity. Journeymen are competent enough to be the source of Software-Engineering advice.
Middle technical skillset and duties
IDE. After using IDEs for quite a while, a middle dev has memorized the shortcut keys for most frequent operations, really speeding up the work.
API. Intermediate levels have deep and solid knowledge of the main APIs.
Frameworks. Middles are tech-savvy with frameworks which helps them write clearer and shorter code.
Database development. Mid-levels are good at managing databases. They can design normalized DB schemas while taking into account the queries that will be issued. Middle devs are well-versed in using database views, stored procedures, triggers, and user-defined data types (UDT). They are adept in the object-relational mapping technique (ORM) used for converting data between incompatible type systems. In order to speed up the query process, they apply knowledge of index syntax to create custom clustered and non-clustered indexes.
Programming languages. A mid-level developer understands functional programming and knows when and how to apply functional concepts in any language.
Platforms and tools. Middles have already worked with more than four platforms and possess a deep understanding of how the platform functions including code execution. They are very comfortable with their package manager tools.
Day-to-day duties. Mid-level software engineers are not commonly entrusted with highly complicated tasks that may require an in-depth level of engineering knowledge. Meanwhile, they may be tasked with designing a piece of the application to be prepared for the further transition to a senior developer. They are already capable of turning tickets into solutions, providing estimates on tasks, and assisting in decomposing larger sections of work.
Middle teamwork and perspective
Independent work. Mid-levels can deliver work with less supervision while being assigned to relatively routine tasks.
Teamwork. Middles actively collaborate with team members, including designers, business analysts, and architects.
Vision. Middle developers have deepened their understanding of development cycle scenarios which allows them to practice Agile methods more accurately. They see the results of the occurring problems and learn how to avoid them in the future.
A lot of mid-level devs fall under the Dunning-Kruger effect, which hampers their further career growth. This psychological phenomenon describes what a dangerous thing a little knowledge can actually be. Being self-assured, developers may tend to overestimate their skills, which impedes their progress. That said, this condition is a big concern in software development. While this cognitive bias can happen to workers on every seniority level, mids are most vulnerable to it.
As a matter of fact, many engineers cannot picture better methods and practices than the ones they are currently implementing. Programmers that have had a string of unsuccessful projects may yield to the belief that it is usual for a project to be a nightmare.
In the opposite scenario, at some point software engineers may realize how little they know and how much is out there to learn. That is when programmers begin transitioning towards a higher level of seniority.
Graphical illustration of the Dunning-Kruger effect on developers depending on their seniority and knowledge. Image