Let Juniors do more

This post aims to show the importance of allowing juniors the time and spce to figure out issues, possibly fail and how to encourage them.


Let your juniours take on tasks that interst them. Dont drive home a fear of difficulty, but instead afford them the time to explore and learn. Help and encourage them when they need it

A team problem

Without going into too much detail, since March of 2020 the team I work on has been working in what most would consider a really unhealthy way, whilst we have achieved a lot it was come at an individual cost, and one such cost is the opportunity for junior team members to get more involved.

Following a recent team meeting about team health / ways of working it was highlighted that the practice of having every team meber on a call "mobbing" on a given problem wasn't an effective use of our time and was causing burn out and other individual issues.

In an effort to change that, the team has started to be more proactive in planning work and writing up tickets for tech debt etc.

We've come into some breathing space and as we explore working individually, we've got the opportunity to solve some "tech debt" issues that have been sticking around.

The Golden ticket

We'd had this piece of tech debt to upgrade the version of dotnet core in a couple of old services we had written. A handful of us had done a little planning around what services needed upgrading and we'd discusssed what was the general points involved in getting a project updated:

  • update version in csproj
  • update NuGet packages
  • fix breaking changes
  • update tests
  • update YAML pipelines

If you've ever upgraded a major version you'll appreciate how hard it can be when the breaking changes lead to significant coding changes.

Having laid out the plans our newest team memeber a junior dev who had joined for a couple weeks to shadow the team had asked if she could give it a go.

Naturally my answer is "Yes, how can I help get you started" (or soemthing like that).

I'd gave her some pointers on how to get going and what was involved and for the most part left her to it.

Now I think it is worth mentioning that her background (from my understanding) was mainly in frontend web development and she'd had next to no experience of C#.

It's important to note, because once she'd wrangled with the csproj files. Upgraded the version, upgraded the NuGet and then followed the Intellisense prompts there were a couple issues left, which were C# in nature like implementing an interface, but having accidentally included a method overload.

We worked through those together and I gave my very worded and possibly rambling explanation as to what those things where, why they'd happened and what to watch out for.

We then fixed up whatever was left and before we pushed our branch for the PR we edited the build pipeline YAML.

The outcome

I hope my collegaue doesn't mind me saying, but I imagine that this was a massive day of learning, a wealth of dotnet and C# bits and pieces like csproje files, the .sln file, the bin folder, dll's etc. (the list really does go on). Git commands to push & create a branch on the remote (and an explanaiton to the hidden .git folder and how Visual Studio, VS Code and the terminal all used to get the current git state) finally topped off with an explanaiton to the build an test process in Azure DevOps and where the Yaml file fitted into all of it.

And the outcome, an upgraded project of course.

A little analysis if I may

So why write a post about this?

Well I think it's important to highlight that just because the job title label's someone as a "junior" it doesn't mean they're any less capable of solving that "really hard" software / computer issue.

To slighlty digress, I recently described the process of gatekeeping being a kin to Ms.Trunchable in the Matilda story. Matilda, who is young and eager to learn all she can is a shining light, but because of her "lack of experience" Ms.Trunchable immediately dismisses her, I particularly recall the line "I was never a child".

And the same applies to software development (hell it applies to anything anyone is ever new to) the juniors are like Matilda, bright individuals keen to learn and full of that "knowledge thirst" but If you micro manage and gate keep their experiences, you'll become like Ms.Trunchable, denying that you were ever a junior as the "years of experience" could your judgement.

And this is what I felt was how we'd become in letting the juniors getting stuck in with coding. We sat them in a corner to observe, without giving them a chance to explore and learn, find and fix and come out the other side with the same level of "self satisfaction" that I imagine most of you get when you solve that issue.

But further to this, you do have to appreciate that junior team members are sometimes fraught with anxiety, impostor syndrome, fear of failure in the code or in the release; in our passing conversation around the Yaml build steps I'd actually uttered "Yah and now that's been deployed" my colleagues response was "What, really? It's been released?".

I explained that it was automated, that the testing was supposed to "fail fast" so we could fix issues as they came about, that in fact we wanted those sorts of things, because at least then we will have captured the issue and would be in a position to fix it before it ended up in production.

Closing remarks

So all in all, let your juniors take on those tasks, if it's something they are interested in let them lead! If they need the time and space to explore and learn as they solve the issue, afford it to them.

Seniority is in many ways a title and not a reflection of one’s capabilities to achieve the end goal.

But if you remeber anything from this post be more like Ms. Honey and NOT Ms. Trunchable!