OK, I'll admit it straightaway... the title is misleading. But it got you here, didn't it? Then it worked! Let's get started...
Lately I've been marinating on the concept of experience, and more specifically, what the value of experience is and what are the most effective ways of gaining more of it.
At my work I have the privilege of collaborating with both seasoned developers and incredibly smart, but much newer entrants to the field of programming.
A common tendency I've observed of green engineers (as well as their managers) is the pursuit of "getting up to speed" or becoming "productive" as soon as possible.
In this post I want to look over a few things I've found helpful as we spur growth on our team. Before we start, a word of caution: Rushing the growth process, or shortcutting the natural acquisition of experience, has the potential of causing harm that will only extend the timeline.
TLDR:
Robbing developers of the chance to level up their own experience journey does more harm than good. Rather, we must recognize that the very process of failing and succeeding is what moves junior team members along in a healthy growth pattern.
To that end I've identified a few concepts that I fall back on as I work with our team. Maybe they will help you too!
1. Principles Guide Practice
When confronted with a problem a junior engineer tends to do a couple things. They either fall back on what they've already learned and try to fix the issue using those skills... think the adage "when your only tool is a hammer, everything looks like a nail".
Or they end up so far in the weeds they lose sight of what the actual problem is. In other words, they are attempting to solve the problem at the wrong level.
To combat this I encourage them to shed off peripheral details and try their best to isolate the root of the problem. Figure out what is causing the problem before attempting to solve the symptoms.
2. Ignore the Fads
In our present tutorial-based learning environment people are spoon-fed methodology and rote prescription for how to accomplish things. My career started off by consuming videos and blog articles which led to the implementation of all sorts of patterns in my code. Look back over the projects I've worked on you'll see when I was learning about repositories, or GraphQL, or SPAs. The code is a result of what I was learning at the time.
As a result, I am now encouraging our devs to choose the most basic, simplest path. I don't recommend that because they aren't capable of implementing more robust solutions, but because the shine of the latest and fanciest has worn off. Tried and true methods of programming will still be trustworthy after the fads pass.
However, sometimes I will let a programmer travel down a particular path of their choosing. But I'll only do that in cases where the level of risk is low enough to accommodate potential failure. Speaking of which...
3. Allow Others to Fail (appropriately)
Failure can be an excellent teacher, but only if you allow it to be. Learning from failures is perhaps the best trait a programmer can possess, and the inverse is true as well. Not learning from failure is a terrible trait and should be called out.
I will never forget to make a uuid column unique again. Want to know why? Because once I did and it caused a whole lot of problems. Yes, I had that pit-of-my-stomach feeling when I realized what I had done, and I make sure to avoid having it again, at least in relation to unique uuid columns.
Insulating your team from all potential failure only defers the responsibility up the chain and your leads can't own the responsibility that belongs to team members.
Allow your juniors to program themselves into a corner. Then, help them see why that approach may not be the best option and guide them towards a better one.
4. Give Consideration to Gut Instinct
Earlier in my career I gave in to self-doubt more than I should. Because I didn't know a particular pattern or syntax I would back off and rely on someone else to lead. What my more recent years have taught me is that, though intangible, experience is just as important as syntax (perhaps even more).
Because of this I continue to encourage our programmers to listen to what their gut is telling them. If they are sensing that a particular approach would be more appropriate than the one a lead suggested, then I encourage them to communicate, or at least be able to take that gut instinct and tease it out. Why are you feeling this way? What other things do you think we should consider?
5. Know When to Abandon Ship
This last one is an interesting idea that becomes clearer the more you live through it.
Let me explain: Tenacity is a common developer trait, and most developers take pride in their work. This combination can make us hang on to the wrong idea, direction, project, or technique much longer than is healthy.
Pay attention to the times it seems like you are jumping through every hoop to sustain an effort when perhaps a better solution would be to scrap it all together and start fresh.
In many ways this is a microcosm of experience itself. Try something... it doesn't go well... bail out... try again with the new understanding of what didn't work last time.
In Conclusion
For the health of your team, please don't try to shortcut the experience trajectory. Instead channel them towards the ideas above and watch them blossom into productive team members who push your organization forward.