Apprentices, they're not just for printing and binding user manuals

A bit of history

You've just been given an apprentice.  What's your plan for them? In the guild days, in a woodworking shop, an apprentice would keep the shop clean, keep the glue heated, and sharpen the tools.  Sounds like busy work, but it wasn't fruitless busy work.  Those menial tasks taught the apprentice how glue flows at different temperatures, how to keep their tools in working condition, and how a clean shop can speed production. After some time, a journeyman would enlist the apprentice to help with a project and in return show them how to cut a special joint, or smooth a piece of wood.  Eventually, when the apprentice was deemed capable they would receive a project of their own. In the days of the guild, the apprentice worked not for money, but for the education of a trade. The master craftsmen invested time and money to train the apprentice so that the apprentice would eventually make a profit.

Modern times

In modern times, most apprentices have had some educational experience in the trade that they are pursuing because colleges do not allow students into a co-op program until the 3rd year of their education. What was your first task as an apprentice developer?  Did you write a bunch of unit tests?  Convert a program written in Java to Python? Were you tasked with implementing the simplest trouble ticket known to man? Or did you print and bind 54 copies of the user manual? Unfortunately, a decent percentage of people I've talked to have done the latter. Imagine the woodworker apprentice having to print the literature for a chest of drawers. That kind of task wouldn't help the apprentice learn how to build a chest of drawers, so why do we ask our apprentice developers to do something similarly pointless?

The helpful apprentice

Presumably, the apprentice was hired because they have some skill that could be beneficial to the team, and not just because "we have to spend this money". Many times companies do not see co-ops as their future employees, but as a way to round out the budget for the fiscal year. Hiring co-ops should be considered an investment in the future of the company. From that viewpoint, the company invests time and money into an apprentice so that when the apprentice graduates from college, the apprentice can immediately start work full-time and be a productive employee. The investment risk for the company is that the apprentice could be lured to a different company after graduation. So what are some areas that an apprentice could be helpful?  That depends on the team, and the project.

Tools

Some view co-ops, new grads, and new hires as a nuisance that must be dealt with until they learn enough to be useful. This is an unfortunate attitude because there are plenty of areas where those that are new in their career can help an organization. How many times have you been in a team meeting where someone has said "We really need a tool to help us with task x"?  Where task "x" could be a writing a static analysis tool to parse source for style guide breaches, a VB script/macros to help systems engineers with some repetitive Excel task, or updating a the nightly build script. In that same meeting how often do the senior developers have time to jump in and write these tools? From my experience, not too often.

Trouble Tickets

"Trouble Ticket", "Bug Report", and "Software Problem Report", are just a few of the ways to describe a problem with software. Usually, there are numerous low priority problems that the journeymen, and craftsmen developers don't get to because they are too busy. The problems usually read as follows: "expand the 'name' widget by 15 pixels", "correct spelling of the word 'account' in report #15", "distance unit of measure should be user selectable between km and miles". These are issues that a journeyman developer could finish quickly but journeymen are focused on the higher priority issues that require experience. These situations are where an apprentice can be extremely helpful. Sure, correcting the spelling of the report output sounds trivial, but it forces the apprentice to go through the entire trouble ticket process from claiming & estimating, to implementing, testing and finally peer review. In addition to an education in process, the apprentice gains logical knowledge of the code base, as well as experience building and running the software. When the apprentice has shown competence with simpler trouble tickets, they can be given more complex assignments.

Discovery Time

Typically, new grads, and even senior level new hires (they are still apprentices for a while) need "discovery time" before jumping into a project. The apprentice is usually given the Software Design Documentscoding standards , an API reference (if one exists) and build instructions for the software. Then the apprentice is told "come see me if you have any questions".  Documentation is essential, but often times documentation alone is not enough to prepare one for working with the code. A journeyman who devotes time to give his or her appointed apprentice a guided tour of the code base, pointing out highlights and answering questions along the way, will instill a good foundation for learning more about the system architecture described in the documentation. Sometimes a side effect of discovery time is that the apprentice will find inconsistencies between documentation and code. A fresh pair of eyes, even if they are inexperienced, can go a long way to flush out problems in documentation.

Investing in people

Master craftsmen of the past realized that their time spent on an apprentice was an investment.  Companies that treat their apprentices as investments in the future will see a greater return than those that treat them as budget filler. When you are given an apprentice, what is your first reaction? Hopefully it will be one of excitement. If you have other ideas for tasks for apprentices please leave a comment below. I look forward to reading more ways to use this natural resource.

References

Information on the apprentice, journeyman, master craftsman relationship of the middle to late 19th century England from "The Jointer and Cabinet Maker" by Lost Art Press.