Bringing Entry Level Programmers up to Speed
Welcome Aboard, New Grad
I recently answered a question on programmer Stack Exchange, and it got me to thinking. The premise of the question was (paraphrased), “we hired a bunch of entry level people as an investment in tomorrow but we’re not quite sure what to do with them today–what do you think?” The most popular answers at a glance appeared to be along the lines of “give them tiny features, let them fix defects, have them read documentation, etc.” My reaction to this (and hence my response) was a sense of vague disquiet, with the exception of the “have them read documentation,” which made me throw up a little in my mouth at the thought that one might learn to do something by reading some hastily-written, outdated, often tautological body of desiccated text written by someone being told to do so on pain of corporate demerits. “Welcome to the company, Bill, but before you get started talking at meetings, why don’t you read this dictionary from 1924 to get a feeling for public speaking. Really focus on ‘S’ because a lot of words seem to start with that one.”
But I digress. The point of the discussion is to figure out what to do with the juniors. A common point of consensus is to spoon feed them small tasks so that they notch a series of wins and gain some confidence. One common example that I’ve seen prescribed for juniors (and sometimes new mid-level or senior developers for that matter) is “go and fix some defects.” Apart from the documentation, this is the one that really bothered me, and I couldn’t quite figure out why. So I left the Stack Exchange page open and went to go brush my teeth and get ready for bed. Halfway through brushing my teeth, it hit me like a bolt of lightning–so much so that I’m sitting here typing this sentence with my toothbrush dangling from my mouth.
The problem I have with starting newbies (and especially entry level people) with defect fixing is that you’re saying to them, “Welcome aboard! Now go get an eyeful of the worst that our code base has to offer.” I mean, ipso facto, you’re sending them off to track down things that don’t work, and the source of things that don’t work is wrong and often bad code. Think about your code base or code bases you’ve seen before. Where do the defects hang out? Are you going to be showing these newbies heavily unit tested utility classes or the polished pieces of code, or are you arming them with a dull machete and sending them off to fend for themselves in the dense underbrush of some monstrous, almost-but-not-quite-threadsafe singleton? Watch out for the mosquitoes, heh heh! (But seriously, you could actually potentially get malaria from this code.)
Isn’t that sort of fundamentally backward and maybe even a touch demented when you get right down to it? If you come to me and tell me you want to learn to dance, I don’t get really drunk, stumble around and tell you to point out what I’m doing wrong. And like trying to decipher the patterns and motivations of drunks, there’s really no value in trying to understand bad code. There’s a downside, in fact. Programmers who are introduced to software development in this fashion learn to love debugger. They’re going to learn programming by coincidence and become very proficient at tweaking variables and coaxing the execution flow into various blocks and around various exceptions. Before you know it, they’ll be checking in fixes with weird, unpredictable, and far-reaching consequences because they’re learning from badly written code how to push the dirty mop water around to check this defect off the list. And as for the other defects they’re introducing–well, that’ll just give them more to work on later so they won’t be bored to tears reading your obsolete documentation.
If Not Documentation and Defects, Then What?
I once worked in a shop where the development manager had gone through a few iterations of how to bring new people on board. He eventually settled on what I considered to be an excellent approach. He would have new developers dump a version of the code from source control and give them a dummy assignment. In this assignment, they would have to implement a feature that was pretty representative of the kinds of features that other developers implemented in reality and one that had them touch a pretty large cross-section of the code base. This was purely an exercise. The work was tossed at the end, but they got good experience and meaningful feedback with zero risk.
I had the good fortune to watch this state of affairs develop, and my firsthand impression was that the developers who implemented this bogus feature were ready for prime time much more quickly than previous onboarding sessions where people were encouraged to read sparse documentation, fix defects, etc. This actually worked, and it wasn’t demotivational or boring. The only drawback is that there might have been a bit of a tendency to loaf, as the newbies knew from the get-go they weren’t implementing a real feature. I always wondered how it might have gone to let them think it was real until the end and feedback stage.
I consider this an excellent example of a productive thing to do with new developers, especially entry level ones. Yes, I’m serious that working on a throwaway feature is productive. Sure, it won’t be shipped and their initial time isn’t contributing to the bottom line, but then again, neither is documentation. And defect fixing is really a crapshoot since they’re just as likely to use their dull machete accidentally to hack off the arm of another programmer as they are to chop down a defect successfully. If there’s a fifty percent chance of marginally positive productivity and a fifty percent chance of marginally negative, you’re right back at square one.
Here are some other activities that you can give to entry level developers right away to help them get up to speed quickly and contribute meaningfully:
- Teach them to unit test and task them with getting (meaningful) coverage over legacy code. There’s no better way to see how the code actually works, the automated test suite grows, and this is a virtually no-risk activity.
- Have them write documentation–not read it. I consider this fundamentally inferior to having them write tests, but it’s certainly better than putting them to sleep with documentation reading that will mean nothing to them. In order to write about something, you need some degree of understanding. (In the end, you can probably toss what they’ve written since it will just become obsolete anyway. Value the knowledge they’ve acquired instead.)
- Pair them with a senior developer and start them out watching one hundred percent of the time. Start ratcheting that figure down by five percent or ten percent every few days until they’re writing code and getting immediate feedback. The drain on the senior’s time will prove worth it in the long haul.
- Turn them loose to try their hand at actual feature development (making sure they get quick and helpful feedback–daily or more). The worst case scenario, assuming that you have a sane source control paradigm, is that you discard their work and they learn a lot from their failure. Best case scenario is that they rise to the task.
If you have more ideas for what to do with newbies besides these, I’m interested to hear. I have no doubt that there are more approaches and good ideas out there. I’d just like to encourage anyone reading not to underestimate the new hires and risk boring them into leaving. I’d also like to encourage anyone reading not to throw them in them right into the trenches with the carnage in your code base and traumatize them into bad habits and cynical outlooks. Invest in them, encourage them to try and fail, mentor them, and make sure you provide quick and meaningful feedback. I promise you that you won’t be sorry in the end.