What Kind of Learning Developer are You?
Getting to a place where a person calls himself a developer is just part of the story. The other half is really about how he develops himself once he's in his career.
Ultimately, it depends on the kind of person the developer is. I've seen a couple scenarios in my experience:
The Renaissance Man
You know the character that is always the nemesis of the everyman hero in romantic comedies?He's the guy that looks like he's going to get the girl the hero wants because he's a double PhD in law and medicine, inherited more money than you'll find in the Denver mint, plays guitar, can charm cats, is an award-winning chef in his spare time, owns stocks that only go up in value, and looks like he walked off the cover of some glossy magazine. Oh yeah, he also knows every language O'Reilly has ever published a book on and can work at a high level of mastery.
Yeah, that guy. Not many exist, thank God, but these guys aren't just lucky, they're also deeply talented. They are the Mozart to your Salieri, and you can't do anything about it. Programming is well served by people capable of blending outstanding memories with quick minds, an ability to manage complex concepts, and organizational skills. Most of us have some of those things but not all of them. What does that mean? It means the Renaissance guy can study less and learn more because it comes naturally. So for him education doesn't require quite the investment of time it does everyone else. It also doesn't hurt that these guys make the effort to learn and can apply what they learn in their craft and their lives. That's what makes them Renaissance guys; learning isn't some uphill battle they do to try to get ahead, it's just a part of who they are. And it isn't just programming crap. These guys seem to learn everything.
Management advice: Don't worry about these guys, they'll take care of themselves. They're probably already making more money from their side businesses than what you pay them.
The Nerd
Nerds are en rapt by the whole world of software and computers. Unlike the Renaissance Man, for whom learning is natural, the Nerd has to work at it. The Nerd tells himself he enjoys it, but that's just a defense mechanism to deal with the fact that again unlike the Renaissance Man, the Nerd is socially estranged and isn't doing much else on Saturday nights. Learning about new techniques and technologies is above rejection on the entertainment scale. Fortunate Nerds work for companies that pay for the cost of education. But most are like the other 80% of the world's tech workers, where IT is considered a cost center, and they'll have to learn on their own resources. But either way the drive to learn is self initiated and they seek knowledge of their own volition.
Management advice: Nerds make great employees if you can handle their eccentricities. They won't make a jump to sales anytime soon, but they'll do good work and they're reliable. Do what you can to support their interests in learning. It'll boost their morale and benefit the organization.
The Resume Builder
This developer's strength is that she is always looking forward and cognizant of industry trends. The weakness is a desire to always be at that cutting edge and a fear that working on the old stuff is death in the marketplace. While there is some validity to that fear, I'm still seeing systems that run on COBOL, so its death, for those that are proficient in the language and willing to work with it, has been highly exaggerated. The same could be said for FoxPro, pre-.Net Visual Basic, PowerBuilder, and C++.
The Resume Builder is always learning, but unlike the Nerd and the Renaissance Man, the Resume Builder never develops deep proficiency. The Resume Builder, currently using language X, will be satisfied with a year or less of experience with it, and even at the day job, will be stealing time from work to study language Y. When an opportunity to use language Y appears, at the same company or elsewhere, the Resume Builder will move on. Once entrenched in her new position, the Resume Builder will begin studying hot new language Z, and will be ready to move on again in a year.
The Resume Builder's resume is indeed impressive, with every programming language conceivable on it. But what the resume doesn't tell you is that the code the Resume Builder wrote wasn't very high quality. It might have been Visual Basic, or PL/SQL, or Java, or C#, but it tended to solve problems the same way in each language, rather than using the language's strengths. It would include T-SQL that used lots of cursors instead of set theory or it might be an OO language where the methods were each 500+ lines of spaghetti code instead of smaller, logically partitioned components. The resume also doesn't mention that the Resume Builder, busy moving between languages, tends to repeat the same mistakes in each new language.
Finally, the resume also doesn't tell the story of the Resume Builder's poor motivation while working with language X. Any assignments in language X were done quickly and with a band-aid approach. Sometimes a band-aid approach is the correct tactical response when the preferences of a developer and a project manager clash but everyone wants to stay employed. The actions of the Resume Builder aren't of that type; they don't leave behind a rushed solution with useful documentation for those who must follow; they leave behind a train wreck caused by neglect for maintenance.
Perhaps I shouldn't be so hard on the Resume Builders. At least their learning is still self motivated, even if the motivation is for the next job and not necessarily for building quality solutions. Frankly, the Resume Builders probably don't care what I think. They're too busy counting their money.
Management advice: Nope. I know you wouldn't listen to me anyway because you keep hiring these guys.
The Anchor
Sometimes developers don't care to learn. It's not that they won't or that they don't enjoy it. They might even like it, but they're not motivated to do it regularly on their own. This is because learning involves substantive effort outside of work. And that's an important distinction I haven't mentioned: learning job-related skills on the job versus learning them as an extracurricular activity.
The Renaissance Man learns with ease anytime, anywhere. The Nerd has to work on it but typically doesn't have a problem committing personal time. The Resume Builder might also do it at work and at home, but prefers to bootleg time from work (and I don't mean bootleg in the nice 3M way, where bootlegging led to the creation of the now ubiquitous Post-It Note). The Anchor will plod along at work, primarily doing work, and when the bell rings at 5pm, he's only doing work at home if it's for a production emergency. The Anchors will learn if someone is forcibly hauling them through the water or holding their hands through a software learning exercise. But it had better be on company time. Left to their own devices outside of work, they'll opt to do something else they find more palatable.
There's nothing wrong with the Anchor's philosophy. It's rather laudable in a work-life balance approach. However, learning isn't really about work even if it's about work-related skills. It's about self development and furthering one's ability as a developer. If someone is too busy at work to learn new things that help both himself and his employer, they'll both be endlessly mired in the same approaches with the same problems. Any improvements from this camp will be rare and of incremental value. Having lots of these guys means that instead of building a staff of Renaissance Man wannabes, you'll have a staff of guys that do as little as possible. They'll never sufficiently refactor the software so that they can spend more time furthering the company's strategic goals and less time fighting fires in overtime (see, I worked the overtime angle into the post after all).
Management advice: Anchors aren't going to lead the way in evolutionary improvements for the organization. They can be reliable in some roles, but be careful about putting them in positions where they are going to make decisions for software projects of considerable risk and complexity.
Keeping it Real
Despite some grains of truth, the above was a largely humorous look at different learning motivations for developers. The truth is that you can't cleanly and completely categorize any person. I myself could have fit into any of those categories (except for that Renaissance thing) at different times in my career depending on my level of maturation, experience, and the environment.
That's enough about intrinsic motivation. Next time, I've got some thoughts on how developers learn.
