Tips for Attending a Hackathon as a Programming Newbie

Our annual hackathon, Hack&Roll, is coming up at the end of this week. If you’re a freshman, or new to programming, you’re probably wondering if you should join it. You barely know how to program, after all, much less build apps — why join a competition filled with people with way more experience than you?

Well, here’s a secret: there are typically two reasons developers join hackathons. The first reason — as you suspect — is to compete (and there are people out there who optimise to win hackathons). But the second reason developers attend hackathons is to use the event as an excuse to work on personal stuff. It may be true that you’re not prepared to compete by building apps. But the second reason applies just as well to new programmers as it does to more experienced ones.

When seen in this light, a hackathon is a great place to learn to build stuff. You’d be sitting in a place filled with programmers, just like yourself, with food and drinks, a highly charged hacking environment, and the concentrated air of a hundred people trying to create something out of nothing.

There’s a spectrum for learning, of course. You could, as a freshman, join as a team and have everyone learn enough to complete an app by the end of the 24 hours. You could, with a group of friends, finish various programming challenges during the hackathon. Or you could just hang out, with a learning syllabus of your own creation, and challenge yourself to complete everything on that list by the end of the competitive period (see below for suggestions).

Regardless of what your goals are, you get food, drinks (including coffee - so very useful), music and company, as you work towards them. And as an added incentive, if you do build an app as a team of freshmen, we have a ‘Best Freshmen Effort’ spot prize to reward newbies dedicated enough to come and learn. (Teams of 1, and pre-university students qualify as well.)

Suggestions

2) Learn a web programming framework. You could use one of the following syllabi:

Complete the Rails tutorial. (It includes all the major elements of writing a web app, including deploying to a server). This syllabus teaches you: exposure to Ruby, Ruby on Rails, a good primer to Test Driven Development, understanding the Model View Controller design pattern, exposure to basic Git and a really basic Git deployment workflow, and basic HTML/CSS.

or:

1. Learn Django by following the official Django tutorial. Your goal is to create a Django-based website by the end of the hackathon. (Also see: this link).
2. Learn Git by reading the Git book, chapters 1-5 (and skip chapter 4). Install Git on your machine.
3. Set up a GitHub account, if you haven't already. Push your Django project to GitHub.
4. If you have time, buy some server space on Digital Ocean (which is really cheap), figure out how to set it up according to one of the Digital Ocean guides (for instance, here's the Ubuntu server setup guide).

3) Solve the first 40 problems of Project Euler, in a language of your choice. (Various solutions exist online, feel free to determine the rules of your own challenge).

Celebrating Hacking

We’d love for you to come drop by — whether you’re new to programming, or you’re experienced and want a shot at the prizes. For more information, and to register, visit hacknroll.nushackers.org.

In memoriam, Aaron Swartz

(This post is written by Eli, a former President of NUS Hackers.)

Aaron Swartz was my hero. He died two days ago, committing suicide at the age of 26, too early in a colourful and accomplished life, and now, too late.

I won’t cover all that he has done; people who know him personally have written extensively about his life and his accomplishments. The best pieces to read about him in the wake of his death, in my opinion, are this, this, this and this.

(Suffice to say, it’s highly unlikely that you’ve not used something he’s touched: he co-wrote the RSS spec at age 14, worked on early Reddit, and created web.py, the design of which later influenced Google’s App Engine.)

To me and a few of my friends, however, Aaron was a hero; someone we worshipped who was not too different from us, but smarter, braver, and justifiably more accomplished. His work was proof, I thought, that anyone could - with enough energy, and judicious use of technological leverage - make a significant dent in the world. (Later, at NUS, I shared his essay on Dweck with a few friends. It changed the way we thought of ourselves.)

Most importantly, however, Aaron didn’t wait; he had the audaciousness to do things regardless of his circumstances. He had the audaciousness to try.

I met him briefly at an ebook conference I was speaking at in 2011. I had, for a couple of years, gotten brave enough to do things as he had. I shook his hand and acted like the idiot fanboy I was; this was in the middle of the JSTOR proceedings. I had always believed he would win the trial. I also thought that he would then go on to do other great things, and that one day, potentially, I might be able to work with him on something. I never even told him how much his work meant to me.

Now none of that will ever be.

The lesson I took away as a teenager, following Aaron’s life, is that you should start trying to change the world today. Making a dent is no longer impossible when seen in this light; the question becomes: given that I am a student, a teenager, someone living in Asia, what can I do given my circumstances to help solve problem X?

The results, if Aaron’s work is anything to go by, is that you can go pretty far if you just try.

Tim Berners Lee wrote the most beautiful eulogy I’ve ever read for Aaron:

Aaron is dead.

Wanderers in this crazy world, we have lost a mentor, a wise elder.

Hackers for right, we are one down, we have lost one of our own.

Nurtures, carers, listeners, feeders, parents all, we have lost a child.

Let us all weep.

nushackers.org will be black for the next few days, in memory of Aaron Swartz.

Death and Passwords

I was discharged from the National University Hospital this morning, after rushing there in a Campus Security car at about 1.30am. I got stung by a bee and developed an anaphylactic reaction in about 15 minutes: couldn't breathe, rashes, slight shivering, all from a 2-second, extremely minor bee sting. It wasn't a life-or-death situation by any means (although I now know that having multiple bee stings would probably escalate into a life-or-death situation very quickly), but it got me thinking again about death and passwords.

In the event of a death, what would happen to my digital property? My photos, blog posts, emails and source code will likely rust in the ether of cyberspace, visible but inaccessible to my friends and family.

Worse, the organizations that depend on me would likely hit a set-back. The NUS Hackers domain and site, and the Pandamian code and site for instance, are locked under my GoDaddy, Webfaction and Linode accounts, respectively. My passing would mean no easy transfer of domains, risking the loss of these sites forever.

There should be a way to hand my digital identity out to the people I love and care for. One mechanism used to do this in the past would have been through law firms. I could theoretically will an envelope containing a stack of passwords to my friends and family after my death. But that's a fragile process - and I'm likely to change my passwords every few years or so.

A better solution might be via software. I could, theoretically, write a program that expects a response from me once a year. If I don't respond to its email prompt within one week, it emails a package of passwords (or some other arrangement - perhaps an archive of photos, thoughts and memories, in addition to passwords?) to my loved ones, in order of importance. The organizations that depend on me would naturally get all the necessary files, code, and credentials necessary for a smooth transition.

It seems like a pretty neat way of making sure I preserve my digital identity, fragile as my life is. It may not be important in the grand scale of things, but it would certainly ease my passing for those that were close to me.

Implementation details (i.e. where the program would run, how it would keep running for at least a year after the death of the person) is left as an exercise for the alert reader. I'm sure it would be a fun problem to solve.

Do We Need A New Richard Stallman?

A heretical thought struck me recently, while at a dialog session with Free Software founder Richard Stallman. Could it be that the Free Software movement is — today — irrelevant? This notion is repulsive: we owe so much to rms’s multi-decade crusade for Software Freedom and universal digital liberties.

Once I got over the initial revulsion, however, I realized that there is a small kernel of truth in the idea. The biggest dangers to digital freedom today is no longer with proprietary software (vs Free Software) — arguably, it is with addictive, networked applications that collect our data and hold us hostage to their services.

What do I mean by hostage? Well, if Facebook were to turn evil in the future, you do not really have any alternatives. You cannot say: “I will take my data and my friendships and go elsewhere” because the truth is there is no elsewhere. The alternative is to live without Facebook, which is to live without all the benefits that social networking has given humanity. This is not a real alternative after all.

Social networking services matter to us because the Internet is quickly becoming a defining social structure of our lives. If a regime were to crack down on its people, Facebook (or services like it) will likely be a tool used by that Government to control its people. More control makes regimes happy; the Gestapo would probably be very pleased with Facebook. It is, after all, the biggest directory of Jews on the planet.

But it’s not just crazy extreme scenarios that we should think about. You’ve probably heard of the dangers of giving your information to big companies. As an example, you might buy a wig from one website, and read a few articles about chemotherapy on another. Taken separately, these pieces of data say little about you. But if that data is combined, a person may deduce that you have cancer. This is a breach of privacy. It doesn't matter if you don't mind people knowing; you should still be given the choice to withhold that information.

Addictive, networked applications compound these dangers. You willingly give your data because the application is addictive, and the application is allowed access to different facets of your digital life because it is networked. And there’s no good way out of it.

Trying to get out of Facebook, for instance, is an interesting experience. When you attempt to delete your account, it throws pictures of friends in your face. “Tom, Bob, and Alice will miss you!” it says. This doesn’t strike me as good behavior. In fact, it smells slightly abusive, as if the service were holding you hostage with your friendships. If you wanted to, you should be given the choice of taking your data, your friendships, and your profile information with you. And you should be able to use that data in an alternative social network, the same way you may switch email providers or telephone providers, but still keep your your email address and phone number. This is fair to you as a consumer. You shouldn’t be punished because you are choosing to opt-out of Facebook. [1]

Stallman does not see this as something directly related to the Free Software movement. “What is the Free Software movement’s response to addictive, networked applications?” I asked. “That’s a meaningless question.” he said, “That has nothing at all to do with Free Software. It’s like asking ‘what does animal cruelty have to do with computers?’ I may have an issue with Google using non-Free Software, and that’s a valid Free Software objection. But the issue that you’ve described is a different thing entirely.”

And then, almost as an after-thought: “The answer to this is to store your own data, instead of storing it all on Facebook.”

Perhaps we need a Richard Stallman for the Internet.

When Stallman saw that proprietary software was threatening the hacker culture he grew up in, he responded by creating a credible alternative. It took him a few decades, and a couple hundred people, but he did it. Similarly, we may need someone to create a credible alternative to Facebook.

This is a lot harder than it seems. Stallman’s primary challenge when writing the GNU operating system was technical: it took a lot of man-months to write an OS from scratch. But if the resulting software was technically superior, hackers would eventually flock to use and contribute to it.

Writing an alternative to an addictive, networked application is a lot harder. Even if you were to produce a technically superior social network, you’d still have a hard time convincing people to join it. And why should they? Their friends are all on Facebook. This is what we call a network effect. [2]

You wouldn’t be done if you solved this problem, however. To truly protect Freedoms, you’d still have to come up with a protocol for importing and exporting friendships, and photos, and personal information. Ideally, you should find a way to convince Facebook to implement this protocol — something that’s going to be hard to do. And on top of that you’ll want to write a distributed social network that’s as bug-free as is feasibly possible.

The good news is that hackers are already making some headway on this problem. The open alternative to Twitter is Identi.ca. The open alternative to Facebook is Diaspora. If you are a hacker who cares about such things, you should probably consider contributing to both projects.

The bad news, however, is that neither have figured out a way to solve the network problem. While they are still busy building out their platforms, Facebook and Twitter are growing at tremendous rates. Every new user they add to their site increases the overall value of their network; making it harder for new social networks to challenge existing giants.

So the network problem is a big one. But I don’t think it’s impossible to solve. Paul Graham suggests that the right way to solve a big problem is to approach it indirectly. The way to create an alternative social network probably isn’t to say that you’ll create an alternative social network. The right way is to probably say that you’re building an about.me.

A Stallman For The Internet

Let me go back to the original assertion of this essay: “what if the Free Software movement is irrelevant?” It isn't, of course, not entirely. But I do believe that the biggest threat to our digital freedoms is no longer in the realm of proprietary software. If anything, it lies now in the realm of unfree data.

My generation needs a Free Data movement, just as Stallman’s generation needed a Free Software movement. Free Software has arguably made the world a better place: better for programmers, and better for users. Free Data is but an extension: the same principles, applied to networked applications in a networked world. The challenges are different. The liberties at risk are the same.

Here’s one last thought: in 1983, people needed Stallman to show the way. We’ll probably need someone like that today. I hope we find him soon.

[1] A logical extension of this argument seems to be: social networking is so important that it should be a public utility. But that's an idea for a different essay.

[2] To be exact, this is known as Metcalfe's Law.

Hacking: The Best Way To Get Hired, While At SoC

If you’re a School of Computing student, you’ve probably been told that the best way to get good at programming is to ‘just keep practicing’.

And this is true. We know this is true because musicians, painters and writers say the same thing; why should it be any different for programmers? Programmers get better when they program — with one unique difference.

The difference is this: code projects, the by-product of ‘programming practice’, are great additions to any resume. Employers will be able to read the code you’ve written. If they care about the kind of software you will produce for them, knowing how well you code matters.

Computer Science professor Matt Might argues:

Having emerged from engineering and mathematics, computer science programs take a resume-based approach to hiring off their graduates.

A resume says nothing of a programmer’s ability.

Every computer science major should build a portfolio.

A portfolio could be as simple as a personal blog, with a post for each project or accomplishment. A better portfolio would include per-project pages, and publicly browsable code (hosted perhaps on github or Google code).

Contributions to open source should be linked and documented.

A code portfolio allows employers to directly judge ability.

GPAs and resumes do not.

Building a portfolio is something we should all be working on. (Matt Might links to MIT student Ed Yang, whose personal portfolio is staggering in its impressiveness).

So the question becomes: what should I practice on? Programming assignments are tedious when done outside class, for no credit. There are only so many Project Euler problems one can solve before getting bored.

The answer, of course, is to start hacking.

There are a number of reasons to hack, all of them good ones. I think it would do to share some of them here for posterity. I’ll end with a number of things you can start hacking on, and one place, next week, where you can do it with your friends.

Hacking exposes you to real world technology

No, professors and employers expect us to pick up production technologies on our own. They teach us the ideas — we’re supposed to use those ideas to learn whatever it is we need for our jobs. Sometimes that means learning Python over the weekend. Other times it means learning enough C to debug the bloody PDF library that seems to print a puppy over every document you try to generate.

Most importantly, however, it means that the student who spends his weekends and holidays picking up production-ready technologies is a step ahead when compared to his peers.

Hacking makes you better

After which you become slightly better.

Hacking forces you into situations where you don’t know enough to begin building things. If you want to build a blog on top of MongoDB, for instance, you might begin by learning a web framework. After which you would need to learn to use Linux, because 99% of websites run on Linux. Learning Linux will enable you to install MongoDB and set up your web server. Then you’ll quickly realize that you’ll need to learn how to use a wrapper for MongoDB, which in turn will teach you how to find and read obscure documentation for a programming project.

Every trivial hack project brings with it a hidden cascade of things to learn. This is a good thing: it means you get to learn more the more hack projects you do.

Hacking puts you in touch with actual developers

But hacking on your own projects are also a good way to meet other developers. If you’re solving someone else’s problem, he or she may find you on GitHub to contribute to your code.

Again, this teaches you things you might otherwise have to wait for graduation to learn.

Hacking gives you projects to show

The latter is sometimes more important than you might think: many a programmer has built a world-changing tool with the partial intention of showing it off to his friends. Facebook and Linux certainly started with some element of this.

Hacking is good for you; start hacking today!

It’s not hard to start hacking - pick a problem you’ve always had, and think about how you might solve it with code. Alternatively, pick a cool new technology you want to learn, and find a way to use that to solve your burning problem.

If you’d like to get a head-start, come join us at our Hack & Roll Hackathon, on the 19-20th February. Sign up here, or read more about the event at this link. We’re trying to get more SoC students to hack on stuff, so if you’d like to learn how to start doing so, in the company of your peers, come join us. It’s only $10 per person, and even then for food.

In the words of a much-loved SoC lecturer: happy hacking!

PS: if you like this post, please consider sharing it with a friend!

Ideas, Meet Skills! Not.

There’s this idea that gets passed around a lot in the entrepreneurship clubs in NUS. The idea goes that technical people need ‘ideas people’, and that entrepreneurship clubs exist to matchmake the two.

Take, for instance, the recent Ideas Meet Skills event by the Startup@Singapore team. The event is made in good faith, but the assumption is there in all its glory: ‘Have a great idea you want to realize or the gumption to excel in a start-up … but not both?’ the poster declares. ‘Register Now!’

(An organizer told me that such events are almost entirely full of business people; it has been very difficult to get technical people to come. And no wonder - with a mistaken premise, is it any wonder when technical people fail to turn up?)

This assumption is more pervasive than one would expect: in my short time in the NUS Entrepreneurship Society (NES), I have heard all sorts of people express it. What took me by surprise was the number of Engineering students who subscribe to this belief. One would think that people from Engineering would be careful about making such assumptions, given the number of jokes engineers make about working under the tyranny of a technically naive, pointy-haired boss. But no, they express it all the same.

The idea is wrong on at least two assumptions. The first assumes that technical people have no ideas (or that they have bad ones). The second assumes that technical people need ideas people to do things. Disprove the first assumption, and the second automatically follows as false.

It is easy to show that technical people have some proficiency with ideas: if they were no good at them, they would not have entered a technical course in the first place. Getting a programmer to come up with ideas for startups is no more than one conversion process away: you simply have to show him how.

What is more interesting to ask is this: are business people better at coming up with ideas than technical people?

The answer to that is: not usually. The key difference between programmers and business people is that programmers can test their ideas, and business people can’t (or at least won’t). That testing process is called hacking.

Joshua Schachter said it best in his Founders At Work interview:

Livingston: What do you think about technical founders versus businesspeople founders?

Schachter: I have never had a great deal of trust for people who don’t execute on core ideas. I understand the value of needing someone to deal with that kind of stuff — someone’s got to do the VC pitch and there’s got to be a CFO, etc. But the guy who says, “I have a great idea and I’m looking for other people to implement it,” I’m wary of — frequently because I think the process of idea-making relies on executing and failing or succeeding at the ideas, so that you can actually become better at coming up with ideas. It’s something you can learn. It’s a skill, like weightlifting. That failed; that worked; continue. You begin to learn how to make ideas. So if you are someone who can’t execute and all you can do is come up with ideas, how do you know if they are any good? You don’t really know if it’s a good idea until you’ve executed it. You need to understand the cost of execution and so on.

When seen in this light, a majority of NES’s entrepreneurship efforts fail to make sense. Ideation workshops are exercises in futility, as they have no hope of real world verification; ideas-meet-skills events fail to attract the people with skills, because the people with skills don’t need such workshops.

It is true, however, that you don’t have to be a technical person to test ideas. Hacking is simply the easiest, cheapest way to do so. You can - like Derek Sivers (CD Baby) and Jason Fried (37signals) - test ideas by hiring programmers to implement products for you, and then learning from those successes or failures. Or you can spend an adolescence tinkering with electronics like Steve Jobs did. But because such methods are more expensive than simply hacking something up, business people tend to stay idle.

In truth, I suspect that the people in NES don’t really believe that technical people are bad at ideas, or that they are lousier than ‘ideas’ people. I suspect they keep at it because it’s much easier to attract large audiences with the lie (‘come do a startup if you have an idea, it doesn’t matter if you can’t execute on it!’) than it is to convince hackers to do startups.

What is the solution to this? The answer is obvious: grow the community of hackers, and then tell them to start startups.^[1] Every year, Y Combinator does something called Startup School - an invitation-only event for technical people, designed to inspire them to take the leap into startupdom. The talks are amazing. The effects even more so. (The sign-up page states that ‘Many founders have told us that this event was what finally made them take the leap.’) And while business people are allowed to attend, hackers have priority.

Perhaps it’s time to start focusing on hackers in Singapore. After all, there are already too many ‘ideas’ people out there: attending workshops, sitting in conferences, pitching business plans - and going nowhere.

^[1] The first is hard, something we at NUS Hackers are still trying to figure out. The second is easy (and can best be done by NES) but will probably have limited effect until the first problem is solved.

This essay was prompted by a recent request to get NUS Hackers to promote more ‘ideas + skills’ events - in particular, to get our members to join such workshops. The coreteam - myself included - reacted with knee-jerk negativity. This reaction, to me, was curious: we could not articulate a proper reason for it, yet we all felt very strongly against it. This essay is written as an attempt to figure out why.

Build Random Shit For Fun, Experience, and Glory

A few days ago I realized a simple summary of what we do at NUS Hackers (if you subtract away all the marketing) is: get people to build random shit for fun, experience and glory.

It reads like a good motto to me. Let’s break it apart to see what it means:

1. ‘Shit’ is random because it’s not fair to just build useful stuff. Sometimes fun, throwaway projects are worth doing, because they give you new ideas.

2. Building stuff for fun is important because programming should be fun. (If it isn’t fun and you’re in Computing then you might have a problem.)

3. Building stuff for experience is equivalent to ‘practice makes perfect’. We are told in school that the best way to become good at programming is to do lots of it. But building personal projects is also a rather useful trick to learning new things - for starters, you’ll bump against a lot of production-ready tools that you might not otherwise need when solving school-created problems. Also, building stuff is sometimes a good excuse in itself for learning new tools - e.g. the unofficial CORS API was used as an excuse to learn and deploy MongoDB.

4. Doing it for glory is a raison d’être for NUS Hackers. The respect and attention of a close community is a powerful motivator for any student programmer. If we succeed in creating such a community, we will give our peers a reason to build things for their own benefit. Everyone wins in that scenario.

I think we’re 2, 3 years our from achieving this. We have a lot of work ahead of us.

Why every undergrad should intern for a startup at least once.

My first post here =D

So, I wrote a post here on my blog, and yep, was asked to blog about it here as well.

So, why should you, as an undergrad intern at a startup?

The truth is, it may not be for everyone. Those who have already decided that they want to work in an investment bank and climb his/her way up the corporate ladder, well, working at a startup is definitely not for them. I’m serious. Now that I’ve gotten that out of the way, this is what my boss has to say on working in a startup.

If you want to be an employee and want a nine to five internship, don't join a startup.

You should only join if you want to learn something and enjoy the process of being challenged and being put in the forefront of things.

And I think that is damn true. So, despite what the title says, working in a startup is NOT for everyone. So why should people who don’t fall in the ‘corporate’ category give the startup route at least a try some time in their uni life? (Note: by startup route, i don’t mean starting a company. it can be just working at a startup)

Very simple. 3 reasons.

1. You learn alot.

I’m currently working at Chalkboard, and heck, I’m learning ALOT of stuff, and getting exposure to alot of stuff as well, from the basic stuff like tech, where I learn python/django, and write more javascript than I’ve ever written, to sales and marketing, where they actually let me interact with the clients. Yes. They let me interact with the clients. How cool is that?

Now, will you get that at an MNC? Will they even let you touch major clients with a ten foot pole?

<li><strong>You think alot</strong></li>

They actually give you quite abit of freedom to do stuff, often with little oversight. What this means is that you don’t get to report to some pointy-haired boss what you have been doing once every 2 hours. And what this actually results in, is that you have to think about how are you going to go about doing your job, because NO ONE is going to tell you,

• step 1, do this
• step 2, do that
• ...
Now, there will be people who don't like this, that's why I said, working at a startup is not for everyone.

<li><strong>You don't have fixed work timings</strong></li>

When there are things to rush, you stay on and work. When there’s an emergency, you stay on and help to fix it. At a big company, you’re not expected to do that. After all, you’re just an intern. But at a startup, you are expected to help respond to emergencies. And as a result, you often get off work late =P. But you have fun in the process. Really. I go home after 6:30pm everyday, even if there is nothing serious that needs my attention going on.

To summarize, you(ok, I) have so much fun and freedom working, that I voluntarily stay on extra to do abit more work. But on a more serious note, there is more benefits to working at a startup, than just the fun and freedom.

Now, startups have limited budgets(other than Color), so generally, if you are not up to standard, there’s a very low chance they’ll let you stay on or even work there the next year. What this means, is that if they want you to go back, or if you manage to get back the next year, there’s a high chance you fall under the Smart and Get Things Done category. Guess what that will do for your resume?

On the other hand, in an MNC, there’s more noise lying around, so your contributions won’t be that obvious. And that’s IF you get to do work at all.

So, what has Chalkboard been letting me do that makes me so damn happy working for them? They let me do the stuff that I find important, such as improving usability, and making the lives of developers and content publishers using Chalkboard products easier. And my stuff get pushed out there into the real world. (Check out the beautiful widget on the top right corner of my blog. I did that.) My ideas get heard. And we are working on helping developers get the data they need. In fact, we have some exciting news coming up in a couple of weeks to empower developers to do what they do best. Follow me @laurenceputra to get the news =D

So, what next? Now you’re convinced to go join a startup next summer, where do you start? There is an awesome program called StartupRoots that matches students to the top startups. They organise talks for their fellows to attend, and these talks are by people like Jeff Jonas & Ian McFarland, chief scientist at IBM and ex-CTO of Pivotal Labs respectively. In fact, this program is so awesome that I’m in it. They managed to get me out of my self-imposed 3 month retirement.

So, what do you think? Should most students try interning at a startup at least once in their uni life?

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

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.

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.

(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.

NUS Hackers: What We Do

This was adapted from a short introduction I did at the beginning of CodeCom 2011. Intended purpose: to introduce people to NUS Hackers, seeing as we had recently undergone a name change. I thought I’d put it up here, as well, just so we’re clear.

Just two days ago, the School of Computing sent all of us in NUS an email:

Title: The Hacker's New Target: Your Internet Application

Abstract: Hackers today know you have firewalls so its hard to hack the network-infra. But they still want to steal or compromise your data …

Anyway, I’m here to tell you a bit about what we do, and maybe a little bit of what hacking is, so you don’t go home and tell your friends: ‘oh, I just went to CodeCom 2011; it was organized by this bunch of evil hackers.’

What We Do

‘Well, what’s this hacking thing?’ you may ask.

The simplest explanation for hacking is: ‘playful cleverness.’ Like you’re writing this big chunk of code, and I take a look at it and reduce it to 3 lines. It’s clever because I’ve reduced it, but it’s playful because I had the audacity to question the way you thought about your code - and take a step back to think about it.

(Okay I realize that’s a terrible analogy. A better explanation of what hacking is can be found here)

Hypothesis #1

Every great innovation in the history of computing has happened because of a hacker, or a hacker community.

Alright - if you don’t believe me - very quickly:

Linux. Linux was created by this 21 year old kid, Linus Torvalds, because he was bored and he wanted to read news in a terminal in his bedroom.

Steve Jobs and Steve Wozniak were members of the Homebrew Computer Club, and they started out selling hacker blue boxes.

Bill Gates had been programming since high school, with a bunch of friends who were all mad about it. He would climb out of his bedroom window at 3am in the morning and sneak to the University of Washington to use the faculty computers.

Ken Thompson and Dennis Ritchie - that’s them at the PDP-10 there. Ken Thompson was sick to death of working on the Multics operating system, so he decided to write this portable OS called Unix instead. And as a result we got the Unix design of operating systems, and we got GNU, and we got the C programming language.

CERN was the lab where the world wide web was built. And while the Internet wasn’t a hacker-initiated project, it was built by hackers, and the Internet as we know it today was the result of this hacker who got bored and wondered what would happen if he sent an electronic message through the early network. And so we got email.

Mark Zuckerberg was a hacker. Before Facebook he wrote this MP3 player to select music based on what you liked, and he gave it away for free, online. Why? Because he was bored.

And yes, some of you are smiling: if you notice a pattern here, it’s true. A lot of these people were bored. And what happened? They began programming these little side projects for fun. And that programming led them - sometimes by chance, sometimes with foresight - to working on things of real importance. (It’s almost uncanny, in fact, how often these things happen).

Hypothesis #2

Here’s the second hypothesis, which we think is true:

The best way to create a hacker culture is to create a community.

If you’ve got a project of your own, or a startup, or an open source idea you want to get working on (or if you’d just like to learn things), then we’d love for you to come to us. We would support you: whether that support means hacking with you, or hosting your code, or hooking you up with engineers who know better than we do. And we plan on being this support system for hackers in NUS, because we think that’s a powerful way to spread the hacker culture.

Three Things (To Close)

The first is that we learn a lot from one another. And this is obvious: when you put a bunch of smart people together, it’s very unlikely that you won’t learn something from the guy sitting next to you.

The second thing is that we have quite a bit of fun. And you probably already know this, being here at CodeCom: this programming-for-fun thing gets really addictive, really fast.

And the third thing - well this is a little hard to prove, but we already have some indication of this: we’re getting quite a number of opportunities. The people in NUS Hackers tend to be of a certain caliber - like … Div over there, who does Linux sysadmin stuff on the side, for fun, and gets paid for it. Angad over there, who’s our president, once overclocked his phone when he was 13. And it burned up in his pocket. He’s going to NOC next academic year, by the way. And last sem I was in San Francisco, giving a talk to the people who’re responsible for today’s ebook formats, because I’ve been doing ebook work for close to four years now (I do a lot of ebook work).

So we get a lot of people talking to us. They’re either from startups, or they’re from bigger companies, or they’re from these startup-related organizations, and they come to us and say that they’d interested in meeting our members. Which we think is rather cool.

Here’s what we know, in a couple of seconds: we know that there are tangible benefits to having a small group of good hackers, and we think it’s worth it to grow this small group into something bigger. We want more people to program for fun, because we think that’s very, very important. (We’re doing that right now, at CodeCom!) And we plan on doing that for a few more years.

Thank you for coming.