It's a surreal thought that I've been running MousePaw Media's internship program for nearly four years. In that time, I've learned a lot about hiring, management, and training, often purely through trial-and-error.
We invest most of our personnel efforts into interns; it's actually the only way into the company. By time an employee has completed the year-long internship program, we know they are ready for the responsibilities of a senior development position. Not only are they well-versed in our company's practices and methodologies, but they understand what the internship program is about.
That second point is important: whether you plan it or not, your entire staff is involved with internship and employee training. By making the internship standard at our company, I know our entire staff is familiar with the challenges and expectations. They can empathize with current interns, and they know how to come alongside and offer support.
Today, MousePaw Media now has one of the most robust internship programs in the Spokane/Coeur d'Alene area. To date, almost a dozen programming students have graduated from our program, and many went on to full-time positions at other firms. About half of them, I'm happy to say, have stayed on with us.
Objectively, there's very little difference between a successful internship and a successful training program. So long as the compensation is reasonable for the individual's existing skill level, I believe any developer without an overgrown ego will be open to working through a formal training program at the start of their job.
I hope by sharing my experiences and hard-won lessons with you, you can ease the process of onboarding new developers at your company.
Formalize The Training
When I first started the internship program, I had a handful of expectations worked out, but nothing formal. Since each intern had different tasks and skills, I figured they all needed a custom training program.
Reality didn't even come close to my expectations! Regardless of an employee's job within a department, they all need the same "core knowledge" - how to use the tools, collaborate, get help, make changes, give feedback, submit work, find documentation, and so forth.
At the start of this year, I worked with my Assistant Lead Developers to create an Internship Checklist, which outlines 20 specific tasks to complete. For each, we detailed the expectations and the learning goals.
We also needed to set a clear time frame for how long the training period lasts. Our internship program lasts for 240 hours at 6 hours a week (since we work with full time college students,) rounding out to approximately a year. Your company probably has very different needs (it should't take a year for a full-time employee to onboard!), but you should determine the minimum time necessary for the training to have the maximum impact.
However, that 240 hours is not all structured training. Most of it is actually spent doing real work.
I've never met anyone who enjoyed the boring "mandatory training" videos and classes, which is why (aside from a few written tutorials) I don't waste my time with those techniques. Formal training should fit into the normal workload, never replace it. Spreading it out over a longer time period (perhaps a month) allows the training to organically fit into the employee's new, regular responsibilities.
Many of the assignments are designed to introduce a tool or method in our company. You only need to give an employee a taste of the benefits offered by a particular asset; once they know it's there, they will usually incorporate it into their own workflow in a way that is beneficial to them. Ultimately, you shouldn't be training an employee to "just do their job" - you should equip them to be capable of working anywhere in their department.
For example, some of our Internship Checklist assignments are...
Create five tasks on the task/bug tracker for your project.
Review someone else's code using the pre-commit review tools.
Make three meaningful contributions (at least 5 sentences changed/added per contribution) to the company wiki.
Within those assignments, we have given the intern permission to spread the assignment out, completing it in the normal course of their work.
In short, training should be standardized and organically integrated into 'normal' work.
Validate The Training
To accompany formal training, you need to establish a means of validating the training. For example, everyone at my company is required to read Dreaming in Code by Scott Rosenberg (which I believe should be read by every coder with a pulse.) However, somewhere in 2015, I realized that hadn't happened:
Some interns had read it.
A few interns had skimmed it or only read it partially.
A couple of interns hadn't realized they needed to read it.
As a result, I started requiring interns to answer three "essay questions" about the book. This allowed me to tell whether they had read the book, and to learn what they took away from it.
For every formal training goal, there needs to be some proof of the goal's completion. Sometimes this is easy, like an edit to a wiki page. Other times, it can be difficult, such as proving someone read the company's coding standards. I solved that by creating a brief online quiz on our servers using Lime Survey.
The First Two Weeks
I believe the first two weeks are the most disorienting at any new job. The trainee isn't just getting used to the company's formal policies and tools; they are meeting their co-workers and adapting to the company culture and everything that comes with it: expectations, unspoken rules, jargon, inside jokes...in short, the newcomer is invariably going through culture shock.
The worst thing you can do at this point is to park them in their cubicle and tell them to get to work!
At MousePaw Media, the first two weeks are reserved for acclimation and exploration. We have five very specific assignments to complete:
Read the Internship Introduction article.
Set up your development environment.
Read the Community Rules (since we have an open source community).
Read the official Standards.
Read and sign the wiki's "Getting Started" page.
That first item is particulary notable. I created a tutorial that walks a new employee through the entire process of setting up and getting comfortable with their regular tools and workflow.
Aside from these assignments, the newcomer has the freedom to explore. We take extra time during meetings to introduce ourselves and answer questions, and the new hire is encouraged to learn more about our projects - even the ones he or she isn't working on!
The formal assignments for that two week period may be different (and probably longer) for your company, but remember that the first two weeks should give the newcomer time to acclimate without the full dose of job stress. Culture shock is stressful enough!
When the two weeks is over, the new hire is more comfortable with their role. They (hopefully) feel like part of the team, and they have that initial confidence boost to propel them into their first "real" task.
Believe me, they'll need it...
Throw 'Em In The Deep End
Once an employee is over that initial two-week acclimation period, the best thing you can do is to immediately start treating them like a normal employee.
It may be tempting to "ease" a newcomer into their new job, but I've learned first hand that it is the worst thing you can do for them, for two reasons.
First, "easing" an employee into their regular work belittles their capability. You hired a smart, capable person (I hope)! They neither need nor want their hand held. Starting on an unfamiliar project is not unlike getting into a cold swimming pool: slowly lowering yourself in only prolongs the torment. Jump in and shiver it out!
Second, "easing in" sets a false expectation bar. This prevents the conscientious newcomer from establishing the self-control habits that will allow them to succeed, and it gives apathy a chance to breed in the less-conscientious employee.
It actually isn't any different for interns: the entire point of an internship is to demonstrate what a real industry job is like.
In short, as soon as the two-week acclimation period is over, I throw the new developer in the deep end and teach them to swim. The only way to learn code is to read it, the only way to learn a language is to code in it, and the only way to learn a job is to do it. I've been programming for years, and I don't feel any less disoriented in a new project than I did when I was a rookie.
That said, you aren't throwing them in the deep end without support! We encourage all our employees to ask questions and seek help from co-workers. Those individuals who refuse to ask for help simply don't last: teams live and die by their ability to collaborate!
Document Your Tools
I've been working at MousePaw Media for years. I can basically work in my sleep by this point (which, I think I have done a few times). All our methods, standards, and tools are programmed into my auto-pilot. Unfortunately, that also means that I forget that newcomers don't have this stuff memorized. It's completely new to them!
To save time, and ensure everyone had access to the same knowledge of our tools and methods, I actually wrote documentation for our development network. No kidding: real prose documentation, hand-written in Sphinx, tracked in a repository, and published on our server. In it, I detail literally everything:
How to create and manage tasks,
How to submit code for review,
How to build from a repository,
How to set up a development environment from scratch on a computer,
How to use our IRC room bot,
...and so forth.
This has the added benefit of getting outside contributors on the same page.
I should mention that clearly documenting the tools leaves no excuse for employees not using them. Proper and regular use of development tools is a key component of successful collaboration. Make that expectation clear to every member of your team! Meanwhile, leave room for employees to give feedback on the tools and processes they're using. Methodologies exist for the developers, not the other way around!
I've put a lot of time into our Development Documentation, and I know I'll put a lot more time into it in the future. It's worth the investment to have a canonical, up-to-date guide for every tool, every method, and every workflow in your company.
Wait For The Questions
Once you've clearly stated expectations, established how to Get Things Done, and given license to freely ask questions and get help, give the new hire their independence.
When I first started the internship program, I felt like I needed to intervene in every issue that arose. I didn't want my interns to crash into any brick walls of frustration. I quickly discovered, however, that I wasn't really helping them. Frustrating problems, annoying knots, stubborn bugs - these are part and parcel of a coder's job. I have learned far more from solving a single particularly difficult problem than I have from an entire semester-long programming course in college!
I learned to give my interns the room to make their own mistakes, and for me to only get involved when asked. It is far easier for an employee to climb out of a hole THEY dug, rather than out of a hole YOU dug. If they mess up, graciously point out what they can learn from the situation, and encourage them to try again.
Conversely, when an employee does ask for help, respond to the call by teaching them how to solve the problem themselves. Share your own experiences, point them to documentation and existing code, but let them own the solution.
That said, I will intervene before an employee makes a wrong turn, but only if it will seriously hamper or delay the project or team. I've had to say "no" to a proposed algorithm that would have occupied several months before its disadvantages would be apparent. I pulled the plug on one coder's "research" into a low-priority task because he was holding up the project. That sort of intervention is my job as Lead Developer. Finding that balance is that age old quest to walk the line between micromanagement and passivity.
Summary
Create a formal training program that fits into and complements a normal work load.
Dedicate the first two weeks to initial acclimation - getting to know the team, becoming familiar with the tools, and exploring the company's projects.
Give every employee the right to ask questions and seek out help from you and the rest of their co-workers.
After the first two weeks, don't "ease" the newcomer into their job; drop them in the deep end with their new normal work load, and teach them to swim.
Maintain clear, friendly, and exhaustive written documentation for all of your company's tools and common workflows.
Wait until employees ask you for help before stepping in (unless you have a managerial reason to get involved). Let them make their own mistakes.
All of that said, I'd like to come back around to that book I mentioned, Dreaming in Code by Scott Rosenberg. There's a reason I have all of our interns read that book - it does a phenomenal job of introducing the paradoxes and conundrums of software development and project management. You can find out more on the official website.
Also, if you're in the Spokane/Coeur d'Alene area and looking for experience in the programming industry, check out our Internship Program.
Cover Photo Credit: "Cliff diver" by Kfengler | Licensed under CC-BY 3.0 Unported.
Top comments (6)
Thanks Jason - I'll shortly be onboarding some new developers under an apprenticeship scheme. There are quite a few things you mention that I think will really help them get the most out of it. Not sure if this might be possible, but it would be really helpful to see the checklist and documentation you mention. All the best, Gwyn
Hi Gwyn, thanks for your comments! Our network docs are still being written, but they're mostly done. You can view them here. (Note: The server is only online from about 6am-10pm Pacific.)
The internship checklist is on our Phabricator, but it can only be viewed by staff and trusted contributors. Here are the summary titles of of most of the assignments:
If you need more info, let me know and I'll see what I can do.
Thanks - this is a great help. Exactly what I needed.
Our new development micro-platform - Nanobox - was created to specifically help with this problem of getting a new dev up to speed. Too many new devs spend more time than necessary configuring their environments and fiddling with overhead instead of jumping into the code base and being productive.
Like you said, new devs need room to make their own mistakes, but it also helps to not bombard them with distractions.
For any dev team leader trying to solve this problem, this explanation may be useful : "On a fresh laptop, our latest dev was up and running with Nanobox - repos cloned, DB imported, local running - in 7 minutes flat. Unheard of." (alternativeto.net/software/nanobox...)
Definitely useful! One of the reasons we actually have our interns set things up manually is because many of them are new to Linux. The process of following the tutorial (with its explanations of what is being done) helps familiarize them with Linux and their development tools.
But, in an environment where that isn't a goal (such as with onboarding a regular developer), your solution sounds quite helpful.
Programming is not a hard job but it is a methodical job.
When its not methodical , it becomes hard.
Your methods reduce madness.