Want to become a hacker?

Monday in a "chatroom interview" in Beijing someone asked me how to become a hacker. (Those of you visiting this web page from the People Magazine article, you should know the term "hacker" here refers to a computer programmer, not an internet vandal).

My interlocateur wanted to contribute to an open source project, but what tools should he use? What books should he read? Where should he hang out? Where should he start?

I've been asked this a few times so I thought I'd repeat my answer here. Miguel tells me he gets this question all the time too, and gives the same answer I do.

So, I'll let you in on the secret. Here are the steps to becoming a hacker:

1. Download the source code to the program you want to change
2. Untar it on your hard drive
3. Get it to build and run
4. Open the source code in an editor
5. Find the part of the code that you need to change to make the program do what you want it to do
6. Make the changes you need to make to the code and test it to make sure it works
7. Run the diff -u command and email the output to the mailing list

That's it; follow those instructions and I guarantee you will be a hacker.

If there are no programs that you want to change, then maybe you don't want to be a hacker after all. Or maybe you haven't used software enough; how can you be a software user in 2005 and not have things you want to change?

Steps 1-4 sound stupid and obvious, but the fact is most people get stuck on step 1. Can you be a hacker if you don't have any source code on your computer? It might be possible but I haven't seen it done.

If you bloody your toes on step 3 a few times, don't be discouraged. It is ridiculous and humiliating but sometimes this step takes the longest and is the most difficult.

If you're lucky, step 5 is as easy as grepping the source tree for some relevant string from the program's GUI or output. It's more likely that you'll need to spend some time figuring out the layout of the code, sprinkling source files with printf's as you home in on the right area. It might also help to step through things in a debugger.

Step 5 gets easier the more experience you have. The more code you've read, the more programming patterns you know. Recognizing programming idioms makes it easier to figure out what someone else was thinking when he wrote the code you're trying to change. Of course step 5 is also easier if the software you're working on was written by a programmer with a lot of experience, who tries extra hard to write easy-to-understand code. Programmers with experience write easier-to-read code because they've been through the shock of having to fix a bug in code they wrote a year earlier and recognizing nothing.

Step 6 is commonly referred to as "hacking" but it's not always the part that takes the longest. If you're trying to hack a change into something big and complex, expect step 5 to eclipse step 6 in time consumption. One of the best hackers at Novell recently spent two months working on a hack involving Wine that ended up being a two line change. So prepare yourself mentally to spend a lot of time in step 5 before you reach step 6, and sometimes to go back from 6 to 5 a few times.

But most people don't reach this point, so if you're at step 6 you can safely call yourself a hacker. Whole books are written on how to do a good job of step 6, so I won't elaborate too much here, except to say that you probably can't be good at writing code until you've written a huge amount of it.

The real key to being a hacker is getting to the point where you're hacking. Without source code, a working build and a working knowledge of the layout of the code, you're not even able to start hacking. But once you know your way around in there and you're writing code and watching the program take shape, well, that's the fun part.

You just gotta get there.