This article is about training, but not the typical “pay $1500 to sit in a stuffy hotel conference room for five days while some guy who hasn’t written software since Elvis reads his PowerPoint slides to you in an effort to keep you awake” training.
We’re going to talk about in-your-face, do-as-I-do, on-the-job, get-them-writing-production-code-four-weeks-out-of-school training. It’s the type that makes people clamor to work at your company, and requires a whole heck of a lot more effort than the fifteen hundred bucks to send someone to a week in a hotel conference room.
Every company that writes software needs to make training a top priority. Say that with me: every company that writes software needs to make training a top priority. Why? If word gets around that your company has a killer training program you’ll be beating candidates away with sticks (at least until the first lawsuit), it boosts your bottom line by making programmers better equipped to do their jobs, and gives people a sense that the company cares about their long term success, making them less likely to leave. As a nice side effect, learning new skills makes people more satisfied with their jobs.
So to review, well-executed training attracts developers, retains developers, and makes them happy. Say it one more time: every company that writes software needs to make training a top priority.
Developer Traits
Before we delve into the structure of an effective training program, let’s talk about the specific areas we can hope to improve. The two fundamental traits of a developer are: knowledge of theory and experience.
Theory
Theory is what we learn in school: little-o and big-O notation, finite state machines, 3rd normal form, etc… Theory is easy to discuss, but difficult to experience since it’s like a wispy cloud floating around in someone’s mind.
Most developers learn theory in school on the road to obtaining their degree in Computer Science or a related field. Many learn it from books, magazines, and developer websites. Theory is things like object-oriented concepts, database design and normalization, and many aspects of software architecture.
Someone who knows a lot of theory and has a little experience tends to sound more knowledgeable than they are. Their mind is mature in the ways of software, but their code is juvenile by comparison. It tends to be over-designed, overly complex, brittle, and lacking in practical areas such as error handling.
Until you’ve debugged an application that lacks error handling it doesn’t occur to most people that storing this information might be helpful. That’s where experience comes in.
Experience
Experience is about making mistakes. When you study theory there are no mistakes: code is bug-free, APIs are perfect, and operating systems never, ever crash. That’s why there’s no “blue screen” shape in UML.
For a programmer, the more mistakes you make the better you are at writing code. I’ve made mistakes on every project I’ve ever developed, and each mistake added one more notch to my belt. Experience can only be gained through sitting down and writing code; there are no exceptions.
Someone with a lot of experience and a little theory tends to write code that runs well but is difficult to maintain and extend. Since the point of software design (which relies heavily on theory) is to organize a complicated system into something extensible and easily-understood, a solution lacking in design tends to want in these two areas. The larger the system, the worse the problem becomes.
Apprenticeship
It’s a sad day when I cringe at the word “apprentice.” Let me say this up front: I’m not referring to Donald Trump’s TV show. Before the show became popular, “apprentice” described someone who works under the oversight of a mentor. Apprenticeship is about learning while doing.
Apprenticeship was born in the 14th century, and with it came a revolution. Suddenly young men and women could trade their most abundant asset, time, for a truly scarce resource, training. Skilled tradesman, including blacksmiths, cobblers and silk weavers, mentored young men and women with the promise that they might one day take over the business, while in exchange the tradesman lowered their labor costs by having low-cost apprentices on staff.
Apprentices were young men or women, typically 14 to 21. They didn’t make much money, but they learned their trades on the job. A blacksmith apprentice, for instance, learned about building super-hot fires, combining different metals to create mixtures with varying melting points, and how much work it takes to make a rake, a knife, or a plow. Most of it was not something they could learn from in school; they needed years of first-hand experience in order to master the trade.
Fast-forward 700 years and apprenticeship has disappeared. No, wait a minute…it hasn’t disappeared. This ancient tradition still appears everywhere you look, from construction to medical school to priesthood. So why is it that this model, which has certainly passed the test of time, is rarely present in the world of software development?
Is it because you learn software development better from books rather than from doing? Nope.
Is it because programming is a solitary trade, while running electrical wire requires a team of people? Wrong again.
How about the ol’ “physical trade versus thinking trade” argument? Not that one, either.
The only reason I can come up with is that computer programming is a new trade, only coming of age in the last 40 or 50 years, while the others: doctors, priests, construction workers, have all been around for thousands of years. And even though they’ve adapted over time, they remain steeped in the rich tradition of apprenticeship; a tradition that computer programming, a wee lad by comparison, has yet to accept.
Some would argue that apprenticeship is present in software development, and I have to agree to some point. I’ve learned a ton from the experienced developers and architects I’ve worked with (thanks Rick, Jeremy, and Calvin), but it’s always been on an informal basis, through osmosis, and only because they were willing to teach and I was willing to learn. From management’s perspective, my mentoring has typically consisted of: “You know .NET? Here’s a spec; build it.” That’s what needs to change.
There is a better way.
Training Done Right
You can probably guess where this is headed by now, so let me cut to the chase: the better way to train is through software apprenticeship. All you need are a senior and a junior developer. Ask if they’d like to participate in an apprenticeship relationship. The junior gets training, the senior gets to pass along his knowledge (most people are flattered if you ask them to be a mentor). The key here is to make a deliberate choice to pair two developers together and get their buy-in. No buy-in, no apprenticeship.
What should their interaction consist of?
Use the time-tested approach of trades that have been doing it for years. Let’s take an electrical apprenticeship as an example: in the United States today, the International Brotherhood of Electrical Workers (I.B.E.W.) trains thousands of electricians every year. They learn through two distinct experiences:
- Attending night school during the week to learn the theory of electricity.
- Working days on a construction site where they’re able to gain experience applying the theory to the hands-on construction of a building
His first day on the job an apprentice is paired up with a journeyman (an experienced electrician), who shows him the ropes. The journeyman typically talks the apprentice through a task, demonstrates the task, has the apprentice perform the task, then gives feedback. Listen, watch, do, review.
With software it looks like this: the mentor evaluates the task at hand, be it writing data access code or building a web-based user interface, and holds a white-board discussion with the apprentice (listen). Next, the mentor might write sample code demonstrating a particularly difficult or confusing concept (watch). At this point the mentor sends the mentee off to gain their own experience writing code (do). And finally, the mentor should review the code, providing positive and negative feedback and suggesting improvements (review). Listen, watch, do, review.
A final note: the key to any type of apprenticeship is the “do” step. Most software training gives you the listen and watch, but the “do and review” is what inspires growth and advances skills. The beauty of apprenticeship is that it tackles theory and experience in one fell swoop. And it’s easier than you think.
The Bottom Line
Training is critical to any company that writes software, and apprenticeship is the best way to bring new developers on board, make them feel at home, improve their skills, and keep them happy and growing. You’ll keep experienced developers in touch with new approaches, compliment them by asking them to share their wealth of knowledge, and hopefully create a few friendships along the way.
Photos by Sherry
Update:
I was recently contacted by a company in the UK offering a real software apprenticeship program. Details are below:
e-skills UK (an industry body for IT skills) is piloting a Software & Web Developer Apprenticeship in the UK, working with Microsoft and QA (a training company). Ten IT companies of all different shapes and sizes will be recruiting 20 apprentices, who will receive a 12 month structured apprenticeship programme. This starts with a 4 week programming boot camp, with 5 further weeks of technical training, on topics such as Data Modelling and Software Testing and, dotted throughout the year.
The key is that the apprentices will be working for the rest of the time, learning their trade as developers from the technical mentors in their companies, but also being productive employees. The pilot will be focusing on C# and the.NET framework, and the apprentices will be aged between 16 and 20, using this as an alternative route to going straight to college/university.
To get in touch, email ben.sweetman@e-skills.com or follow him on twitter @bensweetman.
