The systems administrator in the cube a few feet away from me is fidgeting more than usual. Finally he has to share his excitement. Right now, right this second, he's compiling the Linux 2.4 kernel. He grabbed the source code off the Net, and now he's building it, the first step in constructing a new, state-of-the-art Linux-based operating system for his desktop computer. And he's psyched -- Linux geeks have been waiting a long time for this new, improved, industrial-strength version of Linux. Its arrival is at least a year later than when Linus Torvalds first promised it, a fact that reporters and competitors have not been reluctant to point out.
The delay doesn't bother the sysadmin much, though. Software releases inevitably drag on, especially if the developers are trying to get things right, rather than just hurry out some half-assed, bug-ridden piece of junk in a brazen attempt to grab market share. What's important is that he has the code now, and he is dying to get it up and running.
What's the first thing he's going to try? I ask him. His fidgeting halts for a second as he freezes in indecision. It's almost as if he hasn't had time to think about what he's going to use the new kernel for. The immediate priority is just to get it to boot up. But seconds later, his face clears. He wants to see for himself whether it is true that the new version of Linux will be able to handle much larger file sizes than the old version. This has relevance to his work at Salon, where we are using FreeBSD instead of Linux in at least one key area that involves the manipulation of a massive file. If the new kernel works as advertised, he might be able to make a switch.
A geek playing with some new code, he's as happy as a kid in a candy store. A few minutes later, I hear him exclaim in wonderment at how fast the 2.4 kernel boots. Then, a few minutes after that, he looks grim, crestfallen. His favorite desktop graphical user interface, KDE, doesn't work on the new kernel. It's his first disappointment.
"They'll fix that soon enough," I say, and his face clears again. That's right. Even now, we both know, hordes of developers are testing the 2.4 kernel and upgrading their favorite software to work with it. They'll fix it the free-software/open-source way -- with constant incremental improvement. In the world of free software, stuff is always getting better, which makes for happy hackers. And this sysadmin is one happy hacker.
I'm not very covertly spying on him as he goes about his business, because at the same time as the sysadmin is compiling his new kernel, I'm reading a book called "The Hacker Ethic and the Spirit of the Information Age." With a foreword by Torvalds and an afterword by Manuel Castells, Pekka Himanen's "The Hacker Ethic" is a slender volume of musings on the value system of that new info-age breed of worker -- the code hacker. It seems useful to me to be able to match what I'm reading against the real thing -- kind of like comparing an encyclopedia article on musk oxen to the real thing in the wild.
Himanen's core thesis is that hackers have a new, improved relationship toward work. As opposed to those poor souls beholden to the famous Protestant ethic, outlined in Max Weber's "The Protestant Ethic and the Spirit of Capitalism," hackers don't treat work as a duty or "the most important thing in life." Instead, hackers make their work subservient to their life, feeling a sense of joy and passion in what they do, rather than responsibility for what they feel they should be doing.
The hacker ethic also reminds us, in the midst of all the curtailment of individual worth and freedom that goes on in the name of "work," that our life is here and now. Work is a part of our continuously ongoing life, in which there must be room for other passions, too. Reforming the forms of work is a matter not only of respecting the workers but of respecting human beings as human beings. Hackers do not subscribe to the adage "time is money" but rather to the adage "it's my life." And certainly this is now our life, which we must live fully, not a stripped beta version of it.
Day 2: I walk past the sysadmin's desk, and see streams of code cascading across one of the two monitor screens flanked around him. "I'm looking at the code for KDE 2.0," he tells me, which he is painstakingly setting up. He's grumbling a little. The KDE 2.0 installation has been fraught with setbacks and unexplained crashes, and is very poorly documented. "I'm finding this difficult," says the sysadmin, fully aware of the implication that if this is tricky for him to master, then it would be well nigh impossible for the average person. He mutters about how he should write a script to automate the process. We discuss the possibility that someone has already written that script and uploaded it to the Web. We go a step further -- maybe he should write the script and get Freshmeat to link to it. He's pleased by the idea, but later, after inspecting Freshmeat's new redesign and deciding he doesn't like it, he puts the idea aside.
A few hours later, another sysadmin drops by the cube to discuss some weird memory issues that are cropping up on one of our internal network servers. I listen in on their conversation -- even though they quickly leave behind the realm in which I can fake comprehension, there's still always a chance that I can pick up some good jargon with which to impress other people. But after watching them for a little while, I am bemused by their body language instead of their words.
As they discuss a list of possibilities for what could be going wrong, one sysadmin goes through a sequence of Wing Tsun kung fu moves, aiming kicks and karatelike chops at his counterpart, who ignores the gesticulations while proposing various theories as to what has gone wrong.
Is this the hacker ethic in action? Without doubt, there is a playfulness to their interaction. It's not work in the old button-down, "let's have a meeting" 9-to-5 paradigm. But is it enough evidence upon which to construct an argument that the information age is ushering in a whole new way people interact with their work? And is their model transferable? In other words, could we all become hackers, sleeping in when we want, working when we want, on whatever we want?
Even better, could we all be sharing the fruits of our labors with our fellow humans? Because that's another part of the hacker ethic -- the idea that information should be shared, that software should be free, or at least freely copyable. Hackers, Himanen tells us, have a different relationship to money than normal folks do. They are not ruled by it; they don't do what they do out of a desire for money. They program because programming is intrinsically fascinating, and they share because sharing is righteous.
Much as I find certain aspects of the free-software ideology admirable, and even though I know plenty of hackers who fit into the categories Himanen describes (and plenty who do not), I'm not entirely convinced by Himanen's thesis. Hackers share because they can. And they set their own hours, whenever possible, because they can get away with it. The rest of us cannot.
One reason free software is able to flourish is that most hackers are able to earn their livelihood relatively easily, with enough leisure time to hack for the public good. The hours that they do spend working for the Man are well enough compensated to allow them to construct the rest of their lives in whatever fashion they might desire. A McDonald's cashier or a taxi driver is not so lucky. Free software is built on the reality that programmers are an elite class of worker, both indispensable and relatively rare. The hacker ethic, then, is a luxury.
Neither Torvalds' trivial foreword nor Castells' dense and jargony afterword dwell on the issue of the programmer's privileged place in the information society. Nor does Himanen zero in on the problem. He does have an excuse -- his book is not so much an anthropology or history of hackers as it is an essay attempting to formalize the value system that has grown up among hackers.
But it's a point worth contemplating, particularly in the current "dot-com downturn" era. Of all the various classes of people getting laid off right now, programmers have the least to fear, and demonstrate the least anxiety. Their skills will always be in demand -- no matter how bad the economy gets, technological progress will not stop. "The Hacker Ethic" is engagingly written and provocative, and indubitably commendable in its vision of a transformation of how all of us relate to our working life, but without rigorously examining the paradox of how it is that hackers are able not to care about money, it is significantly flawed.
Day 3: My neighbor the sysadmin pulls me over. KDE 2.0 is up and running smoothly, and he's as happy with the result as a 3-year-old who has just constructed a tower out of alphabet blocks. He says 2.0 is much nicer than 1.0., and the 2.4 kernel screams along. In toto, the improvements justify his hackerist faith in progress. The code will improve!
I can't resist telling him that I've just read on News.com that 2.4.1 is now available, and it is supposed to have a built-in journaling file system. His eyes widen -- somehow he missed the news. Maybe because he and the other sysadmins were too busy upgrading Salon's version of BIND after a CERT advisory of a major security weakness. Sysadmins take such advisories seriously.
I knew the news about the journaling file system would tweak him though, because earlier that day I had heard him arguing with another programmer over how well a Linux or FreeBSD system would respond to a sudden power loss. (In California, sudden power losses are inexplicably on everybody's mind.) The other programmer is recalling how he once conducted a test in which he literally kicked a computer's power cord out of a wall socket, on purpose. The point is to see how well the computer comes back to life after regaining power. Does it boot back up gracefully without losing data, or does it choke and sputter?
Linux-based systems traditionally have not had a good reputation for coming back online intact after an abrupt power failure. That's something that the addition of a journaling file system is supposed to address. There are several projects in effect aimed at putting together an open-source journaling system, and the news that one of those projects is now incorporated in the kernel was a tidbit that would make any Linux geek's heart swell with pride.
The sysadmin glances, almost unwillingly, at his desktop. Pretty soon, it's going to be time to start all over -- to grab the new kernel from the Net, rebuild it and take it for a ride.
It looks like fun. And hacking is fun, except, of course, when it isn't: When you're wrestling with some horrible bug that you simply can't isolate. When you have to solve a "mission-critical" problem in an absurdly short period of time. When you've been up five days straight and you still don't have code ready to ship.
Sometimes the code just gets to you, not in a good way, and you have to stop what you're doing, as my cube neighbor does on occasion, and pull out a guitar and strum a few relaxing notes.
The first time I saw him do that, I did a double take. Is this guy working or just playing around? Aren't we all under incredible pressure to fix things, now? How can he get away with riffing on a guitar?
Not long after that, I decided it helped me relax too when he played, and I stopped worrying about it. And then I read what is probably the central thesis of "The Hacker Ethic."
Hackers do not feel that leisure time is automatically any more meaningful than work time. The desirability of both depends on how they are realized. From the point of a view of a meaningful life, the entire work/leisure duality must be abandoned. As long as we are living our work or our leisure, we are not even truly living. Meaning cannot be found in work or leisure but has to arise out of the nature of the activity itself. Out of passion. Social value. Creativity.
We should all be more like hackers, whether we can afford to or not.
Shares