What does a principal developer do?
Or to word it another way, What is a Principal Developer?
I recently got asked this question at an internal (non-technology-based) event with about 50 people in the room. With a mixture of stage fright and not being able to provide a single one-sentence answer, I copped out with “It’s complicated, we do lots of things”.
Some of the alternatives might have been:
Like a developer but a lot better
I can’t argue with this, I am quite awesome. Apart from displaying an unattractive amount of hubris, this is also not true. You won’t get very far in software development if you consider yourself to be aloof to the rest of the developers out there as there are so many intelligent programmers - you can create an Ayende type coding machine role in an ivory tower (not to be confused with a coding machine for out-of-work personal projects of course) - but ultimately the hive mind is a lot more powerful in software development than a single one; and you also make far more mistakes with the solo-coder attitude.
The overlord of the technology department
This isn’t true at my company, aside from the fact I am one of two principal developers, we also have the older-style software Architect role and not a single dictator in charge. In some companies this role distinction wouldn’t make sense, for new companies or companies without a lot of legacy systems, or small companies.
A good software company won’t have a single person responsible in charge, you will have a good mixture of standards and rules coupled with a democracy and a to steal Jay Krep’s definition (principal developer at Linkedin), a mixture of capitalism and communism.
What does your job description say?
The job role description answer to “What do you do?” is “Set standards” and “Engineering best practices”. That’s one line of it though, probably the most important bits of the description are to reduce the cost of change in the department, by promoting engineering best practices which is almost always going to be from making sure we use the latest technologies and tools (because those new technologies come from exactly the same principles a Principal dev strives for - making things easier less time consuming and easier to maintain).
To me the term engineering is a key part to the Principal Developer role versus names like architect and lead developer. You could argue it’s just semantics and quibbling over what is effectively a job title, and that’s true, but in terms of software development architecture and engineering are just the same as the non-software versions.
An architect will design a building, but the engineer will be responsible for the calculations involved in making sure the building doesn’t collapse, it is well built, the right tools are used (but perhaps not the materials).
Please, not more building metaphors for software development…
The problem with these metaphors is we use words that are not-specific to software development. We’ve stolen labels from the building industry and engineering. Perhaps we need to increase our own vocabulary to describe the separation in our job roles, although we do already have quite a few of our own:
- Junior, Mid, Senior developer
- Distinguished developer (a title at Microsoft)
- Scrum master
So after all that babble, what does a principal developer do?
The technical version
I am going to answer the point of this post by directing you to other companies where the role exists, and perhaps the most famous principal developer there is (or was), at least in the .NET world: Eric Lippert.
Eric was the principal developer on the C# compiler and language design team, so concentrating on the C# language rather than the .NET framework as a whole. Anders Hejlsberg took on the .NET framework, with his roles being described as as systems architect. Eric’s role may not know a great deal about what other teams are doing (but probably will often have a good idea, through meetings, bug reports and feature requests), while the other sees all the bits of the puzzle combined together.
In other words, a principal developer is a sort of specialist, an artisan rather than a journeyman. And ultimately I think the role is about how you write code, the tools you use, and working practices you employ to write the software. Keep update to date with the industry and look at the big players for inspiration: Amazon, Microsoft, Google, Github, open source projects; use and update to the cutting edge technologies as early as possible and don’t be afraid to trial the bleeding edge ones too.
And that’s where I leave trying to define a specific role for a company in generic terms. But one last thing…
The non-technical version
“Helps to set department standards and engineering best practices. ” Wait, that’s just one bullet point from about 10 in my job description!