A Mentoring Case Study in Chaos
We’ve all met significant problems. They manifest each and every codebase and business that engages in software development.
Go on. Name your difficulty.
Horrifyingly bad codebases
A deeply broken project
A code review process which only exists to make you suffer
A convoluted setup process that leaves you with a half-usable machine
We’ve all got the war stories about those things. Other times we have a significant problem that is rather more human in nature.
It’s a junior developer who has been entrusted with your guidance and wisdom.
This isn’t an article hating on junior developers as we’ve all been there at one time or another. This is an article about the truth of the matter, that junior developers can be problem generators and get themselves into rather entertaining messes.
Chaos
As developers we might be satisfied when a compiler spits out nonsense errors and we can use our skill to solve the problem.
It’s a little more tricky when you have some ownership over junior developers who produce creative interpretations of best practices, architecture and even basic syntax. Not that they mean to, but in their attempt to follow instructions they can end up creating something that while technically functional is horrifying to a more experienced coder.
The Junior Developer Experience
Take, for instance, a past experience of mine.
We had an onboarding process where each new developer needed to create a new component and push it into the codebase, going through the PR process right up to (and excluding) merging the request.
A button, with a specific color. The idea is that it is an easy win, and builds confidence.
It didn’t go well.
The junior couldn’t set up their machine for 5 days
They managed to get a merge conflict on their own branch (I still don’t know how this happened TBH)
Rewrote how the component should work, instead of using the usual method we would use
Created a heartfelt but completely unnecessary README update explaining their ‘vision’ for the future of UI design
They didn’t ask for help and seemed to expect us to orbit them, checking everything from our end. That… didn’t work.
Why it’s Good that Junior Developers Create Bugs
Juniors make mistakes because they don’t know what should, and what shouldn’t be done. The best developers I know aren’t the ones who know everything, but they know what to avoid doing.
So every time a junior creates a bug, breaks a build or makes a refactor into a worse mess than it ever was they are learning. It’s their own personal record of what not to do, which is exactly what they should be doing.
Turning Bugs into Features
So what do you do when your junior developer has just taken what should have been a five-minute fix and turned it into a multi-day debugging session?
Resist the urge to scream
Seriously. Take a deep breath. Count to ten. Walk away if necessary. Don’t let the junior developer see how disappointed you are, it will impact their confidence and perhaps make their work worse!
Ask questions instead of giving orders
If you are genuinely curious about someone else’s work you are more likely to get to the heart of what really happened, whether or not something has gone wrong.
Telling someone that
“This is wrong”
is likely to make them feel defensive. An accusatory question
“Why did you do it this way?”
Doesn’t have the curiosity that might elicit a genuine answer.
Rather you should develop a relationship and talk about the situation, and the junior’s contribution to the existing code. You build a bridge to the other person and develop space with them to work out what happened and understand how things might be done for the best.
Encourage failure
We have all heard the mantra move fast and break things. Yet doing so in the wrong environment can be fatal. It is up to senior developers and the organization to create a safe environment where mistakes are embraced and learning encouraged.
Maybe don’t let new coders push directly to production on day one.
Debugging before syntax
The ability to find and fix your own mistakes is more important than perfect code on the first try. This is a cultural norm and something designed to encourage personal development and improvement within an organization.
Much like producing a style guide it is well worth developing a set of cultural norms to help people know where they stand, and how to be successful in a given environment
Conclusion
Here’s the irony. The juniors who cause the most problems today often become the best developers tomorrow. Why? Because they’re the ones who care enough to experiment, to try, and yes, to fail.
And if you mentor them well, one day you’ll look at them and realize they’re no longer your significant problem. They’ve become your significant success.