Home - Publications - Byron Rakitzis

Byron Rakitzis: Whispers from the Zone

An interview with Alexandre Leupin

Published in Chair et Métal, January 2000

Byron Rakitzis, 31, lives in California. He attended Campion School in Athens, Greece, then went on to study Physics at Princeton University. He became one of the first engineers of Network Appliance (NTAP) and wrote a third of the code of the company's first product. He now devotes his time to music (he is a professional, free-lance flutist and bassoonist), black and white photography and his family.

Alexandre Leupin : When, how and why did you get interested in computers?

Byron Rakitzis: This is a long story. In 1980 or so, my high school acquired some TRS-80 computers. These are pocket-calculators by today's standards, but they are what first fired my interest. I never really imagined then that I would make a living programming computers, but I spent many hours trying to understand how these TRS-80s (and later Apple IIs) worked. By the time I got to college I was set on getting a degree in Physics, though I had my eye on a degree in Music as a possibility. Computers were not a focus for me, but around my sophomore year I discovered that instead of working in the cafeteria I could earn money by working at the computer center's help desk. This meant that in practical terms I was in contact with a computer every day of the week. It's here that I discovered the charm of the Unix system, but only as a user, not a programmer.

I think it's one of life's happy coincidences that my school (Princeton University) happened to have close ties with Bell Labs at Murray Hill, the facility where Unix was originally developed. Through my work at the computer center I came into contact with students majoring in Computer Science, and this eventually led to my auditing a few courses, listening to guest lectures of Rob Pike, and so on. By the time I was a senior it was clear to me that I would never be a physicist. My self-study in Computer Science was taking me far further than I could ever reach in Physics. So even though my degree was in Physics, by the time I graduated I was already aiming at a job in the computer industry or at a Computer Science graduate degree.

What happened next was a stroke of good luck: I happened across a job as a computer system administrator at Texas A&M University, where I had the chance to write software in my spare time. I published this sofware on the net, and I had the chance thus to hone my skills before eventually finding a job in Silicon Valley. On the strength of my published code, I was able to succeed in several interviews. The rest is history.

I suppose this is an unconventional way to become a computer programmer, but luckily the industry is still young enough to tolerate such unconventional approaches.

The things which fired my interest are the intangible, unconventional parts of this story: being charmed by Unix, studying at a university with a rich and storied computing environment, being able to prove myself in public with free software...

AL: When, how and why did you decide to leave the field?

BR: Well, I've had a long and abiding interest in music, far longer than my interest in computers. I felt that if I reached age 30 without at least trying to make music a full-time commitment then I would have regrets later in life. So in mid-1996 I went to the Netherlands to study flute and bassoon. I returned to the US in mid-1998 and since then I've been pursuing freelance work with various baroque orchestras on the West Coast.

I can't rule out a return to computer programming someday, but for now it's the other interests which take precedence.

AL: My next question is: who are your heroes? What did they do? How did they influence you? Mine are Christ, Galileo, Einstein and Lacan (in the domain of thinking)

BR: "Hero" might be too strong a word for the way I admire historical figures like the ones you've listed. My university studies were in the fields of physics and music, so my intellectual heroes tend to be the great scientists and composers of past years. Take JS Bach as an example. Perhaps his life was truly a heroic one: he was considered at the same time a great composer, a great organist, and a great teacher, all the while fulfilling the duties of Kappellmeister (a sort of music director) in Leipzig. Add to this the fact that he had 20-odd children, it makes you wonder how he found it within his power to write the compositions which he's left us. A teacher of mine pointed out that simply copying out his compositions by hand would take the better part of a lifetime, let alone composing them from scratch!

If there is anything that the study of physics and music have taught me it's that when it comes down to it, the best use must be made of the most meager material. Nothing must go to waste. Hence the best musical compositions don't allow the addition or subtraction of a single note, and the best mathematical theories are similarly elegant. Einstein, one of your heroes, is quoted as saying that things should be "as simple as possible, but no simpler".

I try to carry this idea over to the way I write computer code, and I have to say that for the most part practical application of this idea is unfamiliar to other programmers.

AL: Let's go further. Music and computing both have a numerical base: does this mean that writing code is also an artistic activity? (When you use Windows, you know that you are not in the realm of science!) Conversely, is there some science in art?

BR: I'd say "yes" to both questions.

I've found that people unfamiliar with programming imagine it to be a dry, boring process. It couldn't really be further from the truth: the person who designs a large piece of software is involved with making a wholly imaginary construct in the mind's eye. Even though this construct cannot be seen it can definitely be described with adjectives like "beautiful", "ugly", "elegant", "clumsy", and so on. As I mentioned before a beautiful design will not have redundancy, and it may well employ deep insights into the problem being solved.

The fact is that a programmer is constantly faced with choices. These choices for the moment exceed our ability to make rigorous rules about how programs should be written, and therefore the best programmers are artists of a sort: they can see through the mess of possibilities to arrive at a clear, concise solution.

I suppose the same argument could be made about mathematics or even chess, but we don't call mathematicians or chess players artists... So when it comes down to it I suppose it is a matter of choosing words. But if I could chip in once more for the programmer: unlike a mathematical theory, which is in some sense "discovered", the programmer leaves us something which is just one of many possible ways of solving the same problem. In that sense it is an expression of the programmer's personality much in the way that a musical composition expresses the personality of its composer. I know as a practical fact that I could identify the code of my colleagues with just a quick glance.

As for the second question, I'm not sure how to answer it: in many ways, yes, there is science in art. For example, a photographer like Ansel Adams had complete technical mastery of all the "scientific" aspects of photography like mixing chemistry, evaluating the effect of light on film, and so on. He used this technical mastery to a higher end, but you could also say that he used science to evaluate his photographic materials. On the other hand, for every Ansel Adams there are loads of photographers who operate on a completely intuitive basis.

I'm not sure if this was the point of your question, and I think I may be missing it. The other way in which I can take your question is whether it's possible to somehow scientifically evaluate artistic endeavors. The brief answer to that is no, there are no scientific rules for good taste. I'd have to say I'm thankful for that!

AL: I think you covered both aspects. the second part had to do with how much intuition there is in writing code. Or "revelation", "illumination", creation...

BR: Well, to reiterate there is definitely a lot of intuition involved when writing code. It is anything but a cut-and-dried process. Of course, this depends a lot on the problem being solved, but generally programs which are at the cutting edge of what is possible will show more of this creativity in their implementation.

A good reference for this is Levy's book "Hackers". He describes in vivid detail what it was like to be a games programmer in the early '80s: computers were seriously underpowered by today's standards, and programmers had to make heroic efforts to extract the most out of what they had available.

Kurt Vonnegut in "Hocus Pocus" has my favorite definition of art:

Making the most of the raw materials of futility

Let us go back about the identity question, where you say you can detect who wrote such and such code by looking at hte code. An algorithm (or science) is the effective erasure of human singularity, of "personnality". The question of who wrote it is irrelevant (As an example, E=mc2 has nothing to do with Einstein's personnality. As soon as it is written, it separates itself fom its creator). However, you can detect singularity, a signature in codes written by your colleagues. This is a fascinating paradox. Could you elaborate?

Here I could go on and on, for example with the fact that science has no memory: Galileo abolishes the Ptolemaic cosmos, etc. However, in the human realm, we function with and because of memories (e.g. the Oedipus complex, etc.). I don't think I need to develop: from your answers, I think you get my points.

Okay, I need to distinguish between an algorithm and a computer program. An algorithm is the most abstract and general definition of how to solve a problem. It has a certain mathematical truth which as you say is a bit impersonal. You can use English words to describe an algorithm. For example, a simple algorithm for determining whether a number is prime or not could be:

Take a number "n" and compute its square root, sqrt(n).

Begin with the divisor "2" and divide n by this divisor. If the remainder of this division is zero, n is not prime, and you can stop.

Otherwise, increment the divisor by 1. If the divisor is greater than sqrt(n), stop, otherwise repeat this division with the new divisor.

There are countless ways to turn these words into a computer program. For example:

int isprime(int n) {

int d;

for (d = 2; d <= sqrt(n); d++)

if (n % d == 0)

return TRUE}

Now, a computer program shows its signature in many ways: many of them are typographical. For example, the same C program above could have been written with nothing more than a change of the use of whitespace:

int

isprime(int n)

{int d;for( d=2; d<=sqrt(n); d++ )

if ( n%d == 0 )

return FALSE;

return TRUE;}

That's just the smallest perturbation I could make to this code (there are many more essentially trivial typographical alterations to make) and yet to my eyes it already makes a very different impression on the screen.

Beyond typographical quirks there are also algorithmic quirks, choices of variable names, number and quality of comments, and on and on. It all adds up to a very distinctive signature.

Just some more examples: in my last job, I was always a fan of a device called "hashing by linear probe". Nobody else in the company used that device. They prefered to hash with "chains and buckets". If you happened across this device, which is a fairly high-level idea, you could be sure that I had a hand in the design of the code. This is far removed from the details of typography, but it is one more way which code can be distinguished.

Another way which code might be distinguished is the overall organization of the code. Some programmers like to divide the problem they are solving  into neat little boxes, and some programmers tend to write single large subroutines which go on and on. A measure of the talent of a programmer is how well this division of labor is accomplished. It can make all the difference between a program which is easily extended and maintained, versus a program which is very "fragile" and will tend to resist even the smallest change, or which might require an inordinate amount of effort to make a small improvement.

Let me finish with an anectode, which may or may not be apocryphal:

BSD Unix (which incidentally is the foundation for Linux and a lot of the networking code which drives the internet) was developed at the University of California in Berkeley in the early 80s. The code that is left to us from those days has a very disinctive look, and the story goes that at the time whenever one of the grad students got hold of a piece of code from outside Berkeley, he would simply "piss on it" until it looked like Berkeley code. This comment might refer to Bill Joy himself (now one of the chief technologists at Sun Microsystems, and one of the main contributors to BSD Unix) but I'm not sure about that. I think if you want to use this paragraph you'll have to help me verify the truth of this story.

AL: To pursue the musical analogy, shall we say that the code stands in relation
to the algorithm as the interpretation to the composer's music? This would
define code writers as creators as well as interpreters.

BR : This is broadly speaking true. As always, in both domains there is going to be a gray area which separates creation from interpretation. For example, jazz accords more of the creative element to the performer, whereas classical music is more rigidly specified by the composer.

In programming there are no "styles" of design like "jazz" or "classical" which are so easy to categorize, but since a large program is composed of thousands or even millions of lines of code, it cannot be regarded as being simply one algorithm, it is an agglomeration of possibly hundreds or thousands of algorithms.

The program's overall design then is likely to be specified only in the most general of terms, and so a lot of responsibility for the implementation falls into the programmer's hands.

Just to muddy this even further: quite often a programmer and designer are one and the same person. And because of the immature state of the computer industry, perhaps, many program designs are rarely written down as such in an unambiguous way: someone simply sits down one day and starts to write code. So if I've given the impression that computer programming is an orderly process which begins top-down from design to implementation, that is true only in a minority of the cases. Of course, this lack of rigor is one of the reasons why much computer code today is so unreliable.

AL: The "charm" of Unix? Most of us could not bring ourselves to find Unix "charming". I think I used it when I first got acquainted with e-mail, and immediately dropped any temptation to understand it. I got into computers when they began to accomodate an average user.What was charming about Unix for you?

BR: Unix is immensely charming to a large number of programmers. It is a literary operating system: like no other, it's an operating system which can manipulate text in interesting ways.

For example, I'm using Unix to edit this email message right now. When someone sends me a piece of email which has been poorly formatted, for example, if the lines are too long, or if the quote-mail string (typically ">" at the beginning of the line) is wrong in some way, a few well-chosen editor or shell commands will usually set the message straight.

The Unix idea of text manipulation rests on something fundamental called "regular expressions". They are loosely approximated by the "*" notation in DOS, but they are far more powerful. For example, the regular expression to denote all words beginning with vowels and ending in consonants is:

[aeiou].*[^aeiou]

Beyond text manipulation, Unix also offered some expressive yet simple ideas which made it unique among its contemporary operating systems. The shell pipeline is one, and putting devices in the filesystem heirarchy is another. It makes it rather like the Lego of operating systems: Unix at its best is a collection of many small tools which interoperate with one another. Using shell pipelines, arbitrarily interesting and useful programs may be created on the fly by the ordinary user.

AL: On a more general level: what is for you the morality of the Y2K fable, or drama, or play? What about these machines created by us which escape our human control?

BR: I think it's ironic that nothing happened. Like everyone else I wasn't really able to quantify the risk (what do I know about the electricity grid or the water supply!?) and so the scare tactics seemed at least plausible.

The grave problem that this points to is that we can be hoist by our own petard. I think computer privacy will be a good example of this.We are giving more and more of our privacy away to the computer, really piecemeal without appreciating it, and as yet it doesn't seem to have caused serious problems. But I think we are setting ourselves up for the worst in Big Brother dystopias.

It's gotten to the point where I think I want to pay for all my supermarket purchases in cash. I am assuming right now that when you offer the supermarket their discount card that they keep track of every little thing that you buy at the store. I don't like the implications of that. It might mean, for example, that my health insurance company or employer will find out how much liquor I've been buying recently.

The Economist ran a story recently which rather bravely proclaimed the end of privacy (as a result of computers in society). I'm not so sure I'm ready for that step.

AL: Let me reformulate: what about the unpredicatibility of the code's functioning? Is there some independence to the machine, since it produces unforeseeable results (e.g., bugs)? How would you distinguish this experience from, for example, Popper's principle of falsification? Is the failure "code experiment" related to science or to the inherent faillability of technology (trial and error)? the machine,s escape from human control, isn't this disquieting?

BR: I don't know what Popper's principle of falsification is, but I'll try to answer your question anyway.

Code can be unpredictable in different ways. For example, there can be outright errors in logic, in the sense that if you were looking at it like a mathematical problem to solve an equation, you'd find at some point that someone forgot to divide by 2.

A more difficult error which comes up frequently in systems programming is something called a race condition: computers often execute more than one program at once, and the possibilities for unpredictability increase by leaps and bounds if one program depends implicitly on the progress or result of the other program.

A simple example is checking your mail: suppose your mail reader opens a connection to the mail server, downloads the messages and then deletes the messages from the server. What happens if at the same time a new message arrives over the internet? A mail server which does not correctly anticipate this race condition could possibly lose this new message, and what you have on your hands is a mail server with a subtle and difficult bug to find. Now, if you add up enough of these unpredictable interactions, what you get is a computer system that is out of control. That is my analogy to Y2K. What we had was a bunch of institutions saying simply "WE DON'T KNOW what will happen on January 1st because all our systems work together in ways which we don't really completely understand any more."

It's a very unsatisfying answer but it explains all the paranoia, I think. I'll move along to the next question here, but I should say that the disconnect between what a programmer writes and what actually happens is one of the most interesting facets of computer programming. It inspires whole new avenues of research in programming language design, for example. This is not a trivial issue and at best I've simply glossed over it in the last few paragraphs.

AL: I was thinking about the psychological effects of these long hours in front of the screen. What about "the zone", for example?Do you withdraw from your environment? Are you elated when "it works"? Did your work as a code creator had any negative or positive impact on your (personal, daily) life?

BR: Okay, there are many psychological effects. And of course they vary from person to person.

There is definitely a "zone". The way I saw it was this: if I had a difficult problem to work on, my best chance of solving it would be to get all the pertinent details into my short-term memory. It felt like filling a box, perhaps. In practical terms, I would mull over the problem, lose a lot of sleep thinking about the problem at night, read lots of code over and over again familiarizing myself with previously unseen details, etc. At some point, usually not long after I had accumulated "enough" information, some kind of solution would present itself, often out of the blue. This was both amazing and frustrating at the same time, since I had no direct volitional control over these flashes of insight.

Another kind of zone I could be in would be a creative zone, when writing new code from scratch. Sometimes what needed to happen seemed obvious, so it was just a matter of making that pattern in my head a reality on the computer screen. I didn't find this boring in the least, in fact, this was the most pleasurable kind of work since time seemed to pass quickly while I typed fresh new code out.

There is also a great elation when "it works". In a high-pressure Silicon Valley startup, though, this feeling does not last long. There is always so much more to do, that soon enough it's on to the next thing. If anything this environment is one which made me a bit blase perhaps towards the "it works" elation. At one point I was doing so much and accomplishing so much that I never had enough time to dwell on my success. Who knows, maybe that's how it should be. Back to the first question about heroes, how many creative heroes of yours paused to smell the roses?

As far as whether this work has an impact on daily life, I would say that the impact is huge. It's one more reason I moved away from programming as a way of life. It struck me that an activity like music is partly mental, partly physical. After a long day of playing an instrument, I'm tired and sore and I want to drink a beer and relax. With programming I found it was the opposite: the purely mental stimulation would certainly exhaust me, but it didn't leave me feeling tired in a good (physical?) way. Instead, I felt physically numbed and yet unable during the intense times to actually forget thinking about whatever problems I was working on. This meant in practice that I worked many long nights as I gave in to my insomnia.

I know I am not unique in this regard. Most programmers who work ridiculously long work weeks don't do it because they are compelled by some external force (financial, managerial, etc.), they do it because the long hours become their own justification in the end.

I have to say that this is a very unbalanced way to live. Also, despite my efforts to find balance, I wasn't able to find it by, say, lots of physical exercise either.

AL: Would you like to play the seer, about the future of computing and the more and more forceful enmeshing of man/machine (this is the topic of Chair et Metal/Metal and Flesh par excellence)? Positives, negatives?

BR: I'm not much of a seer. I prefer to give that role to the better science fiction authors. Neal Stephenson paints a very convincing future based on nanotechnology in Diamond Age. In this book he describes what comes very close, in my opinion, to the perfect user interface:

He writes of a "book" which is really a very powerful computer. It recognizes speech, and it has some way of rearranging ink molecules on a page of real paper in real time so that paper takes on the flexibility of a video screen. The computer also recognizes handwriting as it's written on this paper by a stylus, and rearranges the ink underneath the stylus accordingly.

Ironically this a computer in the guise of pen and paper, a technology which is a few thousand years old. I think the lesson here is that our most long-lived techologies are the ones which we want to learn from the most.

As for the positive/negative sides of man enmeshing with machine: there are a lot of social issues which I alluded to earlier which will be played out in the next few years one way or another: censorship, privacy, digital cash, and so on. I can't tell which way it's going to go, but it will become important in the next few years as our commercial life moves more and more into the digital realm.

Beyond the commercial realm who knows how the computer and now the internet will affect us? A few years ago the internet proponents spoke about the internet with very lofty ideals in mind. Now much of the internet is crassly commercial. There are parallels to television here. I thought that idealistic visionaries saw television as potentially a great educational tool, not the cesspool for infomercials which it's turned out to be.

If this doesn't sound optimistic, I'm sorry. I'm not the optimist I once was. I now feel that computers simply mirror society, and not the other way around. I know that for my own children I would prefer to teach them about computers as tools, and in fact I would also prefer to delay the introduction of computers in the school as long as possible.

AL: I think you address the questions in a most satisfactory way without knowing it. Popper states that a scientific hypothesis, in order to be scientific, has to be falsifiable (as opposed to a revealed truth, for example): that is, one should be able to test it and see it contradicted by an thought experiment or a crucial experiment. You can dwell on it if you wish, but it doesn't seem indispensable to me.

BR: Briefly, of course computers can be scientifically observed and analyzed.

The way I see it is that as computer systems get more complex, we move away from being able to predict their behavior from first principles (e.g., by understanding the source code) and instead we rely on empirical analysis.

These intractable problems abound in computer systems, but they are also very easy to find in the physical and life sciences.

AL: If I threw this sentence at you: "Today, the master of the code is the master of the world", what would be your reaction? By analogy, as a medievalist -this is what I am -, I know that the masters of writing where, in the Middle Ages, the masters of the world. Every symbolic exchange had to go through the hands of a cleric; the clerics' class had hence a monopoly on power, which became more democratic with the people accessing writing and reading. Isn't the same thing happening today in regard to the codes and code writers?

BR: I'm not sure about your premise, but I don't feel qualified to disagree. As far as code and code writers today, what power do they really have? They are rewarded well financially, but so are NBA basketball players. Does that mean basketball players have a lot of power, too? As a counterargument, I would propose what I think is O.S. Card's idea about the computer company-as-beehive: he says that as long as a computer company keeps its programmers happy it can harvest their efforts much the same way that a beekeeper gathers honey. It's a tongue-in-cheek article but nonetheless appropriate.

AL: How do you react to the fact that while you are writing some code, the final say on how the code will operate, depends on the machine itself? Your coding abilities are always dependant on how the "machine" works it out. I'm sure that more that once, the reaction by the machine to your code was not as anticipated. To you feel that the machine is part of the coding itself, part of the art of coding?

BR: First of all, when I write code there is very little impressionistic about it, such as "I have no idea what this will do, let me run this and see what the machine thinks about it". I usually have a pretty good idea about what I want to do when I write a line of code.

So in that sense I don't feel my "abilities are dependent on how the machine works it out".

On the other hand, I can write something and then be surprised by a bug the code I just wrote ("gee, I didn't think of that").

Where I feel that the machine is part of the art of coding is that I often program "close to the metal", especially when writing system code. In other words, without even really thinking about it, I have an idea in my mind of how the compiler is going to turn what I write into machine code, and so I choose idioms which are likely to translate well into efficient, fast code.

Now, this is often called "premature optimization" and strictly speaking it's a very bad habit to get into. But I think there is a difference between slavishly writing with a particular machine in mind, versus composing code sequences which are likely to be compiled into efficient machine code. If there is an art to writing code with the machine in mind,I think that is it.

AL: Something else: What do you think of the fact that coding itself depends on a machine that already has some code? What I mean is this: The more computing programming is being done, the more layers are added to the coding itself (no one codes in machine language anymore), Do you feel as if you've lost some control over the process?

BR: Okay, there are a couple of ways to look at this.

One way is to say: I will invent everything from first principles. And in fact, over the years I have tried to be that strict at one time or another. For example, I have authored my own Unix shell, window system, and I have written several compilers, as well as participating in the operating system work at my last job. So in one sense, if you really want to, you can be a systems programmer and avoid the "layers" you refer to.Another way to look at it is to choose to work with layers of code which are very well specified. For example, the "C" language is extremely well understood. Any bug you find in a C compiler these days is likely to be very obscure. So in that sense you don't really feel any loss of freedom when writing in C, since most nearly all the time your wishes will be faithfully carried out by this imaginary "C machine".

The same reasoning applies to all high-level languages or programming environments more generally, and usually the "spell" works fine until you run into some practical limitation in the implementation. And then you are faced with the choice: (1) improve the situation somehow; this in particular possible to do if the source code is available, such as in a lot of Unix freeware, (2) grin and bear it, or (3) run away; ultimately no one is forcing you to use this tool or environment. You would think that a lot of programmers end up in (2), and that may well be the case but I think it's important to keep the other two

alternatives in mind. For example, I don't use or program for any Windows-based computer, and as I mentioned above I've been more than willing over the years to roll up my sleeves to try to fix something broken.

Back to top