Hacker Culture & acmet Tools BU

Further on an ealier post on the the subject.

The following quotes are from How To Become a Hacker by Eric Raymond.

#1. "There is another group of people who loudly call themselves hackers, but aren't. These are people (mainly adolescent males) who get a kick out of breaking into computers and phreaking the phone system. Real hackers call these people ‘crackers’ and want nothing to do with them. Real hackers mostly think crackers are lazy, irresponsible, and not very bright, and object that being able to break security doesn't make you a hacker any more than being able to hotwire cars makes you an automotive engineer."

#2. The basic difference is this: hackers build things, crackers break them."

#3. "Being a hacker is lots of fun, but it's a kind of fun that takes lots of effort. The effort takes motivation. Successful athletes get their motivation from a kind of physical delight in making their bodies perform, in pushing themselves past their own physical limits."

#4. "To behave like a hacker, you have to believe that the thinking time of other hackers is precious — so much so that it's almost a moral duty for you to share information, solve problems and then give the solutions away just so other hackers can solve new problems instead of having to perpetually re-address old ones."

#5. "Authoritarians thrive on censorship and secrecy. And they distrust voluntary cooperation and information-sharing — they only like ‘cooperation’ that they control. So to behave like a hacker, you have to develop an instinctive hostility to censorship, secrecy, and the use of force or deception to compel responsible adults. And you have to be willing to act on that belief."

#6. "Therefore, you have to learn to distrust attitude and respect competence of every kind. Hackers won't let posers waste their time, but they worship competence — especially competence at hacking, but competence at anything is valued. Competence at demanding skills that few can master is especially good, and competence at demanding skills that involve mental acuteness, craft, and concentration is best."


#7. "If you revere competence, you'll enjoy developing it in yourself — the hard work and dedication will become a kind of intense play rather than drudgery. That attitude is vital to becoming a hacker."

#8. "Linus Torvalds, a Finn, comments his code in English (it apparently never occurred to him to do otherwise). "

#9. "Being a native English-speaker does not guarantee that you have language skills good enough to function as a hacker. If your writing is semi-literate, ungrammatical, and riddled with misspellings, many hackers (including myself) will tend to ignore you. While sloppy writing does not invariably mean sloppy thinking, we've generally found the correlation to be strong — and we have no use for sloppy thinkers. If you can't yet write competently, learn to."

#10. "Learn to write your native language well. Though it's a common stereotype that programmers can't write, a surprising number of hackers (including all the most accomplished ones I know of) are very able writers."

So would a hacker culture have been acceptable? We certainly were well on the road to having one.

For those who worked on acmet's GCC porting project, please read this topic.

Written Communication

I found the following in How To Ask Questions.

"Spell, punctuate, and capitalize correctly. Don't confuse “its” with “it's”, “loose” with “lose”, or “discrete” with “discreet”. Don't TYPE IN ALL CAPS; this is read as shouting and considered rude. (All-smalls is only slightly less annoying, as it's difficult to read. Alan Cox can get away with it, but you can't.)


More generally, if you write like a semi-literate boob you will very likely be ignored. So don't use instant-messaging shortcuts. Spelling "you" as "u" makes you look like a semi-literate boob to save two entire keystrokes. Worse: writing like a l33t script kiddie hax0r is the absolute kiss of death and guarantees you will receive nothing but stony silence (or, at best, a heaping helping of scorn and sarcasm) in return."

I found the link as a polite postscript to a response on a forum.

The article contains great advice from a uber hacker.

Hacker Culture & acmet's Tools BU

A few weeks ago GGanesh, sent me an email about what he considered were the strengths and weaknesses of acmet's tools BU. In that he mentioned:
"But an acmet thing which I remember most, is the way we encouraged getting the bad news early. We definitely had the hacker's attitude. We played with the code and got the bad news early."

Did we really have a hacker attitude? I wondered if I would ever have been comfortable working with a bunch of hackers.

GGanesh's mail led me to Paul Graham's essay on hackers.

One paragraph in the essay says:
"The latest intellectual property laws impose unprecedented restrictions on the sort of poking around that leads to new ideas. In the past, a competitor might use patents to prevent you from selling a copy of something they made, but they couldn't prevent you from taking one apart to see how it worked. The latest laws make this a crime. How are we to develop new technology if we can't study current technology to figure out how to improve it?"

If it is good for progress to look inside the competitor's product, should practices that facilitate poking around inside's one's own product not be instituted?  Poking around is reading (reviewing) code, poking values into variables while stepping through code, writing tests to see what breaks the code... Should not the product be constructed in a manner that makes future improvements easier? (The tag line for the Tools BU was "Software Maintenance as RENOVATION".)

So, yes I agree with GGanesh. And though the attitude was not strongly evident, it was getting stronger

Hindering Poking Around
This is my partial list of what hinders poking around.
* Inscrutable names of modules, functions, structures and data elements
* Prolific use of globals in the name of efficiency (a wolf in a sheep's clothes)
* Magic numbers
* Source code documentation that does not explain what sections of the code do and why it is required to be done, and what are the likely pitfalls.
* Undocumented pre-coditions and post-conditions
* Strong coupling between modules and weak cohesion within a module
* Cliques that discourage new generation of developers from getting to know the current code

Good Hackers
To make code easy to poke around, to bring up a new generation of developers, needs self-confidence and humility. Be critical of code, or ideas; not persons. I think most software companies would want such hackers. I definitely would have wanted more of them. That is the kind of hackers you want for a sustainable software process.