Naming software developer roles

Junior Developer. Senior Engineer.

It’s funny that we use these terms, usually reserved for age, to refer to the level of responsibility and pay given to a software developer.

But clearly, age isn’t what we’re measuring. There are 24-year-olds who have packed in enough experience to be classified as “senior”. There are 40-year-olds who I would only employ in a “junior” role: they’ve had one year of experience 20 times, and one not particularly relevant experience to the role I’m advertising either.

What’s more, in an effort to make people feel appreciated, average developers with three years’ experience are being called “senior” at many dev shops in my home town.

With this kind of title inflation, the terms have been completely worthless. “Junior” has become a pejorative, and in some ways fairly so. Who wants to be junior? What if you bring value from experience in another profession?

A better way to name software developers

We could just get rid of titles entirely, and I think for some companies that’s a good idea. But it is useful to be able to put a line in the sand to say where a developer is “at” in their career progression, both so they know where they should head next, and also to set pay at a standard scale across the team.

I’d like to suggest a system we implemented at Powershop: using the colour spectrum.

From infrared to ultraviolet

It’s pretty simple, actually. At the very start of your career, you’re an infrared software developer. The lead developers that are at the top of their technical game are ultraviolet.

Colours are a nice system since they don’t hold any intrinsic meaning in themselves, yet they fall nicely on a scale — in the same order that they appear in a rainbow. If you’re geeky you can even refer to them by their wavelength in nanometres.

Here’s a rundown of key stages in a developer’s career and how they match with the spectrum, in my mind.

Infrared: the starting developer

It all starts here. You need reasonably close supervision as you ship your new code, but you can handle simple tasks by yourself once you’ve done them a few times. There’s so much to learn! But you’re learning fast.

Red: trusted with small tasks

You’ve reached red when your team trusts you to take a small task (around half a day’s work) from the backlog, understand the consequences of implementing it, and do a solid job writing it up.

Orange: trusted with tasks

You’ve got a good base knowledge for architecting changes, so your team trusts you to work on a change for a few days, perhaps with your peers, and deliver the right solution. You can talk with non-technical people to understand their requirements.

Yellow: understands business context

You can work with non-technical people to decide on the required features of a small project, and work with your team to deliver those features. You’re using appropriate patterns in your code and thinking about its longevity.

Green: leads small projects

You can run a team of developers working on small projects, making solid decisions about code architecture. You can fluently interact with non-technical people and communicate back with them your progress in a way that exposes requirements they have that they have trouble articulating. You’ve got a good grasp on code quality practices which you articulate with your team.

Cyan: leads projects

You’re really comfortable with the delivery lifecycle, having done it a few times, so you can lead a small team to successfully deliver a three month project. You’re experienced with architecture, both infrastructure and code structure, and the decisions you make mean the code that your team writes is easy to maintain into the future. You spend a fair amount of time mentoring other developers.

Blue: oversees projects

You have deep technical skills in a range of areas. You support multiple projects across the organisation, and understand business consequences to new changes. You spend roughly equal amounts of time discussing product features and designs, mentoring other developers, and working on code yourself. You look three months ahead into the future to ensure the right features are worked on. You participate in the recruiting process to ensure the right devs are coming on board.

Violet: oversees systems

You’re ultimately responsible for the health of your codebase. You spend time talking about the architecture with other developers across multiple teams, and provide a guiding hand to ensure the work that’s been done is fit for spec. You have a deep understanding of the business domain and are present during high-level product decisions to provide the technical voice of the organisation. You’re an integral part of the developer recruiting process. You look a year ahead into the future to ensure the right features are worked on, and are a strong proponent to get budget from management for your codebase’s maintenance and infrastructure. You do some code spikes, but most of your time is spent supporting the developers in your teams.

Ultraviolet: runs technology

You’re the technical head of a very complex and large product. You don’t have the time to cut much code, because you’re involved in high-level product discussions, architecture review, mentoring, and planning the technology roadmap for your company for the next three years. You work closely with the product teams to ensure the right thing is being built. You spend much of your time thinking strategically regarding recruitment, training programmes, maintenance teams, infrastructure, and making your workplace an attractive place to work.

If you adopt the colour spectrum system for your company, I’d love to hear how it went. Send me a note at @mogest on Twitter.