How 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).
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:
- Download the source code to the program you want to change
- Untar it on your hard drive
- Get it to build and run
- Open the source code in an editor
- Find the part of the code that you need to change to make the program do what you want it to do
- Make the changes you need to make to the code and test it to make sure it works
- 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. [nat friedman]