Disclaimer to my junior readers

Fist of all, we love you, we need you and we welcome you!

This article is not to scare you, and is intended for project managers, business teams to better evaluate their hiring choices. There will be examples where the cost optimization at start meant big losses on mid and long term.

In none of those examples, I believe, was the inexperienced developers at fault; they are cautionary tales for every one of us.

Being junior is literally not having enough experience yet. You can be junior, in my opinion, in an unfamiliar language when you learn new stuff.

There will be a section on what I think is an ideal environment for a junior developer.

Are junior developers cheap?

In my experience junior developers are mostly humble, hard-working folks. Some even can be more productive when they freshly learned the NEW TECH and they introduce it to older devs on the team.

However, in any company I worked at, there was 1 very expensive mistake repeatedly made:

They left junior devs alone on internal (and sometimes actual product) tasks.

In companies or teams where the budget is tight, from the business there is a great temptation to just "put a cheap junior on it" because "what's the big difference anyways?".

Real examples here:

• a company got acquired, turned out the entire codebase was only 10 (very long) PHP files; half a year later a rewrite in C# started, but with so many edge-cases covered and expected by users it still required PHP developers to be hired 4 years later.

• an internal application tracking shift working and time offs was developed by a jolly but quite inexperienced junior developer who was transitioning from another job. 7 years later, every time you wanted to take time-off, you had to ask somebody how to make sure the UI actually registers your vacation request. Shifts sometimes also got swallowed by the same glitch, that had to be covered by additional manual work.

• mobile application and questionnaire creator application built by a couple of juniors who did their best. Took us 3 years to finally replace them with a manageable, understandable solution. Changes are quite hard when you already have an existing user-base and external dependencies on your real world data.

I hope these examples show that lack of expertise can be quite expensive on mid and long-run, therefore I don't recommend optimizing for "developer cost" until products are mature enough.

What environment to seek as a junior?

• first of all: a constructive environment: your code and decisions should be reviewed, the reviews are respectful, constructive, asking you questions to think about, and recommending more effective ways to handle a problem
• psychological safety: no bullying, everyone understands that you are on your way to be great, people around you want you to grow; code reviews should never be stressful, they are not exams, they are people helping each other for the greater good
• open doors: not yet there but curious? They should let you in on how product meetings go (unless you work in the defence industry and we talk about top-secret stuff :D)
• let you take on features alone: it sounds contradicting to what I just wrote, but in reality, the best teacher is to write something end-to-end. Of course you should be able to ask questions and get a decent review on it, but responsibility and decision making are very important to transition to the next level.

Code reviews should never be stressful, they are not exams, they are people helping each other for the greater good.

Are seniors expensive?

Yes, and no. They can be very expensive under the wrong circumstances and quite cheap with the right ones.

The right circumstances

According to me, these are the right circumstances for a senior developer:

• ability to discuss product and tech decision with managers as peers
• autonomy on day-to-day work
• early involvement with product ideas: they saw a lot of projects from start to finish, they can help you avoid unnecessary costs, they might recommend you specific options/teams/method to get there
• ability to make decisions and research: many times
• trust them but ask them to reason about those changes
• let them manage their own time: I expect senior devs to know at what times they are the most productive; they can be early birds, late-nighters and everything in between.

The wrong circumstances

• not to challenge them on any decision: one of the products I worked on decided to go with Elm; a then mostly unknown language; it was clearly not ready to go near production (I still remember the sentence "Hey, where's internationalization for the project?" "Wait, I'm writing the first library for it.")
• micromanagement: telling them what enum to expand specifically; maybe they recommend a more future-proof solution that you never guessed
• making them change programming languages/platforms too frequently: no-one is senior in a new field. Yes, they learn much faster as they know what to look for, but every piece of tech has a couple of very special, little surprises that cannot be known. Factor in a year, better two, for any dev to make reasonable decisions or code a new language/platform.
• giving them or forcing them to use dumbed down options: if someone is a SQL black belt, telling them to "only use the ORM please" might be quite stressful.

My advice

If you can afford, start a new project with a couple of senior devs to build out, scrap, rebuild and land on a nice stem project where there is already enough best practices that juniors can easily add a ton of value.