[FoRK] great hackers

Owen Byrne owen at permafrost.net
Thu Aug 5 19:40:47 PDT 2004


Another contrarian speaks:
Owen
http://software.ericsink.com/entries/No_Great_Hackers.html

Great Hacker != Great Hire

I thoroughly enjoyed reading Paul Graham's recent essay Great Hackers 
<http://www.paulgraham.com/gh.html>.  His sermon is well-written, and I 
assume it played very well when he preached it to the choir at OSCON 
<http://conferences.oreillynet.com/os2004/>.

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 
<http://software.ericsink.com/Small_ISV_Defined.html> 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 <http://software.ericsink.com/laws/Law_21.html>:  "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 <http://software.ericsink.com/Geek_Gauntlets.html>: 
    "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
    <http://software.ericsink.com/bos/Platforms.html>:  "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 
<http://software.ericsink.com/No_Programmers.html> 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.

 




More information about the FoRK mailing list