2004-08-05 03:17:26
Great Hacker != Great Hire
I thoroughly enjoyed reading Paul Graham's recent essay Great Hackers. His sermon is well-written, and I assume it played very well when he preached it to the choir at OSCON.
Graham describes the notion of a "great hacker", which he seems to roughly define as a programmer who is several times more productive than average. (Please note that some people use the word "hacker" to describe programmers who engage in illegal activity. That connotation is not applicable here or in Graham's essay.) He then asks the following questions:
How do you recognize [great hackers]? How do you get them to come and work for you?"
Note carefully: Graham proceeds from the assumption that we do in fact want to hire these great hackers, but he never explains why.
I concede that this assumption is intuitive. After all, doesn't every company want the most productive employees they can hire?
But this assumption deserves to be examined and challenged.
For the love of the code
Graham begins his description of great hackers by explaining the intrinsic motivation and passion they have for writing code:
Their defining quality is probably that they really love to program. Ordinary programmers write code to pay the bills. Great hackers think of it as something they do for fun, and which they're delighted to find people will pay them for.
On this point, we agree. The best developers simply love to create software. They get paid, and their compensation is important, but it isn't really the primary reason why they write code. They wrote code before they were getting paid for it. They would continue to write code even after winning the lottery. When I hire developers, I am looking for this quality.
However, the remainder of Graham's essay does a pretty good job of explaining why many small ISVs might not want to hire a "great hacker". In a nutshell, great hackers are often very fussy people.
Fussy about tools and platforms
Graham explains the well-known fact that great hackers are extremely picky about the tools, platforms and technologies they use:
Good hackers find it unbearable to use bad tools. They'll simply refuse to work on projects with the wrong infrastructure.
Bad tools? Wrong infrastructure? Graham sounds like he is right on the money. Nobody could object to the idea that great hackers care deeply about these kinds of choices, right?
Unfortunately, Graham goes on to explain what great hackers mean by "bad tools" and "wrong infrastructure". Painting with a very wide brush, he observes that great hackers don't use technologies like Windows and Java. They prefer languages like Python and Perl. They prefer to use open source technologies whenever possible.
I'm not saying I am a great hacker, but I do sympathize with this fussiness. I have similar religious preferences about technologies. I really do like Python. My personal server runs Debian. The first things I install when I repave my Windows machine are emacs and cygwin.
However, I work at an ISV. I love building software, but SourceGear is not my hobby -- it is my profession. We sell products to users. We have learned to value the needs of the users over our own preferences.
Graham seems to suggest that if we choose to build our products on the technologies that great hackers prefer, then it is more likely that we will be able to hire them. This opinion may be true, but it ignores the fact that technology choices have marketing implications. I've written about this topic several times now:
Law #21: "These may not seem like marketing decisions, but they are. Technology choices have big marketing implications. When you choose a platform, you define the maximum size of your market."
Geek Gauntlets: "We need to talk about what customers want, but our own preferences get in the way. We bring our technology prejudices and biases to the discussion, often without ever being aware of the problems they can cause."
Be Careful Where you Build: "As developers in a small ISV, our productivity is important, but it must be secondary to the comfort and preferences of our users."
The higher productivity of a great hacker is a big advantage, but probably not big enough to overcome our attempts to sell something that users don't want.
If Graham is right, a great hacker is someone who believes that his own preferences are more important than doing what is best for the users. Small ISVs don't need people like that.
Fussy about doing interesting projects
Graham goes on to explain how important it is for great hackers to be doing interesting projects:
Along with good tools, hackers want interesting projects. It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that's full of bugs.
Here again, I am sympathetic. I like interesting stuff too. My To-Do list tells me that I am supposed to be working on some enhancements to our online store website. Frankly, that programming task doesn't interest me very much. I'll confess that I'm procrastinating on that particular task.
However, I work at an ISV. I love building software, but SourceGear is not my hobby -- it is my profession. We sell products to users. The reality is that lots of highly profitable software development tasks are just not very interesting.
Graham strikes particularly close to home when he says, "One of the worst kinds of projects is writing an interface to a piece of software that's full of bugs." Our SourceOffSite product provides an Internet-based interface to a piece of software that's full of bugs (SourceSafe). That same product supports integration with IDEs by means of a piece of software that's full of bugs (the MSSCCI API). If we had been great hackers and refused to do this work because it is not interesting, we would have missed out on millions of dollars of revenue.
If Graham is right, a great hacker is someone who is not willing to do any of the un-fun things that need to be done. Small ISVs don't need people like that.
Fussy about interacting with users
Graham characterizes great hackers as people don't want to be involved with users:
Bigger companies solve the problem by partitioning the company. They get smart people to work for them by establishing a separate R&D department where employees don't have to work directly on customers' nasty little problems.
You may not have to go to this extreme. Bottom-up programming suggests another way to partition the company: have the smart people work as toolmakers. ... This way you might be able to get smart people to write 99% of your code, but still keep them almost as insulated from users as they would be in a traditional research department.
This kind of attitude is a big problem in a small ISV. I concede that it is frustrating to be interrupted when I'm working on a coding problem. I concede that users sometimes ask dumb questions. I concede that writing a great piece of code is more fun than figuring out how somebody screwed up their Web.config file.
However, I work at an ISV. I love building software, but SourceGear is not my hobby -- it is my profession. We sell products to users. Nothing here is more important than our users. Nothing.
Last year I wrote an article in which I claim that small ISVs should only hire "developers", which I define as "programmers who also contribute in non-coding ways". The thesis statement of this article said:
"For the purpose of this article, a "programmer" is someone who does nothing but code new features and [if you're lucky] fix bugs. They don't write specs. They don't write automated test cases. They don't help keep the automated build system up to date. They don't help customers work out tough problems. They don't help write documentation. They don't help with testing. They don't even read code. All they do is write new code. In a small ISV, you don't want any of these people in your company."
If Graham is right, a great hacker is someone who is not willing to help the people who use the software he creates. Small ISVs don't need people like that.
Bottom Line
Like I said, I enjoyed Graham's essay very much. He describes great hackers by enumerating all of their worst qualities, and yet, the essay still makes us want to admire these super-productive people. That's good writing.
But the essay causes concern. I worry that lots of small ISVs will read his article and believe that they need to hire great hackers. When great hackers are as fussy as Graham says they are, they're not worth the trouble. We want the super-productivity, and we want the innate love of software development, but we don't want all the extra baggage. Instead:
- Hire people who care about users.
- Hire people who understand the difference between a job and a hobby.
- Hire people who want to contribute in lots of different ways to the success of the product.
It's okay to be in awe of these great hackers. But as a practical matter, small ISVs would be much better off hiring professionals.