The first indication that my life would be numbers obsessed was when I was four years old, and was caught attempting to count to infinity, one integer at a time. (I never got there.) The first time I saw a computer was in high school when we had a small machine that used BASIC and read and wrote punch tape, six holes to a line. But I was focused on math and physics and didn't get into computers then. Actually, I took a personality test, which showed that my two ideal professions were physics and law. At that time, I had enough self-respect to avoid law.

We spent a lot of time doing measurements in physics lab: when we wanted to measure speed, we would feed paper tape between two electrodes which would spark and leave a series of marks on the tape. I was partnered with a girl known to all of us subsequently as "the girl with the electrodes." She would wait until we were in the middle of adjusting the electrodes to get the exact right gap and then turn on the juice. If we assigned one of our numbers to hold her while we adjusted the electrodes, she would object that we were not holding her the way a gentleman would hold a lady. She was deaf to our riposte that a lady would not have needed holding.

I kept up with the physics when I went to Harvard. My sophomore year at Harvard I elected to do work-study in the physics lab. The first day in the lab, my assistant professor, not knowing anything about my skills with electronics, told me to crimp some of the cables needed for an experiment. Crimping, he explained, means you put a metal collar around the end of the wire and clamp down with a "crimper" to achieve a tight fit. I crimped with vigor; there was no chance whatever of an electron escaping. I wasn't in the lab the next day, which was on the whole a good thing. The day after, the assistant professor had recovered a bit, and handed me a copy of McCracken, the then canonical text on Fortran. He gave me three excellent pieces of advice and one piece of wisdom. The advice was: 1) "write code that runs from top to bottom," 2) "use meaningful variable names," and 3) 'throw the first version out.' The piece of wisdom was that the computer is an instrument of justice. It will do exactly what you tell it to do. Whether this is what you want it to do is not its problem. In the course of confirming the truth of this, I built a lot of card decks. The card reader liked to take a deck, generally one that had not been backed up recently, chew it into confetti, and spray the remains over the computer room. If you were quick enough, you could reach the off button before the reader destroyed your deck. That's how we got our exercise in those days.

My job was to construct a program that would waltz charged particles through a magnetic field, meant for use in designing a high-energy experiment. I learned an enormous amount about debugging in the course of doing this, e.g., the human mind has a wonderful tendency to fall into a rut and not even notice that it is wedged. One of my favorite tricks was to start the particles off with randomly selected positions and velocities so that every possible configuration would be checked, especially those I had not thought of checking.

I went on to do graduate work in physics at Princeton, on an NSF scholarship. I kept up with the scientific programming, now computing the orbits of charged particles around neutron stars and black holes for a physics professor who had two obsessions: one was glitter babes, the other physics. He had worked out that you could solve a number of otherwise intractable problems by combining theoretical and numerical methods using the theory to take you as far as you could go and then using numerical analysis and the computer to pick up the problem from there. While I did get a Masters from Princeton, I wasn't able to find a problem suitable for a PhD thesis. I drifted forwards and after a brief stint of trying to write science fiction. (lack of talent would appear to be a fatal handicap in this arena.) I wound up as an editor on Isaac Asimov's Science Fiction magazine. I received 1000 manuscripts a month and published ten.

My job was to read 40 of these slush pile masterpieces a day, looking for the one in a hundred. There's a reason why people in publishing drink a lot. After about two years of this, I ran into a fellow who was setting up a scientific and scholarly press. He needed someone who understood publishing and who knew how to program a computer. TA-DA! For the first couple of months, my working hours were 11 a.m. to 2 a.m. Monday to Sunday

I still remember the day we got the huge five-megabyte disk containing our new operating system, "Unix." I followed the instructions sedulously but found that the machine refused to allow more that one user to work on it. There were no books on Unix at the time. I beat my head against the wall for a while, and then called support. I read out the instructions I had been given. The voice on the other end of the line said "what about init2?" I said, "I don't see that here." He said, "That's the instruction that lets more than one person use the machine." This was my introduction to the state of UNIX documentation. We needed to run the computerized typesetter. The typesetter had a particularly vicious personality. It was fond of taking not only itself, but also the entire system down if fed data it disliked.

After about a year of hard work, we actually got the system largely automated. I took a week off, went up to Vermont, and read a book called The Dancing Wu Li Masters. This is a wonderful book about time and quantum mechanics, full of many instructive errors. After spotting some of these, I realized that this whole area was actually wide open. This got me started keeping up with the physics literature in the area.

A few months later, I started to get calls from headhunters. Apparently, "Unix" was a good thing to know. When the market speaks, I listen. Eventually AGS Consulting hired me. They placed me at Bellcore, a spin-off from Bell Labs. After a couple of weeks, I was assigned to hot line. First time on hot line, I was asked to solve a problem with the remote job entry system (RJE). I asked, "Who is the expert on RJE?" I was told, " if you solve the problem you get to be it." "Where is the documentation?" "If you can't read source code, you shouldn't be here." Somehow, I managed to bull my way through the problem. I discovered that local practice when on hot line was to head out for lunch with your friends and knock back a couple of drafts of Old Peculiar at a local bar left over from the days of the British empire.

After four years at Bellcore, I found myself responsible for 25 mini computers, 1500 users and 4 or 5 junior system administrators. It was time to go independent. I got a couple of contracts building medical databases for some labs back in Philadelphia. The great thing about building medical databases is that you can learn an enormous amount from the doctors about how to solve problems. Doctors routinely deal with problems that have technical, psychological, statistical, sociological, economic and even political dimensions. And even medical dimensions! The other problem is that if your software doesn't produce the right numbers, someone could die. This leads one to take a very serious attitude towards errors, debugging and testing.

My other big contract was to build a database for a Jewish cemetery. At first, I didn't understand why a cemetery even needs a database, but it became clear that a cemetery is a giant inventory control problem where the inventory doesn�t move around a lot. (Although at times it does move, for example when relatives are reburied.)

Since the labs were mainly for pregnant women, my company slogan became "cradle to grave programming." After some good years, the HMOs and the hospitals ate my small labs and the cemetery business died out.

I moved on to programming for a television and cable advertising company. The great thing about television is that it runs 24 by 7. For some reason, problems like to happen at 2 a.m. There is nothing like trying to phone-walk a dyslexic operator through a trouble shooting procedure in the wee hours. This drives home the importance of proper test and rollback procedures.

While I was working for the television station, I kept thinking about time and quantum mechanics. At 4: 15 a.m., Dec. 15, 1997, I woke up with a wonderful idea for an experiment to determine where the direction of time in quantum mechanics comes from. I worked on this on weekends, but after a couple of years, it became apparent this was a full time project. In September of 1999, I signed off from the television station and took about a year off to design the experiment, which will hopefully let me finish my PhD in physics.

In 2001, I went back to work for a portfolio management company, helping the rich become richer. In the course of doing this, it became clear that my basic company focus was "cleaning up after the elephant," which is my new company slogan. When the market tanked, the portfolio company and its contractors parted ways, and I went back to my physics project to finish it off.

I'm pleased to report that the experiment is now completely designed, written up, and on the web at http://xxx.lanl.gov/abs/quant-ph/0306007. Unfortunately a few weeks ago, my wrist and a glass wall got into a dispute, making it clear I will not be typing code for another month or so. I've always wanted to write a book on debugging, since this seems to have been my biggest single professional focus. I'm taking advantage of the enforced professional hiatus to complete my upcoming masterpiece, Zen and The Art of Debugging.

I am delighted that Mac OS X has become robust and usable. I've always used Macs personally, but for the first time I'm able to make use of them professionally as well.