Andy Crouch - Code, Technology & Obfuscation ...

The True Cost Of Junior Developers

Photo: Unsplash - Free To Use Sounds

Not long ago I wrote about developer labelling. One of the ongoing things I have been thinking about is the cost of promoting junior developers. In the case of this article, I am referring to developers in their first or second programming role.

There is a cost with junior developers that you do not immediately appreciate. When you hire them you undertake to invest in training and in time.

Investing in training is an obvious win/win situation. You support the developer to learn and develop professionally. You also ensure that they have the skills and knowledge they need to be proficient for your company. You want good clean code developed to your expected standard. You also want your developer’s coding confidently. You don’t want them spending excessive hours on Google or Stack Overflow looking for solutions. As an unexpected bonus, I have discovered a positive side effect of training juniors. They share their newfound knowledge through conversation and at stand ups. This knowledge sharing can reaffirm other developers knowledge. It can also trigger conversations about improvements and standards within the team.

The total time invested is a cost that you may not appreciate at first. When a junior joins your team they will take time to get up and running. They will need support from the more senior team members. This means that those more senior team members are less productive. The junior developer’s own productivity will increase over time as their knowledge grows. Planning and estimating has to be adjusted for the junior’s capabilities. This all results in financial cost.

The benefits of hiring a junior developer on a lower salary can be offset both financially and in productivity.

So why when they ask for a pay rise, do we say no.

At some point, after the first couple of years, the junior developer becomes an established developer on your team. They know the product well. They have developed their skills and their productivity is high. They are clearly an experienced resource. They sit in a review and you give great feedback and then they ask for a pay rise. You have no room to pay the kind of increase they ask for or deserve. You haven’t budgeted for this. The company can not afford or does not agree with giving large pay rises. Three months later the developer has left for a company that will hire them at the salary they deserve. Demand is high for developers don’t forget, there are not enough of us.

On average at present, if you hire a junior developer, you will pay around £10k less a year than a mid-level developer. So when you have to replace your developer for a new junior you are going to incur costs such as:

  • Unless you work for a large company, you or one of your team will sacrifice time to go through a hiring round to fill the role.

  • A recruiter fee. If you are lucky enough to get 15% rates then this could be between £2.5k and £4.5k. (If you are not getting 15% rates at this level then you need to work on your recruiter relationships.)

  • You will invest in training.

  • You will invest your senior teams time in on-boarding the new junior and supporting their learning of your codebase.

  • You will lose productivity in the team as you return to having a less productive resource.

If you could and did sit down and calculate the monetary value of the points above I suspect you’d be surprised at the cost. As a leader, I would sit back and weigh up if this cycle is cost-effective against a £10k raise.

There is a flip side to this argument. As a junior developer at the start of my career, I could see the number of roles reduce if all teams did consider the arguments above. I would also argue that as a more junior developer, working for many types of company and across many projects is beneficial to your career. So it might be that even if your current role does offer you the money you deserve as you progress your career, you should still move on.

Like my previous article on developer labelling, this is really just a brain dump of thoughts. If you would like to discuss or have thoughts around this them please contact me via twitter or email.