"How To Be A Hacker" is a brief document by Eric S. Raymond, author of The Jargon File. It gives instructions on how exactly to become a 'hacker', beyond basic definitions such as "A hacker is a problem solver." The document does indicate what a hacker is, but the main part of the text describes how one becomes a computer hacker in modern times. I have not sought permission to post the document here, and the document ought to remain publicly available for a great deal of time.

There ought to be a clear distinction in anyone's mind between a 'hacker' and someone who uses computer systems (for instance) to steal credit card numbers. Immediately find and read the document (see address at bottom) if you don't understand. (Someone softlinked Jargon File Disorder; clever, but confusing 'hacker' and 'cracker' is still offensive to a large culture.)

A cursory reading of the document ought to reveal any conflicts with your personal feelings, as it is a very plain, forthright document and not Pale Fire. I have a few nitpicks, but I generally agree with what is said.

The first major part of the text is a list of five principles that you will probably generally agree with. You may take some exception to certain parts, e.g. "Boredom and drudgery are not just unpleasant but actually evil." Also, the principle "no problem should ever have to be solved twice" might be construed to mean "no problem should ever be solved twice, and there is only one correct solution" i.e. there is only one correct Unix, language, desktop, text editor, etc. I think it would be very hard to justify this viewpoint in light of the rest of the document.

The following section, "Basic Hacking Skills", outlines four areas of knowledge and technique that a would-be hacker should pursue. The first two areas are closely related (Unix and programming), but the second two areas might have been better place under the next heading.

In the sections on programming and Unix, ESR does not beat around the bush in saying that you should get a Unix (he suggests Linux or *BSD, with reservations about Mac OS X) and learn to use it. This is principally because the free unices are popular, freely available, and highly hackable.

His advice on learning to program seems a little imbalanced. The greater portion of the section is given to discussing different programming languages (his final suggestion is that you learn Python, Java, C, C++, Perl, and LISP) and saying that problem solving skills derive from knowing how to solve a problem multiple ways. My objection to the section is that it neglects essential bodies of knowledge (such as data structures, operating system design, calculus) that are found mainly in academic circles. Apply "No problem should ever have to be solved twice".

The sections on HTML and English are self-explanatory; I largely agree.

The latter part, on the hacker culture and contributing to the community, is much harder to evaluate. I would agree with what is written there, and only say that there is already a lot of good code out there; finding something useful will be difficult until you reach a fairly high level of skill or knowledge.

The last section, points on style, is much more highly subjective and scattered than the rest of the document. I belive it serves more as a point of departure for shared culture than as a guide to what a hacker should or should not do; in this sense, it may be misguiding to the very uninitiated who reach this section and believe that there is some subtle connection between watching anime and being able to construct an array of function pointers.

I recommend having a look at the document itself, as well as some of ESR's other works, such as The Jargon File and The Art of Unix Programming. (There is probably a very good way to diagram the relationship of all of ESR's writings concerning hackrity; know at least that they are somewhat connected.)

How To Become A Hacker: http://www.catb.org/~esr/faqs/hacker-howto.html

I think it would be appropriate to have a list of useful links around E2 pointing to hacker-related topics, especially instructional topics mentioned by the doc itself.