TL;DR

Hire the behaviours, train the technical skills

It’s all arbitrary and entirely dependent on what you need from a ‘Senior Developer’. That said, my experience has shown me that – to me – being a Senior Developer is mainly about behaviours. Sure, technical ability is a significant part of that, but for the day-to-day, being able to cover 80% of technical challenges is enough if the other behaviours are strong. Ultimately if I encounter a developer who demonstrates consistent, reliable delivery and behaviours aligning with those demanded of a senior in that context then I will do all that I can to help them gain promotion to that level, regardless of the number of years or hours or whatever. This is almost always going to produce far, far, more preferable outcomes than the inverse situation of little in the way of senior behaviours but with expert level programming knowledge which I have frequently encountered in senior engineers… usually the result of left-brained managers hiring based primarily on experience. The 10,000 hour rubric isn’t even worth mentioning; it’s irrelevant. 

Years and years… and… years? 

Developers are senior after 7 years’ experience. It’s that simple. Nothing else to it. At least that is what many in the industry would seem to believe. Or is it 6 years? I’m sure I’ve worked places where its assumed to be a 5 year threshold and I know there are many developers with 10-20+ years of experience but still working as ‘Senior Developers’. Does this mean all the Senior Developers of 5 years’ experience are performing at the same level as those of say 25 years? I assume we all agree that the only answer here is ‘it depends’.

I brought backup

I’m not the only one here who feels this way. Parul Singh – an established and very strong voice in the UK North West tech scene, championing diversity and inclusion – very recently vented the same frustrations:

Stop putting arbitrary numbers in front of requirements for the sake of it. It means nothing.

Please read Parul’s full post here and give her a follow for great insights on diversity in hiring: https://www.linkedin.com/posts/thecodingrecruiter1_i-tend-to-browse-javascript-roles-on-linkedin-activity-6952926844253835264-WKVb

I wholeheartedly agree with Parul. As far as I can tell the number of years is actually meaningless. Maybe there is value in excluding the bottom quartile of outliers during CV screening by applying a strict bottom end of i.e. 3 years but who on earth is getting enough CVs through for Senior Developer positions for this to be worthwhile? You could be missing gold! Don’t believe me? Read on… and if you still aren’t convinced by the end then shout at me in the comments. 

Applying the 10,000 hour rule  

I’ve seen the “10,000 hour rule” being used to measure the Seniority of engineers in a few places and its never sat right. I understand as I’m sure we all do that this rule dictates that it takes 10,000 hours of practice to become an expert in anything. The rule has been around a while – nearly 30 years in fact – but it’s likely not what you think. I’ll go into further detail around the specifics of this “rule” in a moment but suffice it to say that it was not much more than an interesting data point from a study by K Anders Ericsson on the relationship of practice and performance in musicians. This data point was then and continues to be horridly misreported, as is the case with so much useful science, and blown out of proportion. You can read a report by the original study author on this misreporting and it’s dangers here (it’s well worth a read!): 

https://radicalscholarship.com/2014/11/03/guest-post-the-danger-of-delegating-education-to-journalists-k-anders-ericsson/

Why not to let the media educate on science

The 10,000 hour rule would imply that anyone working in the UK under normal working hours of 37.5 hours per week with 30 days annual leave (including Bank Holidays) should be required to work 6 years in their field to become Senior.  

Given 252 working days, 25 days holiday @ 7.5 hours per day: 

10000 / ((252 – 25) * 7.5) 

= 5.9 

We need to be careful in using this reference to 10,000 hours for a number of reasons: 

1. The 10,000 hours from the original study refers to time spent on a single, specific task, namely playing a musical instrument. A Senior Software Engineer or Senior Software Developer does not simply churn out code day-in and day-out. Indeed most teams would tell you that the more ‘Senior’ a developer becomes, the less direct coding they are involved in, instead spending increasing amounts of time implementing process, engaging with wider business stakeholders and mentoring less experienced co-workers. 
2. The original study did not intend to suggest that 10,000 hours was some sort of magic number that someone can commit to for success, rather it was an average for specific groups in the study. Many of the most successful musicians had attained far fewer hours and many other factors from height, genetic disposition of motivation and environmental were considered. In short the 10,000 hours number was an interesting number to report on, in part because it is such a huge amount of effort! 
3. The Civil Aviation Authority in the UK requires *only* 1500 hours for someone to be awarded the licence required to pilot commercial passenger aircraft (https://www.caa.co.uk/commercial-industry/pilot-licences/aeroplanes/airline-transport-pilot-licence-for-aeroplanes/#:~:text=Of%20the%201500%20hours%20of,be%20completed%20in%20an%20FNPT). Using the same parameters as before this would mean that someone would need to fly for less than a year, full-time to be considered experienced enough to pilot passenger aircraft in the UK. Some data points indicate that commercial airlines expect at least double the amount of hours for candidates to be appointed to pilot positions, but this is still 1/3 of the effort touted by the 10,000-rule brigade. 

So… where does that leave us? 

I have been fortunate enough to work with people who are able to build up the appropriate behaviours and skills for seniority in just a few years – this has convinced me that it may well be possible to do this even more rapidly. Some people just have it naturally. I for one do not have any such natural gift and I constantly need to work on reckless tendencies and forethought. I honestly do not feel I was near a senior level of behaviour until after 10 years of constant experience. 

Even when we get to the technical expertise expected of a senior team member it becomes so broad as to render the abstract concept of time-spent as meaningless. Even throughput metrics are at best flaky; I find that the more senior engineers often deliver code at a slower rate. This is expected however due to other growing commitments outside of actual coding, but also down to time taken to mentor more junior team members as they go. Add to this the added responsibilities of ensuring that delivery is completed to standard and all non-functional requirements such as performance, observability, tolerance and so on are being met and its’ not long before the act of ‘development’ becomes a sliver of the overall skillset. 

So what to do? Well the most effective means I have seen of ensuring you are nurturing people through the ranks in seniority is to identity the roles and functions each team member performs on your team and align those to seniority levels. I doubt your juniors are responsible for designing cloud architectures, though they may be involved, so there would be one senior level responsibility “Takes accountability for cloud architecture design decisions”. You’ll likely find your senior engineers are also the team members that are always finding simple paths through messy problems and there you have “Can be relied upon to find the simple solution to messy problems”. Plot these into a roles/responsibilities matrix and then these can be measured against to gauge each team member’s contributions to the team and calibrate them within seniority bands as fits for your business. See the RACI model for an example model for building your own: https://scalac.io/blog/software-in-a-team-software-development-team-roles-and-matrix-raci/ 

If you still desperately need a strict rubric to decide the future of other human beings then – speak to a therapist! Really, the only currency that talks in seniority is the ability to apply knowledge gained from experience. It’s entirely possible that you are interviewing a candidate that has experienced and learned in just one year from all of the necessary key situations that make them a perfect senior in your team. If you are not at least considering this then you could well be missing your team benefiting from the next CEO of Oracle and you are almost certainly harming your diversity efforts. I have sadly seen too often teams who are unable to keep up with seemingly naturally gifted developers and they inevitably move on to greater challenges and the only losers in that situation are the team that let them get away. Don’t be that team!