SOURCE: This article is excerpted from Secrets of the Rockstar Programmers: Riding the IT Crest by Ed Burns (McGraw-Hill, 2008), with permission from the McGraw-Hill Companies. All rights reserved. McGraw-Hill makes no representations or warranties as to the accuracy of any information contained in the McGraw-Hill material, including any warranties of merchantability or fitness for a particular purpose.
The speakers who frequent the IT lecture circuit are a gold mine of rock star programmer talent. The premiere series on that circuit is Jay Zimmerman’s “No Fluff, Just Stuff” (www.nofluffjuststuff.com), at which I had the pleasure of speaking in Reston, Virginia, in the fall of 2006. The keynote speaker at this particular conference was Andy Hunt, who presented his engaging “Refactoring Your Wetware” talk. Just ten minutes into Andy’s presentation, I knew I wanted to share his insights in an interview for this book. He puts out the vibe of a true Renaissance man, and he is -- right down to toting his well-worn Moleskine notebook and fronting his own rock-jazz-swing band, the Independent Memes (www.independentmemes.com).
Andy’s career arc has brought him through most of the roles one can have in the IT industry, from rank-and-file programmer at a Fortune 100 company, to senior architect, to independent consultant, to his current role as the co-founder of the Pragmatic Programmers LLC. The Pragmatic Programmers are widely recognized in the IT business for high-quality content (no fluff, you might say). They are also seen as a programmer-friendly publisher for IT authors. This is probably because it is run by two programming pioneers who “get it” when it comes to managing the process of authoring a technology book because they’ve read, used, and written them themselves. He and fellow Pragmatic Programmers founder Dave Thomas are seen as true thought leaders in today’s global programming community.
Name: Andy Hunt
Home Page: http://toolshed.com
Time of Birth: Mid-1960s
Region of Birth: Eastern United States
Marital Status: Married
Degree: Bachelor of Science in Information and Computer Sciences, Georgia Institute of Technology
Years as an IT Professional: 30
Ed: Andy, I like to start out with some soft-skills questions to warm things up. From your vantage point at the helm of Pragmatic Programmers, I bet you get to see a lot of new technology just as it’s taking shape. How do you tell when something new is going to also be something big?
Andy: Well, that’s an interesting question because -- and this isn’t just true of me or Dave or anyone else in particular in the industry, but just in general—when you’ve been in the industry a long time, people start to watch you and watch what you’re interested in, so past some particular tipping point, it becomes a bit of a self-fulfilling process.
Ed: You mean, you create the trends?
Andy: You start getting interested in, say, Erlang for concurrent programming, and now people start thinking, “Ooh, these guys are interested in Erlang. That must mean something.”
Ed: That’s a nice place to be.
Andy: You can cause your own industry swings, and I think it’s far too early to say that about Erlang yet, but certainly I think that was the case with Ruby.
Dave and I wrote the first English-language Ruby book (Programming Ruby, Addison Wesley 2001) and really brought that to the attention of the Western world. Dave, in particular, has been instrumental in beating the drum and getting people interested in it, using the language, bringing it to people’s attention.
Ruby was something that we were particularly looking for...that kind of technology.
I had just done a large data mining project in something like 50,000 lines of object-oriented Perl, and for various reasons, that was the environment I needed at that point. It was frustrating, but it was also really quite promising because it was so close to being a really nice environment, except for the fact that in Perl you had to do all the object orientation by hand. But the promise of having a scripted object-oriented language that had regular expressions, as well as good access to the operating system internals, and ran as an interpreted scripting language was a powerful thing.
At the conclusion of that project, both Dave and I started looking explicitly for that technology. We said to ourselves, “Okay, here’s a need. This is something I want to see. What’s out there?” And we looked and we scoured around, and Dave actually stumbled on Ruby in Japan. He found this website and said, “Hey, well, what about this? Take a look at this. This looks pretty cool.”
We started looking at it, and that started the ball rolling. In that case, it wasn’t really a question of looking at emerging technologies and picking the winner. It was a question of “I have this need. What is out there that could possibly fulfill this now or in development?” It was very much need-driven.
In general, I think that’s a better way to look at the question. New technologies pop up all the time. We get book proposals for new frameworks, new libraries, new languages, some stuff I’ve never even heard of, and it comes flying across [my desk] and [I] say, “Well, what’s this? Is this interesting? Does this have promise?”
You look at it, and the question I always try to ask is, “Okay, what’s the problem they’re trying to solve?” Concurrency is a big, hairy problem and trying to do it properly in a more traditional language like Java or C++ or C is problematic at best. You can do it, but it’s like the object-oriented Perl. You can do it, but there’s a certain amount of pain involved.
Then you’d look at something like Erlang that says, “Okay, well, here’s this problem and we’re gonna solve this in a completely different way and rather elegantly, so that a lot of the problems that you were facing just simply disappear by virtue of how the technology is created.”
Ed: Let me characterize what I’ve heard you say regarding the process here. After you were done with that project with the 50,000 lines of Perl, you had an idea of the attributes of a solution and then you went out looking for a technology that filled those attributes, right?
Ed: In essence, it’s almost like you had a requirements document and you were looking for something that filled those requirements.
Andy: I wouldn’t use the phrase “requirements document.” It’s a genuine requirement. This is something that I can see a need for, or clients or friends have had a need for, so there is a definite requirement.
Ed: There’s a tension between always moving on to the next new thing and sticking with it long enough to achieve true mastery. I want to find out if you think there’s any relationship between personal intelligence and one’s susceptibility to losing interest in something before achieving mastery.
Andy: I think there’s definitely a correlation there because, again, one of the facets of the programmer’s personality that I think is very important is curiosity. If you have mined the territory pretty thoroughly and there’s nothing left to be interested in, then, yeah, you’re gonna be in a world of hurt on a twoyear long project. One of the challenges for a project manager or sponsor is to somehow keep some level of interest going for your smartest developers because the less skilled, less curious developers really won’t run into that problem.
They’ll be perfectly happy still discovering the rudiments of it two years later. They’ll be fine. The best and brightest expert is gonna be bored in a week -- it’s no longer a novelty. Once the novelties run out, [boredom] becomes an issue; there are a couple of ways around this.
Some of the folks who advocate pair programming say rotating team members around all the aspects of a project helps ameliorate [boredom] because you don’t get so completely inured to one aspect of the project. You may work on that for a while, but then you’re in a totally different area, so that it becomes a little bit more novel. I think that’s probably a pretty good way of going about it. Maybe not necessarily pair programming, but certainly having different roles to play in a project.
If it’s a very large project, I’ve seen a lot of teams that will rotate out programmers to work in quality assurance (QA) for a while and see the other end of the spectrum or be more closely allied with the end user’s requirements, elicitation, or whatever, but something just to literally break up the monotony of sitting there and writing the same bit of the same report module for two years in a row or whatever it may be. Variety and novelty is really the key there.
If you’ve got real experts that get bored very quickly, it might be profitable to actually swap them out between entire projects on some periodic basis. If you’ve got some hotshot you just can’t keep ahead of and he’s churning out code so well and so fast and you can’t keep him engaged, give him a day [or] a week to go work on some open-source project and donate the results to the Web. It’ll keep him engaged and interested and [he won’t] leave your company and you’re not actually losing any real productivity ’cause they’re such hotshots to begin with. In extreme cases, you can look to doing something like that.
Ed: The attributes you’re describing seem like desirable character attributes. But there is a flip side to it. How do you tell when someone is actually like that or they just get distracted real easily? They don’t necessarily achieve true mastery. They just get tired of working on it.
Andy: Well, that’s a good question. That’s more towards burnout than boredom, really, and there’s a distinction, because if you do have someone who’s fairly well skilled, they can be subject to burnout just as well. They’ve been looking at the same thing over and over again and they’re just tired of it, and that’s where just rotating people among different roles, even within the team, is probably useful. Nobody wants to work on the report module for a year straight. If anyone did, would you want them to? That sorta would be a danger sign. If somebody says, “No, I’ll just stay over here in the corner and work on this little piece all the rest of my life,” that’s probably an issue.
Ed: Say you’re hiring someone. Is there ever a case where it’s a desirable attribute to have someone just stick with one thing for a long time, or is it always a danger sign if someone is like that?
Andy: I think it would almost always be a danger sign. I’m sure there’s probably a counterexample somewhere, but, in general, I want developers working for me that have an insatiable curiosity.
Ed: I think it’s important that this insatiable curiosity be focused inward as well, increasing self-awareness. How important is it as a software developer to be aware of one’s own ignorance?
Andy: It is absolutely vital. That’s a real, real important thing. You know, understanding our own limitations, understanding the constraints that we’re operating against, whether it’s our ignorance or the situation, that’s a real -- that’s a real, real big thing. It is absolutely vital to know what you don’t know and to be okay with it.
It’s just that people have a lot of difficulty answering a question with “I don’t know.” That’s a perfectly valid answer, yet it shouldn’t be your final answer on the subject by any means. All too often, I’ll see folks in a
corporate environment where the culture is such that they can’t say, “I don’t know.” So they make something up or they do some waffle words around it or the famous politician thing of [saying], “Oh, we’re having a blue ribbon committee look into that.” That’s just nonsense. That doesn’t really help anyone. I’m a big fan of saying, “I have no idea. I don’t know how that works, but I’ll try and find out.”
Ed: How much time do you spend in a meta-cognitive mode, being aware of your own thought processes and how you are interacting with the world around you?
Andy: Not as much as I should. For me personally, that’s one of those things that just varies as life moves on. When I can [go meta-cognitive], things work out better, and when I get crushed under time pressures and
scheduling pressures and I don’t [go meta-cognitive], things tend to go a little bit worse.
One of the things that we’ve always advocated in our books and seminars is to set something akin to an alarm clock to interrupt you periodically. Every couple of hours, stop what you’re doing, get out of the mud for a minute and take a deep breath and re-evaluate: “Does what I’m doing even still make sense? Am I still on the right track with this or do I need to adapt and adjust a little bit?”
Ed: Forced meta-cognition.
Andy: Yeah, exactly. And it really needs to be interrupt-driven, because if it’s a sure thing, where if you said, “Okay, tomorrow at eight, I’m gonna take stock and take a deep breath and evaluate stuff,” that doesn’t seem to ever work. It’s one of the few things that’s better interrupt-driven.