Tuesday, August 05, 2014

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.

No comments:

Post a Comment

Do not spam this blog! Google and Yahoo DO NOT follow comment links for SEO. If you post an unrelated link advertising a company or service, you will be reported immediately for spam and your link deleted within 30 minutes. If you want to sponsor a post, please let us know by reaching out to duane dot nickull at gmail dot com.