The Hackers' Craft

Craft has things in common with what hackers are about and I've found Eric Raymond's pages interesting and enlightening as a result. His essay Homesteading the Noosphere gives an account of the dynamics of respect among hacker, in which behaviour is accounted for by the pursuit of such respect.

Eric recognises that craft has a rôle, but finds this to be less relevant to hacker dynamics than the closely related business of peer recognition. I don't suppose him to be saying this is exclusive: the two are intricately intertwined. But Eric appears to say that hackers do the things hackers do in order to obtain the respect of their peers: and with that I disagree. I contend that hackers do things hackers do because those things are useful, they do things the way they do because those ways are effective, and they respect folk who share their attitute to utility and effectiveness. This is the way of the craftsman and it produces all the symptoms Eric describes.

Note the huge difference between: how shall I get their respect ? ... ah, in that case, I'll do those things and I am doing what I do and I find there are others, who do likewise, who respect me - what a joy that is. Part of the true hacker experience is the sense of surprise at first gaining the respect of hackerdom: the true hacker practiced the craft in order to get a job done, so any respect gained along the way is a bonus. The mutual respect of hackers is the foundation of hackerdom's social dynamics: but its cause is not hackers seeking repute, it is hackers getting jobs done (which hackers happen to respect).

Furthermore, hackerdom's main interest in repute and respect is, as with anything, about effectiveness. Folk can stir up the enthusiasm of those who respect them, so respected hackers can get projects going, so respect is useful. The participants in the project learn (in all the ways Eric points out) to respect one another, so respect is also self-sustaining: and tends to become mutual. The large primate (or dog) who happens, also, to be the hacker does (for all the usual social animal reasons) derive satisfaction from that respect: but if that were all the benefit respect produced, the hacker would have overruled pursuit of it as more effort than utility.

One of the beautiful traits of hackerdom is that it judges a work on its merits, not on the reputation of its source. Each discovers the merits of a work only when exposed to it, and works associated with widely respected folk or projects tends to get tried by more folk, but that's the selection of what to judge - it doesn't mess with the judgement of whether the work is good, which is based on the work itself (both its inner details and the hard truth of its live performance). Hackers only seek repute in so far as it is useful: which mostly rules out fame (in certain of its senses, at least). Where it is not, expect to see hackers shunning it - and you will notice that hackers accept respect more as Thank you for your good will - and I am glad to have helped than as somethings deserved or due.

Effective and straight-forward.

The hacker way, the way of the craft, is effective to the best of my knowledge, which implicitly involves seeking to get better knowledge of what's effective; it also implies many things that come under the heading of enlightened self-interest, including certain matters of dealing straight-forwardly and decently with folk.

As an honest practitioner of my craft, I aim to have the tools that will enable me to do what I'm doing as effectively as I know how, given the means at my disposal. If I can make it easier for other folk to be effective, for instance by equipping them with effective tools, I'm generally in favour of it - particularly when the folk in question seem likely to improve the tools I'm using (in order to make best use of them in another context) in ways I can use. If making the improvement for myself suffices, as it does with software, to provide it for anyone else who wants it (without any loss of use of it by me), then I do not waste my time trying to guarantee a pay-back before letting them have it.

I want tools that let me do what I'm doing as effectively as I know how, so I'm interested in what tools are available to do the same job, or parts of it, in helpful ways - particularly if I'm at liberty to adjust my copy of the tool to do just the thing I want, or can fit it into my own tools in good ways. Hackerdom has discovered, by the means it most trusts - experiment - that one of the most effective ways of developing tools is to share our assorted fumblings, each picking and choosing what each finds useful, assembling the fragments and improving the assembly.

In choosing what to try, to discover whether it's useful (that is, conducive to effectiveness), we take into account the opinions of folk whose judgement we trust (typically because we've identified good correlation between their past advice and our subsequent experience: but sometimes simply because we've seen them behaving in the spirit of effectiveness - hackers are prejudiced in favour of such folk). We thereby form a consensus (in any given project, however diffuse or informal) which pays close attention to the opinions (on the topic in hand) of certain folk.

Hackers respect those who they've seen behaving in the spirit of effectiveness: that they have been seen doing so tends to depend on their having participated in (possibly having founded) some project to make a tool good for some purpose(s). If I improve any tool that I'm in a position to improve, I'm apt to make the improvement available to other folk using that tool - and, if there's someone the tool's source mentions as willing to serve as collator and redistributor of such improvements, I'll use them as the channel by which to do so: but I don't embark on making a change, though it would be an improvement, if it would take more than a modest amount of my time and effort and would imply significant extra work every time I accepted anyone else's improvements to the tool. For a respected figure in a project, however, the hacker will suggest such major changes, and perform them if advised that they'll probably get incorporated into the project's ongoing versions (thereby saving all that extra work at each improvement thereafter).

As a result of such involvement, hacker volunteers get to work with one another and learn respect for one another: the respect of each seeing that the other, also, strives for effectiveness, straightforwardness and all the other hacker virtues; the respect, equally, that comes through having learned those virtues better by association with such peers. This, in turn, leads to a rich discourse among parties willing to learn from one another's opinions: and that's a recipe for forming the best consensus the folk involved can honestly agree on. Such a consensus, among folk who value effectiveness above all, has a very good habit of choosing effective ways forward.

Hackers, in short, to the things that hackers respect when they see folk do them. I don't accept that hackers do those things in order to gain the respect of hackers - I contend that hackers do these things because hackers find them effective: the following are natural consequences.

• Folk dealing thus with the world find one another effective colleagues and good companions.
• A group of folk brought together by such a common aim will consequently be able to support a viable social dynamic of mutual respect based on shared values, which is good for collective effectiveness.
• The general processes of social dynamics can thereby swing into play and give us familiar structures: many contribute, some earn respect among those who know their contributions, a few of these become known to many and serve as the channel by which all form a consensus; and this is effective, else hackers would find some other way to organise.
• Hackers acquire respect not because they sought it, but because they did useful things in effective ways, which is what hackers do even when they aren't going to get respect for it (for instance at work, for many hackers).
• Hackers do not seek respect, though hackers are always glad to receive respect - and its giver will then, at the very least, be charitably reviewed for what kinds of respect they do warrant.
• Hackers have no reason to seek respect: anyone who isn't going to respect the faithful pursuit of effectiveness isn't worth being respected by; and anyone who does respect that pursuit is going to respect hackers anyway.

Hackers don't split projects, because they've learned that this is counter-effective (wasteful). When a hacker has a patch to send in to a project, the hacker looks through the project information for some single party to whom to pass the patch for redistribution to all - the hacker prefers this because it is more effective than doing the distribution independently. Because the folk on the project realise that's what hackers will want to do, they make sure that there is such a single point of contact by finding a volunteer willing to serve in that rôle. Since patches will be coming in from folk working from old project releases, changing who this is is disruptive (wasteful) so hackers avoid doing it unless the present point of contact is clearly not willing to continue serving in that rôle. So hackers don't shift the mantle of project leadership without going through some thorough checking that the shift will really be an improvement. Hackers do what hackers do because it's effective: that rule creates the taboos Eric highlights.

Stone soup

Linus took a pot of water, got a fire going under it and threw in a stone: because stone soup is often the best. He threw in some other stuff, too: so did lots of folk who fancied a bit of good stone soup. Between them all, they made a fine old stone soup. Best of all, each of us can have all of it, even make up our own brew of it, without interfering with everyone else's access to all of it. Yet everything any of us throws into our own pots, to make it be just how each wants it for self, is available to make the soup better for all.

I suspect Linus cares more about there being a community tending the pot than about gaining credit for having set it all in motion. Likewise, the hackers tending the pot are doing it because it's useful to them, rejoicing in the fact that being effective is fun. That suffices, in itself, to get them any repute that is apt to affect effectiveness - they are known to the other folk involved, they have been seen being effective.

Each craftsman wants credit to be given, publicly, to those of her peers who've contributed to a project, so that she can know which of those peers it may be effective to consult or work with on some sub-project or related project. She knows what she's contributed, so her own pieces of the credits file will contain no new information for her - though they will doubtless raise a smile, and encourage her. The hacker maintaining a credits file has learned to include all: it is the most straight-forward solution; and it allows the reader to recognise where credit is due even when the record-keeper didn't recognise its significance at the time. A good record-keeper has the humility to recognise that this happens some of the time.

The Linux community is effective and gives us all effective tools: the craftsman cares more about having the tools with which to do each job well than about who gets credit for those tools. At the same time, Linus enjoys his bowl of stone soup and thanks those who have contributed so much for having made it a much better stone soup than he could have had without them. RMS and others, before and since Linus, have given stone soup to the world too: they have gladly thrown their assorted brews together to make a veritable feast for us all; and they all honestly thank those who've helped them, because they're honestly grateful.

So the leaders of projects thank contributors, great and small, for which the standard mechanism is the credits file ('though I cannot remember what I did to ispell, so I don't suppose it was any great matter, I find myself credited all the same) and the sweetest thanks happen in the source code - it contains the patch contributed, so I don't have to maintain it myself any more (likewise, I can no longer remember what it was I changed about mailalias.el's handling of source directives - what I care about is that it works and I'll never again have to work out how, why and what to change).

Hackers want a bowl of stone soup more than hackers care about credit for having cooked it. The latter's only of any use in so far as it enables the hacker to make the soup better: having better soup is the goal, credit is subordinate to that.

Humility

I see humility as an active force in hackerdom. It shows itself partly in the jovial self-deprecation of The Great and The Good. Its true nature is the honesty to recognise that the question how well am I doing this ? is always open - I may know of no bugs in my code, but I don't assume there are none there. With hindsight, my confidence that what I'm doing now is good may solidify: possibly after I've made some subsequent improvements in light of what I learn by doing it. For the present, however, I'm doing it the best I can see now, aware that I may later see glaring errors; listening to folk I trust can help me spot the errors sooner. In such a spirit the hacker humbly submits a patch to a project - if you guys assimilate this, it'll be easier for me to use what you're making in future, but I can revise my patch at each update if it doesn't fit in with where you're taking the project. That way I can thank you for software that, with a little tweaking, is useful to me; all the more if you accept the patch and I don't even need the tweaking.

This humility trait is inseparable from the honesty aspects of hacker culture (which by no means involve total honesty in all things). A hacker will faithfully report a (sub-) project's failure so that those anticipating its results can begin preparing their way forward without it: such honesty is recognised as necessary for the smooth functioning of collaboration - it enables the participants to be effective. It also leaves the hacker open to blame that could have been dodged by keeping quiet and trying to divert attention: but blame isn't effective and misleading folk is counter-effective, so hackers are going to ignore blamestormers and won't want to hide the truth just to dodge their noises.

Part of the cause of that humility is traceable to a back-lash against certain kinds of ego - notably, the programmer who devotes more time to proving that the bug is someone else's fault than to searching for things in his code which might actually be responsible. His ego says he doesn't write bugs and that you're trying to blame it on him, so he defends himself by attack. He'll even write code which depends on the behaviour he knows someone else's code doesn't support, the better to prove the other's guilt. Yet every good journeyman recognises that she does write some bugs, so learns the humility to search long and carefully in her own work to understand how the error arises - in particular what she has presumed of someone else's work. In truth, this is the best way to help someone else understand what they've gotten wrong anyway - as I hear her account of what her code has presumed, and remember promising that in my spec (or realise that I should have promised it in the spec), I see where I went wrong: and it's easier to own up to an error I discovered than to an accusation.

The hacker ideal places effectiveness before the ego: the wise hacker knows that the ego is not easily thwarted so learns to tame it instead, so that its follies and absurdities do not interfere with effectiveness. Hackers accept the tenet that, while you can't help bringing your ego to work, it shouldn't get in the way of the business of getting on with the job as effectively as I know how: no-one else should have to do something less effectively simply to give my ego a bit of extra elbow-room. The discipline of humility is part of the process of taming an ego to within these constraints.