Defining Development Experience
Friday morning, one of my colleagues asked, “What do you consider to be the difference between a junior, mid-level, and senior developer?”
Being a .NET shop, the obvious answer would be to head over to Scott Hanselman’s blog and pull up this post: What Great .NET Developers Ought To Know (More .NET Interview Questions). Scott has broken out what he considered, at the time, to be the relevant platform- and framework-related knowledge required of a .NET developer at various points in their career.
However, I do not believe that knowledge of a programming language and hosting platform solely defines a great developer, no matter the depth or detail of the knowledge. If a developer is unable to apply that knowledge to a problem domain, it is useless knowledge – a mere parlor trick.
Given a developer has an affinity towards coding and technology, that developer should be able to learn new programming languages, new platforms, and new tools. If a senior developer in a ASP.NET shop moves to a Ruby shop, what would define him or her as a Senior level? Language syntax and idiomatics should only be a small part of the equation.
A Different Perspective
I believe developer levels are determined by a combination of autonomy, mastery, and trust. I have a started a list below. This list is not scientific – it just represents my current viewpoint.
Junior Developers
Autonomy: LOW
- Not self-directed
- Need tasks rather than requirements/user stories
- Tasks are expected to be implemented as defined
- Often under the watchful eye of a senior developer
- May need assistance in finding/deriving appropriate solutions
Mastery: LOW->MEDIUM
- Comfortable with the constructs of their main language/platform
- Basic understanding of object-oriented programming
- May have understanding of architectural design patterns and principles (MVC, Single Responsibility Principle)
- Limited comprehension of problem domain
- Can write basic tests/specifications
Trust: LOW
Mid-Level Developers
Autonomy: MEDIUM
- Self-directed
- Can work from user stories
- Can normally find/derive appropriate solutions
Mastery: MEDIUM
- Comfortable with the constructs of their main language and platform
- Basic understanding of constructs of additional languages or platforms
- Moderate understanding of object-oriented programming
- Basic understanding of functional programming
- Basic understanding of messaging architectures
- Understands several design patterns and principles
- Can write both state and interaction tests/specifications
- Comprehends problem domain
- Committed to continuous learning
Trust: MEDIUM
- Can represent the needs of the development team
- Is respected in the community
Senior Developers
Autonomy: HIGH
- Self-directed
- Can develop user stories
- Can elucidate requirements
- Can generally find, derive, or create appropriate solutions
Mastery: MEDIUM->HIGH
- Comfortable with two or more languages/platforms
- Moderate to high understanding of object-oriented and functional programming
- Moderate to high understanding of messaging
- Can explain design patterns and principles to developers, as well as non-technical staff
- Comprehends problem domain and common domain patterns
- Can write state, interaction, integration tests/specifications
- Committed to continuous learning
Trust: HIGH
- Can represent the needs of the development team
- Can represent the needs of the customer
- Can represent the needs of management
- Is respected in the community
Please note that I do have emphasis on language in each level, but language is dwarfed by the need to understand and communicate the problem domain. Also, mastery of a particular platform is less important than autonomy or trust.
What do you think defines a junior, mid, or senior developer?
Here’s another one:
High level developers are often extremely productive and efficient with the tools they use, i.e. the IDE, the OS, the keyboard etc. They can type fast, they know all the keyboard shortcuts and they know which piece of software will get the best results for any given task. They constantly assess their own efficiency, looking for ways that common tasks can be automated or streamlined. They keep track of software releases and can make informed decisions on whether or not it is worthwhile upgrading a particular package.
Describing in depth knowledge of a framework as a ‘parlor trick’ is misguided. I’m not discounting the rest of your point, but that kind of knowledge of a platform is what keeps developers from implementing code that already exists in the framework.
@cbp I agree. That is a good point.
@Kevin Stevens I agree with your point. Developers should be learning the ins and outs of their chosen platform. I was making the statement that in-depth knowledge in isolation of application is the parlor trick.
I tend to add two things. 1. length of practice. In martial arts, the belt color used to be gained because you didn’t wash your belt. That was to show how much you worked. With music, I often hear 10,000 hours. This can be correlated to number of projects completed if you want. BTW: some of them should be failures.
2. Movement. I want people to move around a bit. Work with multiple teams, different project types, different languages, etc.
I enjoy engaging on this subject, I guess because right now it’s topical (we’re currently in a recruitment cycle, and have been for some time). The subject is just so subjective and what constitutes seniority is multi-faceted.
Ultimately, though, I’m on the same page as you – *what* you might know rates relatively low in my book, if only to offset the general perception that it’s *only* about what you know that’s important. What’s more important is knowing when you don’t know enough, and having the initiative to correct that — that is, IMO what seperates senior from mid-level and junior.
I wonder, is there need for anyone else above this mythical senior programmer that you’ve described? I mean, he can represent the needs of everyone and he finds the solutions without direction. That pretty much makes managers look like seniors that can’t code, doesn’t it?
Sounds to me like the Dreyfus Model ( http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition ) applied to the trade of software development.
BTW, I tend to agree with most of this FWIW.
@Chris Brandsma – I completely disagree with your first point. Practice does not make perfect, perfect practice makes perfect. I have been in the IT field for 5 years and have worked with tons of developers with more experience than me. Most (and I am talking 95 %) of the “more practice” developers, I would still classify as junior developers.
When recruiting for a senior developer, I usually value knowledge of principles and patterns higher than knowledge of any particular framework. I have only ever interviewed one candidate who had even heard of SOLID OO principles. Scary!
Having said this, it’s important that candidates can demonstrate knowledge of the technologies specific to a role or project. I will usually ask questions around .NET language features and concepts rather than specific framework classes. I wouldn’t expect anyone to know every class in the framework. That’s what google is for!
Additionally, I expect candidates to demonstrate their commitment to ongoing improvement, past and present. I often ask what features (language and IDE) were introduced in a particular version of .NET or Visual Studio. People who regularly read blogs by respected members of the community and books on topical subjects rate much higher than those that don’t.
Why you didn’t specify any knowledge of algorithms as part of developer experience?
@algorithm guy I did not purposefully include or exclude any specific computer science or software engineering topic. I wanted to express the things I valued, while giving an opportunity to let others express theirs also. Much like the wording of the agile manifesto: while I value the technical expertise (language syntax, algorithm, etc.), I value these other things more (understanding of problem domain, architectural practices, community involvement, etc.).
That said, I wanted others’ perspectives. So, from your perspective, the depth of knowledge of algorithms is what sets a senior developer apart from a junior developer. That’s great. Thanks for your input.