Siren songs
If you want to get junior developers up-to-speed within 18-24 months, teach them skills.
If you want to do it within 3 months or less, teach them habits to help them manage cognitive load.
Let’s look at a common source of conitive load that causes junior developers to get stuck: distractions.
The developer is in the middle of fixing a bug or implementing a feature, when they think, “Hmm, this code is kind of hacky; I should refactor it to make it cleaner.1” So they switch into refactoring mode and start rewriting, but then they bump into an unfinished part and have to switch back into solutioning mode.
This goes back and forth a few times, with the developer continually context-switching between refactoring and solutioning. Before long, they have a Frankenstein’s monster of half-implemented ideas, everything grinds to a halt, and the developer is well and truly stuck.
Our hypothetical developer isn’t lacking a technical skill. There isn’t a principle or pattern they can be taught to help them avoid this situation — they may even be able to cite solid reasons2 why the refactor is necessary.
The real issue is that the refactor is a distraction, and the developer hasn’t yet learned how to manage these distractions.
Unfortunately, the advice most developers receive about managing distractions is, “ignore them”, but this won’t work either.
Distractions are like kittens: they won’t tolerate being ignored for long
The trick (and where the metaphor hopefully breaks down) is to have a system for funnelling them into a holding area, so that you can deal with them later.
Here are some ways I teach junior developers good habits for wrangling all those fusspot distractions.
Ugly code that works first, then pretty code that works
New developers don’t understand the difference between coding and refactoring — and critically, they don’t understand that there’s a context switch that occurs when flipping between the two. During pair programming, help them identify when they unconsciously switch from coding mode to refactoring mode, and then to switch back before they lose focus on their original goal.
Construct a parking lot
As developers work, they will naturally identify issues and inefficiencies in the surrounding code. This is a good thing — it’s how a lot of teams discover the majority of their technical debt, after all. So, you don’t want your developers to disregard these discoveries, but you also want them to avoid getting diverted into rabbit holes.
To strike that balance, work with each developer to design and create their own parking lot. When they discover an issue in the code that would potentially distract them, they can stuff it into their parking lot, to be dealt with once they’ve freed up some headspace.
Experiment to find the system that works best for each developer. Some examples that I’ve found work well include:
A separate text file, Notion page, etc.
Adding stub cards to the product backlog.
Adding warning comments (
TODO,FIXME, etc.) to the code where issues are found.3Writing in a physical notebook or on sticky notes.
We’ll go over how to follow-up on the items in the parking lot in a moment, but first….
Commit after every win
Once the developer has a working solution – no matter how ugly – get them in the habit of committing their changes before attempting any refactoring.
This is useful for avoiding cross-contamination, but it’s also important for keeping that cognitive load at a manageable level. Until the changes are committed, the developer has to maintain a “mental snapshot” of their work, so that they can undo further changes in case they break something during their refactoring.
With practice, developers can build up their capacity to maintain these mental snapshots (to an extent), but especially for new developers it can be extremely taxing. Teach them instead to “page out to git”, so that they can free up mental RAM for the next operation.
Getting back to that parking lot…
After solving the original problem and committing changes to version control, the developer is now ready to go back and follow up on the issues they stuffed into their parking lot.
Some of the issues will be small or straightforward enough that they can be addressed right away (don’t forget to commit after every win!). Others will need to be added to the product backlog as technical debt.
Keep moving forward
In my experience, the biggest factor keeping junior developers from being productive is rarely lack of technical knowledge. Rather, where they tend to run into trouble is not having built up habits to manage cognitive load and free up that mental capacity to apply to technical challenges.
Teach your developers good habits for recognising and managing distractions, and leveraging git as virtual mental RAM, and you’ll start seeing their productivity gains compound.
“I bet I can apply (read: force in) this design pattern I just learned about!”
Or perhaps SOLID reasons.
If you go this route, be sure to turn on no-warning-comments, fixmes, etc. in your linter, to ensure these comments get cleaned up later.