Esther Schindler on June 3, 2013
At some point, you will hire junior team members. It makes sense to help those newbies become productive and happy as quickly as possible, for your own benefit as well as theirs. Here’s a few practices that may reduce their stress and improve your train-the-new-hire effectiveness.
Businesses have several motivations for hiring new developers. You might blanch at the dearth of qualified expert talent. You might look at the company budget and declare a need to “do more with less.” Or the business may have a commitment to mentoring tech staff, including hiring students right out of college. Whatever the reason, at some point a development team manager has to contemplate the best way to get novice software developers on board as productive team members, without wasting time or talent. In a few sessions given at last week’s O’Reilly Fluent Conference for Web developers, experienced developers shared some of the things they’ve learned about integrating junior developers in a programming project.
First, this shouldn’t be seen as something you do when you’ve exhausted all your “good” options. There are plenty of reasons to go out of your way to seek – and train! – novices from other walks of life. Elise Worthy, a recent graduate of the Hungry Academy program from LivingSocial, made a transition from marketing pro to Rails developer. In her conference session she pointed out several advantages to hiring programming novices, primarily in the realm of functional diversity, wherein people contribute new ideas and background. “When we are different, we think differently,” she says, and that benefits most software projects.
After all, building software is more than writing code. It’s ultimately the process by which we find possible solutions to a complex problem, which involves perspective (understanding the problem) and heuristics (a means of solving it).
Experts tend to share similar perspectives, Worthy points out, and the novices bring new ways of looking at things. A developer who previously worked in customer service can be extremely good at generating user stories, and in understanding customers’ unspoken needs.
But the last thing you should do is dump a junior developer in the corner and make her work out everything on her own. Worthy cited a few points from Daniel Pink’s book, Drive: The Surprising Truth About What Motivates Us, regarding the key elements that make any business (or project) succeed, and she correlated them to the novice’s role:
Mastery isn’t simply about learning to be technically competent on the job. As Kate Matsudaira explained during a keynote address, “Success isn’t chance. Success is mastery.” For a developer at any level (or in any job, not just software!), the best and happiest moments are when you push yourself.
To gain any kind of mastery you have to get through plateaus and dips in your learning curve, and that usually requires a full stack understanding of the technologies a developer works with. It makes sense to give novices the best opportunity for success by giving them something meaningful to work on that requires them to learn new skills.
To limit day-to-day issues, Worth suggests these “five habits:”
This isn’t the sort of thing you can do skeptically, without management buy-in, she adds. Or without participation from rest of the development team either, for that matter.
The bookend to the “encourage junior developers” was Carina Zona’s session on “Evil Overlords’ Tips for Being a Senior Developer,” much of which was advice on helping other people “level up” to their next position (in skill or rung on the corporate ladder). For example, Zona pointed out that Emperor Palpatine was a pretty effective mentor to Darth Vader, including career counseling, helping Darth get over initial mistakes, and building for the future.
So in the context of integrating junior developers into a development team, Zona suggested, it’s important to keep in mind the 10 Commands of Egoless Programming, identified by Jerry Weinberg way back in 1971. For example, Weinberg wrote, in The Psychology of Computer Programming, “You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.”
So, Zona points out, experienced developers offering mentoring should keep in mind the importance of critiquing code, not people. Encourage communication among team members and managers. Teach novice developers that they are not their code. “Be kind to the coder, not the code,” she says.
“We are defined by what we make the time to do, not by what we do when we have time,” Matsudaira said. That applies to the junior developer, as well as to the senior developer guiding her.
Receive Mendix platform tips, tricks, and other resources straight to your inbox every two weeks.