If you’re a senior developer with years of experience under your belt, it may be hard to remember what it was like coming out of college with a newly minted CS degree, and entering the workplace. But as David Hoover argues, helping these newcomers to the workforce to succeed can be the difference between effective, motivated developers and confused, discouraged ones. Hoover is the author of the new O’Reilly book Apprenticeship Patterns, and he says that people coming right out of college may, in fact, be less motivated than someone who has been working for a while. “One of my theories is computer science education is really hard, and it’s expensive. And so when you’re done with it, you’re ready to cash in and sit back for a little while. ‘Hey, I just spent a lot of money. I spent a ton of time and effort and pain on four years of getting this certificate and okay, now it’s time to make that pay off.’ You’re definitely going to be less incentivized to start a new job, and now realize that you’ve got so much more to learn still. As opposed to someone who’s just coming up, who’s going to be at a big disadvantage knowledge-wise, but is probably actually going to be at a big advantage motivation-wise because they’re going to be hungry, and just assume that they have to learn everything on their own. Whereas, like I said, some computer science people are going to be disincentivized. They’re going to be surprised that they’ve come into their first job and, geez, they have to learn source control and they have to learn unit testing and they have to learn about these different processes that we use. And some programs prepare you for that stuff; some programs are very theoretical and very outdated. And you just have a ton to learn in your first gig.”
According to Hoover, one way to ease the transition into real life development is to use an apprenticeship model. His book draws on his own experience moving from being a psychologist to a developer, and the lessons he’s learned running an apprenticeship program at a company called Obtiva. “We have an apprenticeship program that takes in fairly newcomers to software development, and we have a fairly loose, fairly unstructured program that gets them up to speed pretty quickly. And we try to find people that are high-potential, low credential people, that are passionate and excited about software development and that works out pretty well.”
Hoover says that most developers have benefited from one or two key people in their career that helped them move along. “For people that had had successful careers, they only point back to one or two people that mentored them for a certain amount of time, a significant amount of time, a month, two months, a year in their careers.” He also points out that finding that person may mean looking outside your company. “For me personally, I wasn’t able to find a mentor at my company. I was in a company that didn’t really have that many people who were actually passionate about technology and that was hard for me. So what I did is I went to a user group, a local Agile user group or you could go to a Ruby user group or a .net user group, whatever it is and find people that are passionate about it and have been doing it for a long time. I’ve heard several instances of people seeking out to be mentored by the leader, for me that was the case. One of our perspective apprentices right now was mentored by the leader of a local Ruby user group. And that doesn’t necessarily mean you’re working for the person, but you’re seeking them out and maybe you’re just, “Hey, can you have lunch with me every week or breakfast with me every other week.” Even maybe just talking, maybe not even pairing. But just getting exposure to people that have been far on the path ahead of you, to just glean off their insights.”
For Hoover, one strategy that pays off is to not try and be the most experienced person in a group, but the least. “For me, I didn’t really get good solid mentorship until I was able to leave that company and get to another company where I could basically try to be the worst. I wanted to get onto a team where I wasn’t the three-year programmer who was suddenly senior application developer. I wanted to be on a team where as a three-year programmer, I was junior. And then I got to pair with people that had written books about test-driven development and people that were authors of successful open source projects.”
On the other side, being a good mentor may require some patience, but Hoover considers it part of the nature career path for a senior developer. “At a certain point in your career, your priorities shift from learning being the most important thing, to delivering software is the most important thing, then mentoring becomes part of your responsibilities. It’s something you take on if you’re following the craftsmanship mentality of apprentice to journeyman to master. And transitioning from apprentice to journeyman, part of that is taking on more responsibility for projects and taking on more responsibility for mentoring. One of the basic simplest ways of mentoring is programming with someone who’s more junior than you. And understanding that that person’s going to slow you down potentially, in the short-term. And it only works if you’ve got the right apprentices or the right motivated learner novice sitting next to you. But if you can invest some time into them at the beginning of a project or at the beginning of their time with you, that’s going to pay off three weeks, three months, six months down the road when they’re going to be blowing you away with their productivity because a lot of times these people are just sponges and they’re very excited about flexing their new development muscles.
For newcomers, part of the challenge is figuring out what to learn first, when dumped into a fast-paced development environment. “When it comes to trying to get up to speed, whether you’re in your first gig and you’ve just got this huge laundry list of things you’ve got to learn, or you need to get a first gig and you’ve got to knock out all of these acronyms that you see on the job requirements, one of the things that’s tempting is to just take it all on at once. There’s a book called The Art of Learning that’s written by this guy that was a chess grand master when he was relatively young, and left that behind and went and became a martial arts grand champion. And he talked about the way that he was taught chess wasn’t to start with a full board. It’s to start with the king, another king and a pawn, meaning remove as much as you can and make the game as simple as possible for starters and start with the end game. And we use that in our apprenticeship program, by don’t have somebody learn Unix and then RSpec and Ruby and Rails all at once, right? Have them just learn one thing at a time. Don’t have them learn vim and database design at the same time. Let them use the tools, as few new tools as they can at once. It’s tempting for these enthusiastic young people to take it all on because they are fast learners, but it can become overwhelming four weeks down the road when you’re starting to get advanced in all four — you’re trying to take next steps in too many things at once. What I would do is pick one and time-box it to two or three weeks. And then move on to the next. And then you’re going to end up coming back, of course, because you’re not going to master anything in two or three weeks.”
Although Agile development is all the rage now, Hoover laments that it has led to a lot of virtual development teams, a practice that he says works against apprenticeship. “Whether you’re distributed or you’re just isolated in cubicles working by yourselves, it’s just fundamentally a poor learning situation. Because the newcomer is only going to have the internet and books, basically, to figure out how to do their job. Peer programming and a team working collocated together is pretty much one of the most ideal environments for apprenticeship, for people getting up to speed because they’re immersed and working side-by-side with people who really know what they’re doing. There’s a lot of teams and companies that are completely virtual. They’re spread across the country or maybe they’re even fairly close together in a big city, but they don’t have an office. I think that’s not an apprenticeship friendly environment. There’s a ton of things to learn from pairing or sitting right next to somebody that you can’t learn from them over instant message or over email or even over iChat. Especially at the beginning of your career, you’ve got to be looking for situations where you can expose yourself to new senior developers and learn their tricks because they’re going to have a billion little tricks that they don’t even know about, that they wouldn’t even be able to tell you about because it’s just so ingrained in the way they work. So you’ve got to stay away from distributed development.”
He also suggests seeking out small companies as a good way to learn a lot in a short time, although it has its downsides. “To be honest, I’m pretty biased against large companies. It’s just very difficult to make that work, but I’ve heard Google’s done a pretty good job at it. Although I don’t personally know many people whose first job was Google. I do know more people whose first job was in an IT organization at a mid-sized company. And again, a lot of those companies are actually starting to adopt Agile. I think you’re definitely going to have a different experience in a small company. There might be more pressure. Might be a little bit less stable in a small company. But you’re probably going to have exposure to a wider or a deeper set of people. You might have exposure all the way up to the top of the company. And you might have exposure all the way down to the business of the people actually paying for the software or specifying the software. Whereas my experience in midlevel or large companies is there was many, many layers separating the doers from the people that were specifying what needed to be done or paying for what needed to be done. In some ways it’s more intense because these people from far away can lay down strict deadlines and schedules on you and not really care about the consequences. But in some ways, it’s also less intense because if you screw up, you personally are so removed from the consequences of your mistake that it’s not a big deal. Whereas if you’re in a small, very tight-knit environment and you screw up, you can see who that affects. So there’s pros and cons to that. One’s going to allow you to experiment more, potentially. While the other is going to be a little bit more intense and you’re going to be learning from your mistakes and you might be afraid to experiment in a smaller situation. There’s probably no hard and fast rules about that. It’s just personal preference really.”
Here’s Hoover’s top 5 suggestions to succeed as an apprentice:
- Understanding where you’re at. “I wasn’t really exposed to the concept of apprenticeship until about two years into my career. And I had already made some pretty good progress. But once I was exposed to that idea and that people were out there trying to master this craft, this software development, it made me realize, ‘Oh, man. I’m just an apprentice.’ So having an accurate self-assessment. And you have that but it’s too easy to compare yourself to the standard developer out there, the average developer in our industry. And if you do that, you’re going to feel a little bit smug. And you’re going to feel like you’ve accomplished something pretty darn quickly. Just by caring, you’re already going to be ahead of a lot of different people. But instead, you should be comparing yourself to masters which are people that are out there doing great work and potentially speaking about it or writing books about it. And if that’s what you — if you want to achieve mastery of this craft, that’s who you should be comparing yourself to.
- Find mentors who are ahead of you in the field. “That might not be the luminaries of the field, but people that you can learn from and that are going to be able to give you some guidance about the right ways to approach problems.”
- Find some peers to network with. “Finding kindred spirits is another thing that is really important, I think, for people that are trying to walk this long road to mastery. These are more peers, people that come along with you who you’re going to bounce ideas off of each other or you’re going to keep each other going through different projects. You might not work with them. For me, I had a kindred spirit who worked at a different company, but we both worked in Chicago. We’d meet once a week over pizza and either pair on things we were more interested in than our job or lament the difficulties of our different organizations.”
- Perpetual learning. “As people in our industry know, our industry changes quickly. The technologies are rapidly evolving. There’s fundamentals, so you have to go back and study the classics of our field. There’s certain books that are timeless that I think everybody needs to be able to read. Certain computer science fundamentals like compilers and algorithms that maybe you’re not going to use everyday, but they’re important for stretching your brain. And other things that are a little more people-centric like Peopleware by Demarco and the Psychology of Computer Programming by Weinberg. So educating yourself, perpetual learning.”
- Setting aside time to practice. “Setting time aside to be able to write software outside the constraints of your day job is important because that’s where you’re going to be able to learn new techniques and try out new techniques without bringing down your production site because you screwed up or you were too excited about some new design pattern or some new technology, but being able to break these things called breakable toys where you can experiment and learn. And sometimes those things grow into real projects. Linux was a breakable toy a long time ago. Where Linus was just playing around and never thought it would amount to anything, but it turned into something.”