Motivations

Over the past couple months or so we’ve had a number of non-programmers contacting us, looking for hackers to hire for their startup/project/idea/next-Facebook-to-be.

The logic goes — and you can almost hear it in their emails — that a university hacker is a good, cheap resource. One particular ad asked us for a candidate with ‘many scholarships, lots of research papers, and we’ll pay you $1000!’ — which might be a joke, but if true ignores the fact that such a candidate would be Google material, for close to $80,000 a year. I find most of these shoutouts rather sad. “Saw the email from x?” I’d sometimes ask Angad. “What do you think of it?” And in fact good ads are so rare that when we get one we rush to post it to our mailing list.

What most of these ads lack is an understanding of hacker motivations. When you’re posting a help-wanted ad, what you’re really asking a potential candidate to do is to weigh the cost/benefits of working for your unknown, unproven startup, when they can:

  1. Code for Google Summer of Code — which is incredibly attractive because you not only earn USD$5000 for 3 months of work, but you also get to work on an open source project (good for your resume); learn several new programming practices; and give back to the world.
  2. Intern with a elite program such as Startup Roots — (which we endorse, by the way).
  3. Code on personal projects — all hackers have one or two on the side, for fun; or
  4. Intern at a bank

But then there’s an added problem. Some people who email us are business founders looking for technical people. And more often than not the ideas that they have are either laughably bad, or of unknown quality. (The only way to make that unknown known is to implement it yourself and see the response. Which is a chicken and egg problem.)

So how do you hire a hacker if you’re not one yourself? One answer is to get the motivations for hacking right. Chris Dixon wrote a post recently titled Showing Up, where he says:

We went to places like the Media Lab and basically just sat ourselves down at lunch counters and awkwardly introduced ourselves: “Hi, my name is Chris Dixon and this is Tom Pinckney and we are starting a company and would love to talk to you about it.” Most students ignored us or thought we were annoying. I remember one student staring at us quizzically saying “startups still exist?” Most of our trips were fruitless. At one point after a failed trip we were on the Redline back to our office in downtown Boston and joked, depressingly, that we felt so out of place that people looked at us like time travelers from the dot-com bubble.

Our first breakthough came after a series of trips when a particularly talented programmer/designer named Hugo Liu re-approached us and said something like “hey, actually I thought about it and your idea doesn’t suck.” Then his friend David Gatenby talked to about joining us. We eventually recruited Hugo and David along with a brilliant undergraduate Matt Gattis. We had finally broken through. Matt and Hugo now work with us at Hunch along with some of their friends from MIT they brought along.

When you’re asking a student programmer to work for you, you’re selling him two things: 1) your idea, and 2) yourself. If you’re not demonstrably smart, or if your project isn’t interesting, then it’s not likely that any hacker would want to work for you. Not with so many other options on the table.

This is, however, a cop-out. The truth is that it’s hard to sell your idea when you have bad ideas, and it’s even harder to sell yourself if you’re not already a hacker (Pinkney, Dixon’s friend, is a brilliant programmer). The non-technical people who start companies and go on to do great things tend to do so with hackers who they’re already friends with. Which leaves us with: if you have bad ideas, or if you have absolutely no freaking clue of hacker culture, than nothing mentioned here will ever help you.

So what can help you? Here are a couple of things that I’ve found to be attractive in a ‘programmer-wanted’ ad:

  1. Know your problem space really, really well. Hackers have finely-tuned sensors for bullshit, because we absolutely hate it, and know it when we see it. This is a function of preferring to build things vs sitting around and talking about them. If you’re not a domain expert in whatever you’re doing — it’s harder to get a hacker interested.
  2. Sell the problem. If you know something really deeply, it’s also likely that you know the problems that people in the aforementioned field need to solve. Problems are very attractive to programmers. In fact, problems are especially attractive to programmers if they’re well defined. Fortunately for you, problems in the real world are rarely as clear as problems in programming puzzles, even if real world problems are ultimately more important. Your job as a startup founder is to make that problem space definable, and then sell that to a hacker.
  3. Sell experience, not money. Most of us are attracted to people who try very hard to solve interesting problems. Some of us — the ones you can hire — think that the experience of doing something like that is more valuable than the money. It helps to take money (as an issue) off the table as soon as possible; know that there’s no way you can compete with Google Summer of Code, or even a bank internship.

In a nutshell: give us interesting problems to solve. Because if you can’t do that, then it’s a signal that you either have a lame startup, or you’re not particularly good at doing startups, or you’re a copycat. And there’s nothing to save you from that.

(Note: notice that ‘interesting problem’ can mean a lot more than a ‘startup that solves an interesting problem’. For instance, travel search engines are boring, but a travel search engine written in node.js (or Haskell, say) is incredibly attractive to a hacker. Unfortunately you have to be a hacker to understand that, and so we’re back at square one.)

Semi-related: why business co-founders should learn to code.

Update: A number of people have observed that point 3 was ‘off the mark’. It’s not. What I mean by it is that you should pay market rate — or enough, whatever that amount is — to take the issue off the table. Don’t sell yourself based on salary; it’s unlikely that you’ll win.

Discuss this article at HN.

  • Daniel

    I don’t see why “a travel search engine written in node.js (or Haskell, say) is incredibly attractive to a hacker”? Just for the fun of it? How would that benefit anyone except the hacker himself?

    • http://elijames.org Eli James

      And that is exactly why you won’t be able to hire a good programmer. ;-)

      • Daniel

        I’m not going to hire any good programmers in the near future. I’m still an undergraduate working my way through university. I do work for a startup, contribute to an open-source project, and participated in GSoC last year. I do believe a good programmer would be able to choose the right technology to aid him in producing running code that solves the problem, not adding complexity by using a tool that is not designed for that kind of problem. I’d agree with “a travel search engine written in node.js” not Haskell.

        • http://elijames.org Eli James

          Daniel, notice that my post does not in any way recommend a change of
          programming language. This is an article about hacker motivations, not
          engineering decisions. i.e.: that certain boring jobs can be interesting,
          give the right technology. (See also this piece:
          http://www.paulgraham.com/carl.html)

          You’re responding to a non-point.

          • Daniel

            Then next time try not to include irrelevant examples in your article. I agree with your idea overally :)

          • http://elijames.org Eli James

            I would suggest that you read more carefully before you respond, in the
            future. The example is anything but irrelevant. There is a huge difference
            between making a recommendation to change your programming language to
            attract interns, and arguing that it is possible for a startup to be
            interesting as a result of its technology stack.

            You seemed to have mistaken one for the other. Worse, you commented on it,
            and argued on what was essentially a non-issue.

    • http://blog.exolimpo.com Kuroir

      Doing it in node.js looks more attractive than doing it on Rails or PHP “for the fun of it”.

      Also note you’re not reinventing the wheel.

      • Daniel

        You’re not re-inventing the wheel by using a different framework or programming languages to solve the same problem?

      • http://www.facebook.com/eric.stern Eric Stern

        Reminds me of the time a friend wanted me to help him build the next facebook (this was when myspace was still a real player, several years ago).

        “Ok, so how is this different from/better than facebook?”
        “We’re going to write it in Rails.”

        Suffice to say, I made the right move in passing on that one. Unless your market is developers, the technology you use is completely irrelevant to your customers. Doesn’t mean that picking appropriate technology isn’t important (it most certainly is), but if it’s not giving you a competitive advantage it’s merely a talking point on Hacker News comments.

      • http://www.rumblingedge.com/ Gary

        “for the fun of it” is a highly subjective term.

        While I would not to add any flame to any fire that might be brewing, I’d respectfully like to point out that I don’t see how doing it in node.js will look more attractive than doing it on Rails or PHP or Python.

        Someone could code in Perl or even my own JS cookbook library and would still feel that it’s fun.

        And that someone would not even feel that such an effort constitutes being a “Hacker” which seems to be prevalent throughout the post.

  • http://www.marketingplan.net Marketing Plan

    I agree with the spirt of your recommendations.

    As someone who is both a “hacker” and a business owner, I think it primarily boils down to answering one question for the person/people doing the work: will the work I do matter and why?

    A few examples from personal experiences:

    * I’ve taken on projects with clients just because it would allow me to create a reusable code-base that I could use for various other projects.

    * The money was good.

    * The people were enjoyable to work with and I expected to learn something from them (usually something non-technical)

    * It allows me to figure out a problem that I’ve been trying to solve that would be applicable to other implementations.

    * The problem was important.

    * It was a favor for someone else.

    * I just wanted to see if I could do it.

    * I wanted to use it as an excuse to learn a new language or technology.

    The reasons can vary considerably… but what’s common is that it takes understanding the person you’re dealing with, their personality type and what motivates them individually.

    Melvin Ram

  • http://twitter.com/fettemama fettemama

    hey, you’re not a hacker. you’re just another startup-millionaire-wannabe. stop calling yourself hacker

  • Guest

    I would think the $1000 is not for salary for the hacker but a referral bonus to you /your group for referring that hacker to them.

  • Aadd

    wtf?