Senior vs. Junior Programmer (Developer) Definition

We have been asked many times to define the differences between Senior and Junior programmers. While there is no exact answer, this blog post attempts to clarify what we look for when hiring developers at different levels.

The labels “Senior” and “Junior” are difficult to comprehend as they can sometimes be bestowed on the same developer depending upon the context of assessment. A developer may be considered “senior” with respect to the .NET development platform while at the same time be considered “junior” at HTML5 and some of the more recent related technologies. Experience clearly plays an important role in working with multiple technologies as well. Developers who may intrinsically understand the internal nuances of a complex platform like J2EE may be lacking the full practical experience that only comes from using multiple versions of the language and migrating from one to another. In some cases, a developer who is knowledgeable about topics in great depth may actually lack the full breadth of experience. This latter experience augments the deep knowledge of more specific facets since the entire evolution of one part of that language may be a reaction to a shortfall or persistent problem a previous version had. Such context-specific assessments require those who assess developers to remain somewhat flexible in their own judgments concerning experience vs theoretical knowledge. Both help a developer get the whole picture of each language or platform.

Of course, the differences could be explained with a bit of humor. The following diagram helps non-developers understand the differences in mind-sets between the two groups.

To begin to place some formal constraints around the differences, the descriptions can be summarized as follows:

Junior developers are still acquiring many of the skills their senior counterparts possess. The reality is that the senior programmers only achieve the extra skills through experience and perseverance. Many of the skills cannot be taught in a classroom as real life experience is required to guide the developers knowledge bases. Junior programmers are often given tasks to do, but are seldom handed projects. A task takes no longer than a couple of weeks overall and often is not delivered as a customer-ready deliverable. The junior programmers often do not gather requirements and in many cases are not provided the details of “why” they are doing a certain task. They typically do not talk to customers or if they do, the interactions are often very limited. A junior programmer will not feel comfortable training other developers nor will they lead teams. They often need reviews from senior developers. On version control systems, an administrator will not provide the credentials or bestow the rights to “destroy” code or projects and are not permitted to over-write the work of others. They typically dream of working on bigger projects and are well situated to handling smaller tasks but cannot provide customer-ready solutions to business problems.

By contrast, a senior developer is given projects to do as opposed to tasks. Some projects can last up to 6 months and require the senior developer to gather requirements. They often will be part of the team that talks to customers directly and will develop “solutions” to those problems and explain their ideas to the customer. Senior programmers tutor juniors and provide paths for juniors to keep acquiring new knowledge. A senior developer will usually have “destroy” rights on version control systems and uses them to help others learn the errors of their ways. The senior developer dreams of designing, not coding but hacks all the time.

The following chart outlines some other fundamental differences we typically use to delineate a senior programmer from their junior counterparts.

Task	Junior	Senior
Codes up a given library	Yes, task does not require knowledge of entire application.  When given the task, the API will be constrained and specified.  All work will be to ensure the library works as intended.	Yes but can also engineer the library. This means defining the API and parameter list, understand what classes or libraries may call it and how it has to be architected (static classes?  Prototypes with concrete classes inheriting?  Method signatures?)
Understands the method signatures	No – is only proved with the specification and the API signature.	Yes, additionally, the senior developer can architect the class to accept multiple parameters and figures out the correct order, data types and tests.
UML	Junior Developers are not required to interpret UML of an entire system	Senior developer must understand the system architecture.  In addition to the class function, needs to understand the class relationships and methods. Typically uses class new diagrams, sequence diagrams and use case diagrams as well as other similar artifacts.
Class methods	Juniors usually scope everything to private.	Can determine how to mutate the access modifier to public, private, protected etc. based on class use and function. Understands the rationale behind the decisions.
Knows when to develop simple API’s vs complete web services	No	Yes
Data types	Does not understand which data type to use if not told.  Does not differentiate big endian vs. little endian types.	Can study a system and determine which data types are optimal for each API call.
Multi-thread experience	Basic – understands the concepts.	Advanced – uses keywords like “volatile” to denote variable uses when multiple threads may be trying to mutate values concurrently and knows how to mitigate these scenarios.
Multi-thread experience	Does not understand thread controllers	Uses thread controllers to ensure optimal operations for all class instances. Can take advantage of multi-core processors.
Abstract vs Concrete	Basic knowledge, often tries to implement abstract classes resulting in errors.	Understands when to prescribe abstract classes as prototypes and how to create concrete classes that may be instantiated based on the abstract classes.
Naming conventions	Basic	Ensures consistent naming conventions are used throughout a project.  Will flag the project if it is apparent that no one else has specified this vs the Jr. Developer who will not see the need.
Unit Testing	Has some UT skills.  Occasionally writes test is not too busy.	Uses Test-driven development and is a strict user of unit testing to ensure code can survive a code audit.
Frameworks	Has experience on one or two	Can decide which framework/version to use based on functional requirements.  Knows how each one performs, where strengths/weaknesses are in each framework
Localization	No – often hard codes values and binds them to buttons, frames etc	Yes – knows that any long lasting system requires localization and knows it is easier to do it once at the beginning of the project than trying to reverse engineer it in later.
Architecture	Can understand some drawing/specifications but needs to have a source of knowledge to ask questions	Reads UML like their native spoken language.  Comfortable interpreting UML into code.
Architecture process	Codes first to get a head start. Can only be given tasks and not projects	Does architecture first properly to ensure the system will work as required.  Can be given entire projects and will write any missing architecture docs to ensure others have documentation.
Documentation	Does not write	Knows it must be written and ensures it is done along the way.
Durability	Writes code.	Writes code to be maintainable over time.
Problems	Brings problems to Sr. programmers	Finds solutions to problems
Estimates	Guesses.  Cannot envision all code in their head without writing some so cannot be accurate in estimates.  When given, estimates are often provided in < 1 hour	Can estimate a complete project, Designs complete code in mind before starting to code in order to provide a realistic estimate.  Estimates take at least one week and asks many questions to ensure complete understanding of requirements.
Motivation	Needs to be motivated	Knows how to motivate other coders to complete the project and produce quality code.
Vision	Only sees what is in front of eyes	Can foresee problems others do not yet see and knows the best ways to eliminate them.  This work is often unrewarded as the product owner often thinks the problem never was, does not appreciate the Sr. Coders work in avoiding it all together.
Coding	Thinks users will only use the software as intended.  Writes code, discovers problems, fixes code, repeats multiple times.	Knows users will abuse the software and use it for other things.  Ensures components will gracefully fail without bringing down the entire system. Eliminates points of failure.
Knowledge	Asks “what is the difference between junior and senior developers?”, assumes they are senior and forges ahead in the wrong direction.  Naïve and optimistic.	Knows the difference but does not rub in in others faces.  Tries to help junior programmers. Humble.  Has scars from many IT projects.
Optimizations	Will often write code once and deliver it to project code base.	Will try to write code in more than one manner to determine which code runs best and will then optimize it for the solution requirements.