Site moved…
I decided to consolidate my blogs. All of the old content and new posts can be found at http://journeymandev.com
Shaping Expectations Part 2 “The Guru”
What should an apprentice expect from a ‘guru’ mentor?
During different phases of my career I have had different types of mentors. Some experiences were good and some experiences were bad, but I learned from each of them. Every mentor will approach their task in a different way and their approach affects you, the apprentice, directly. In the following paragraphs I describe a few different classes of mentors, what to expect from them, and how to work with them. As with the apprentice classes in Shaping Expectations Part 1, the guru mentor described below is not meant to be comprehensive and definitive.
The Guru
In general the guru will be technically brilliant but socially inept. Gurus always consider themselves to be in a time crunch and as a result they rarely spend time actively mentoring. Tasks will be delivered to you, tersely, via some form of electronic communication and will, occasionally, be incomprehensible. This mentor expects a lot of work done quickly, and often does not understand why you have trouble with complex ideas. Any work generated for the guru will mercilessly reviewed under extreme scrutiny. This mentor’s respect can only earned as reasonable doubt is never given. Guru mentors are generally argumentative when their design, implementation or philosophy is questioned.
An apprentice under the tutelage of a guru must be prepared at all times. To gain the respect of this mentor questions must be researched, well thought out and timely. Your work must be verified from every angle before turning it over. Be prepared to have any work product you turn in to be completely re-worked by the guru without explanation. Redoing other people’s work is one reason the guru has so little time.
What can you learn from this mentor?
For all of the guru’s faults, this mentor is still technically brilliant. There is a wealth of knowledge that can be learned, you just have to work a little harder to get to it. Once the guru accepts you as a productive team member, you will have an open door to learn.
One of the great things about this mentor is that they force you to verify your work. As a student in primary school you were always told to double-check your work. How often do you apply that principle in your day-to-day activities? Being an apprentice to the guru will make verification a habit.
The guru’s social inadequacies will demonstrate how important social norms can be. Observe how other team members interact with the guru. Observation will allow you to learn what interactions work and do not work with the guru and other colleagues.
This mentor knows everything and expects you to know everything too. Musicians often say “Make music with people who are better than you, if you want to get better”. Working with the guru will be frantic and you will struggle to keep up, but the amount of knowledge gained will be tremendous.
Mentors gone but not forgotten
I started programming professionally over 10 years ago. As a student working full-time I had a mentor who treated me as an equal. He taught me a tremendous amount about networking, C, C++ and was a very good friend. One of the most important things he taught me was how to tell my customer “no”. “You can’t just say ‘No.’ You have to say ‘Yes, I can implement that given adequate schedule and budget.’”. I use those words often. I even taught him some new techniques that I was learning in school.
Over the years we each moved on in our careers and lost touch. And today I’m extremely sorry about that. The world lost a great mentor today. I hope I can pass along to others the wisdom that he passed to me. Luke, you will be missed.
Shaping expectations part 1
What to expect from an apprentice
Like most questions in software development, the question “What can I expect from an apprentice?” has the answer “it depends”. An apprentice joining a company as part of a co-op program will have an entirely different skill set than a new graduate. In addition, senior developers transitioning into a project will need mentoring before they are self sufficient with their duties. The important thing to recognize is that each apprentice requires a different approach from their mentor. Apprentices need different mentoring approaches based on personality. The sections below describe the three categories of apprentices that I have seen in years past. Although the categories are general and not meant to encompass all personality types, they will provide a starting point for finding the motivation for your apprentice. In the sections below, I describe what you might expect from an apprentice and the mentoring approach that I have seen work. I will focus on co-op level apprentices, but the categories also apply to new graduates and senior developers. You may have different experiences, and I hope you share them in the comments section at the bottom of the post.
“The Prodigy”
The easiest apprentice to mentor is the prodigy. When this apprentice is tasked, they will immediately see how to apply the theory they have learned to the task at hand. This is also the apprentice that will challenge the mentor’s knowledge by attacking a problem in new ways. Prodigies have a tendency to be over zealous. The mentor that has been assigned this apprentice must take care not to stifle passion, while at the same time, keep the prodigy aware of standards and process.
Prodigies need guidance too. Take care not to smother, but do check the prodigy’s progress occasionally. If you leave a prodigy alone too long, they will produce the Michelangelo’s Sistine Chapel ceiling paintings, when all you asked for was a coat of satin latex interior paint. Most of the time a prodigy will complete tasks rapidly, therefore have a to-do list of tasks laid out in advance. Another aspect to keep in mind with a prodigy apprentice is that they need to be challenged. If given a repetitive or mundane task the prodigy will challenge themselves, possibly wasting time and resources in the process.
“The Good Kid”
The good kid is just that. A good kid. This apprentice wants to learn and be productive. The mentor will field numerous questions as the apprentice learns standards, process and how to apply the theory they have learned in school. Good kids generally fall into two categories. Those that spend time researching a topic to figure out something for themselves and those that ask questions before doing research. The mentor’s dilemma is figuring out how to guide this apprentice into researching for themselves, and understanding when it’s time to ask for help. Often times the good kid will spend hours trying to figure out a problem, when they should have asked for help.
As a mentor, keep track of this apprentice. Check in on them one or two times throughout the day depending on the difficulty of their assignment. Ask them “How is it going?”. If the apprentice has hit a roadblock they are more likely to ask a question if they are approached rather than “bother” you. When the apprentice’s tasks has been completed, ask them what they have learned. Sometimes, the answer they give may surprise you.
“The Slacker”
The slacker will generally miss deadlines and meetings. They will ask for no help, or will ask for so much help that it is obvious they have put no effort into figuring out the task. While this apprentice is frustrating to mentor, they are not a lost cause. A mentor must be careful not to dismiss this apprentice too easy. The slacker usually needs a different approach than their mentor would normally use. For instance, some need to be “spoon fed” their goals and instructions until they become proficient. Sometimes the mentor/apprentice relationship is not congruent and a change in mentor will turn a “slacker” into a “good kid”. Then, there are times that a slacker is just a slacker.
Mentoring this apprentice can be challenge, therefore patience on the part of the mentor is required. This apprentice will require more attention and motivation. One of the mentor’s challenges is determining the motivating factor. Think about the tasks this apprentice completes to your satisfaction, and try to determine the apprentice’s motivation. Often times the motivation is not the task, but how it is presented. Check in on this apprentice more than you would the good kid. Be sure to ask “How is it going?”, “Do you need help?”. If all else fails, ask someone else to mentor the apprentice to determine if the apprentice/mentor relationship is strained.
In closing
Obviously not everyone falls into these categories, but I have found that the categories described above are general enough to describe most apprentices. Hopefully I have given some of you mentors the ability to recognize the category of apprentice you are mentoring. Knowing who you are dealing with is important in the mentor/apprentice relationship. If you have more apprentice categories, ways of guiding apprentices or just general comments please leave a comment below or email me via the contact page. Apprentices reading this, don’t worry. Part 2 of the Shaping Expectations series is “What to expect from a mentor”.
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 Documents, coding 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.
