Notes for Susan Lammers Programmers at Work: Interviews with 19 Programmers Who Shaped the Computer Industry

Key concepts: garden of software.

Apparent white male American hegemony “behind the software” notable for software, code, and programming studies.

Related theorists: .

INTRODUCTION

Inspiration of Microsoft Press publisher noting lack of in depth, personal studies of programmers.

Compare to dearth of information about in depth consideration of programmers to predictions about manuals by McGee.

(1) The idea for this series of interviews with notable programmers of our time originated with Min S. Yee, the publisher of Microsoft Press. . . . He noticed parallels between the work of the writer and that of the programmers. . . . When Yee looked in bookstores, he discovered innumerable “how to” books about programming, but a dearth of information that presented the experiences, approaches, and philosophies of software designers in a personal, in-depth manner. So Microsoft Press decided to look into the minds and personalities behind the software.

Are timeless matters philosophy in the context of technology studies, comparing to Stroustrup introduction?

(1) The purpose of each interview was not to interrogate the programmer about secret projects or gather opinions about day-to-day developments within the software industry. Instead, we aimed to discuss timeless matters that often get overlooked in this hectic, fast-paced industry.

Compare to Plutarch Lives and other works in this genre like Out of Their Minds.

(1) In the interviews, I tried to ask all the programmers a common set of questions to provide a framework by which the interviews could later be read and compared.
(2) We gave them the opportunity to rework the interview, so that it expressed exactly what they meant.

Programming style glimpsed when thoughts written down: back to Turkle, Nietzsche, Deleuze, and cultural studies.

How about studying mediocre programmers, not possible in pre-1986 but now readily available examples; or, as Kittler suggests, would there be any value in or interest in studying the average programmer?

(2) In addition, we asked each programmer to provide us with samples of his work – either a piece of code, a program, some sketches or doodles of program designs to provide our readers with a glimpse of the programmer's style when he puts his thoughts down on paper.

Programmer defined in sense of architect develops or designs software, though may not write actual code.

(3) For the purposes of this book, the word programmer is defined as a developer of software or a designer of software, often but not always involved in the actual writing of source code.

Exclusion of UNIX and language inventor notables: does Stallman exist to this writer?

This is why not to include mediocre; but now there is the long tail.

Apparent white male American hegemony behind the software notable for software, code, and programming studies.

This view of the software industry that imagines it started with the personal computer fits Campbell-Kelly observation that microcomputer-based software industry arose from different basis.

(3) We have included a range of ages and experiences from the older, well-established programmers in their forties who first set off the microcomputer revolution, to the younger, energetic, less traditional thinkers who are intent upon taking the computer revolution far beyond the boundaries we know today. . . . Yet there is no doubt that the programmers featured in this book are exceptional and offer intriguing insights into the creative process of programming and the variety of personalities and experiences within the computer industry.
(3) While the intent of the interviews was to discuss the programmer at work, what has come along with the interviews is an informal history of the software industry, as told by some of the major participants involved. The order of the book roughly reflects the history of the industry.
(5) We hope this book will serve as a learning tool for aspiring young programmers, as well as professionals who wish to learn the secrets of success in the software industry from the experts. But even aside from its instructional value, this book is a good read.


Charles Simonyi

Simonyi: for each programmer a page laid out with notes or code snippets on the left, one the right a head shot drawing, name, biography for no apparent order. How to include context of question in notes because pertinent key design issue with this text. Compare interview sequences to my interview form for learning programming.

(8) The first program I ever wrote filled in a magic square, where all the columns and rows added up to the same sum.

Simonyi: compare to Kittler not Floridi point that Turing loved binary coding.

(8) It was a Russian-made computer, a Ural II. It had only 4K of memory, a 40-bit floating point, and 20-bit operations. The computer was programmed totally in octal absolute [no assembler]. I wrote thousands of lines of code in octal absolute.

Simonyi: shared enthrallment with programming with Gates, but on Ural II instead of Altair; everyone can, and should, remember when they first learned programming, and what influenced their style.

(8) The Ural II was exactly like a personal computer because it was just you and the machine and no one else. With 4K of memory and the slow speed, it was very similar to the Altair, which was introduced in 1974. The excitement I experienced with the Ural II in 1964 was the same kind of excitement that Bill Gates experienced with the Altair in 1974.
(10) I had two influences—an engineer in Hungary and the computer I worked on in Denmark.

Simonyi: designed by Naur of BNF, the Algol compiler machine language listings served as Heim huge writing areas whose materiality as printed paper pages gave a place to write out the Algol semantics; this aspect of the function of texts associated with learning programming I had not considered when contemplating the Apple and Timex Sinclair manuals.

Simonyi: Critical code or programming studies point about clever Naur compiler concretizations.

(10) The Danish computer also had an incredible influence on me. At that time, I had probably the world's best Algol compiler, called Gier Algol. Before I went to Denmark, I had complete listings of the compiler, which I had studied inside and out. It was all written in machine language, so it was both a lesson in machine-language programming and an aesthetically beautiful way of thinking about a compilation process. It was designed by Peter Naur.
(10) If you scan backwards they become backward references, which are easy to resolve. Just by looking at a program in a new way, what formerly might have been rather difficult to solve becomes easy to solve.
(11) There is a lot of science in programming, and at the same time it is somewhat of a trade. In fact, for many people, programming is a complex skill, very much like toolmaking, that requires a lot of care.
(13) But if a code has some redeeming qualities, I don't think it needs to be structured in a mathematical sense to be beautiful.

Simonyi: Joke implicit in Hungarian notation.

(13) The joke is that the program looks so unreadable, it might as well be written in Hungarian. But it's a set of conventions that controls the naming of all quantities in the program.
(14) “Hungarian” is a way of almost automatically creating a name from the properties of the named quantity. Very similar to the idea of calling people Taylor if they were tailors and Smyth if they were blacksmiths.

Simonyi: if everyone programmed synaptogenesis may incorporate this computational convention for humans to use working code.

(14) So “Hungarian” introduces some abbreviated notation to encode the properties in a short space.

Simonyi: style of doodling, designing data structures, then code writes itself, likely considered proto object oriented.

(15) The first step in programming is imagining. Just making it crystal clear in my mind what is going to happen. In this initial stage, I use paper and pencil. I just doodle, I don't write code.
(15) The code for the most part writes itself, but it's the data structures I maintain that are the key.

Simonyi: teaching style of learning style writing code accomplishing directed goals.

(15) The knowledge of the best algorithms is the science, and the imagining of the structure is the art. The details of algorithms, writing efficient lines of code to implement transformations on those structures, is the trade aspect of programming.
(16) First, it was easier for me to work in this incredibly high-level language, essentially programming these people. Second, the really learned to program much better than if I had finished it and given them the listing and said, “Study this program.” They learned it because they wrote it.
(18) Programmers get a couple of books on their first day here. One of them, called How to Solve It, is by George Polya, the mathematician.

Simonyi: sees no major changes in programming practices ever.

(19) I don't know that the sixth or the thirty-second generation will do something really drastically different or that great.
(19) I have always worried that when these claimed incredible new benefits come, we will lose all the old ones. The it becomes a kind of trade-off situation where you have to see if you are better off.

Simonyi: reference to Bill Budge who programmed Pinball Construction Set; fun to encounter pinball platform studies variant for end of presentation on long tail.

(21) Bill Budge [who programmed Pinball Construction Set for Electronic Arts]. These guys are all great.

Simonyi: hopefully they are doing incredible stuff together in retirement for benefit of everyone, for example using free software licenses like GPL.

(22) It would be great to be able to work with all these guys, but we are business competitors. I think we could do incredible stuff together.


Butler Lampson
(27) Yes, a friend and I did some hacking on an IBM 650 while I was still in high school. The 650, which was the first business computer, was nearing the end of its useful life, so there wasn't much demand for time on it.

Lampson: importance of combining logical reasoning and experimental sciences or humanities in service of programming.

(28) From mathematics, you learn logical reasoning. You also learn what it means to prove something as well as how to handle abstract essentials. From an experimental science such as physics, or from the humanities, you learn how to make connections in the real world by applying these abstractions.

Lampson: style of precisely defining interfaces.

(33) The most important goal is to define as precisely as possible the interfaces between the system and the rest of the world, as well as the interfaces between the major parts of the systems as well.
(33) Programmers often lose sight of the fact that the problems in building software systems arise because what they are trying to do is just too hard. They believe the computer is a universal engine that can do anything. It's very easy to be seduced into the proposition that a group of one or five or ten or fifty or a thousand programmers can make the computer do anything.

Lampson: organizing solution into manageable structure.

(33) The most important quality is the ability to organize the solution to the problem into a manageable structure, with each component specified in a simple way.

Lampson: computer revolution has not happened yet.

(36) I give a talk to general audiences titled The Computer Revolution Hasn't Happened Yet. Its basic theme is that major changes in the world take a long time.
(37) Even in situations where big organizations like banks are intimately and unavoidably involved in our lives, we can still find ways to give individuals far more control by using machines cleverly.

Lampson: not worth universal learning literacy in a single language.

(38) To hell with computer literacy. It's absolutely ridiculous. Study mathematics. Lean to think. Read. Write. These things are of more enduring value. Learn how to prove theorems: A lot of evidence has accumulated over the centuries that suggests this skill is transferable to many other things. To study only BASIC programming is absurd.

Lampson: programming as giving computer instructions, which is equivocable to using spreadsheets and other cultural software, versus creative programming.

(38) If programming just means giving the computer instructions, I think everybody will do that at some level. Most business people operate a spreadsheet and that's programming in some sense. I think you'll see more of that. Creative programming is another matter.


John Warnock

Warnock: style of preference for interpretive environment and interactive languages like LISP.

(44) I prefer the LISP-style languages, because they're more interactive and they're interpreters; I like the interpretive environment.

Warnock: writing programs like writing books: must be willing to scrap bad parts, borrow from others.

(47) It's very important that a programmer be able to look at a piece of code like a bad chapter of a book and scrap it without looking back.
(47) Also, never make an assumption that you know something somebody else doesn't know.
(47) It's a matter of picking and choosing from that smorgasbord to make a good menu, so to speak, to do a given task.
(49) If you really want to be successful, being acculturated to the rest of the society and then going into computers is a much more reasonable way to approach the problem.
(53) We use whatever has the most reasonable environment and set of compilers; those are the considerations. Computer languages are computer languages. Once you've learned a half dozen, the next half dozen aren't very hard to learn.

Warnock: programs reflect the organization in which they are written.

(54) I once heard that any programs you write reflect the organization in which you work.
(55) The best mathematics of computation was done before the advent of computers. Mathematicians laid much of the groundwork of what could and couldn't be done in computers.


Gary Kildall
(58) I would teach the course I enjoyed most, the data structures course. It goes back to the fundamentals of programming: simplifying the problem.
(59) I start with drawing the data structures, and I spend a lot of time thinking about them. I also think about what the program has to go through before I start writing code.

Killdall: style of drawing data structures and program operations before writing code; automotive transmission mechanical gearwork (Papert); fast edit, execute, debug cycles for iterative improvement; few written comments in favor of well-written code; spontaneous coding from written description of algorithms; concise and efficient ALGOL philosophy.

(59) Programs are like mechanical devices; the way one piece of code works with another is very similar to the way one gear meshes with another gear. Building code is a little like building a transmission.
(60) This whole process of iterative improvement requires speed, so for me at least, it's very important to have fast edit, execute, and debug cycles.
(60) But a friend of mine had this FORTRAN statement card, showed it to me, and told me it was going to be a really big thing. I became so intrigued I had to get into it. So I took an assembly-language programming course and FORTRAN right after that, and I was hooked. I found I liked programming for the same reasons I liked to build models, cars, and things of that sort.
(60) It [first program] calculated the number of seconds between any two times of the day and any two calendar days.
(61) Rarely, except at the beginning of procedures, and then I only comment on the data structure. I don't comment on the code itself because I feel that properly written code is very much self-documented. . . . The actual coding process has always been a little scary for me because I don't know if I'm writing the write code, nor do I know what I'll write next. It just seems to come out.
(61) When I reach the point where the code coalesces, I'm certain the program will work, and I also have no doubt I did it about the best way it could be done.
(62) Semour Papert has this notion that kids learn to be inventive by tinkering with gears and other mechanical gadgets. The skills you learn and practice with this kind of play carry over into other areas. Papert is certainly talking about my childhood experience. My father was a great craftsman. I used to stay and watch him by the hour, and then I would go outside and try to imitate him with my own hammer and nails.
(62) Data structures, which are the foundations of programs, are mechanical by nature, like the things I played with as a kid.
(62-63) You need to study other people's work. Their approaches to problem solving and the tools they use give you a fresh way to look at your own work.

Kildall: Admits ALGOL philosophy entrenched from spending considerable time studying and modifying the Baur compiler, evidence of important selection of tutor texts and need for long habituation and deep, active study of them in critical programming studies; pick up with Ratliff parser creation as precondition of machine intelligence.

(63) I'm very pragmatic. I like to build programs that are fast and small, and use clear, concise algorithms. I learned that style from the early Burroughs 5500, a very advanced machine for the day, which was based upon the ALGOL philosophy of block-structured languages. The ALGOL compiler was probably one of the nicest pieces of code to come out at that time. I spent hours trying to fix and change the compiler. Working with it so closely affected the way I think about programming and had a profound influence on my style. Fortunately, the ALGOL philosophy became the basis for design of popular languages like Pascal and C, so the style works for me.
(64) When you've got the code all ripped apart, it's like a car that's all disassembled. You've got all the parts lying all over your garage and you have to replace the broken part of the car will never run.
(64) There's a concise form of LISP called the M expressions. When you write an algorithm using M expressions, it's so beautiful you almost feel it could be framed and hung on a wall.
(65) There certainly is some art in it. But a lot of programming is invention and engineering. It's much like a carpenter who has a mental picture of a cabinet he's trying to build. He has to wrestle with the design and construction to get it into a physical form.
(65) But remember, I'm in one special area of programming: compilers, operating systems, retrieval, and other system software. A programmer who specializes in graphics, for example, may have an entirely different view of the programming world. . . . You know, I also think programming is very much a religious experience for a lot of people.

Kildall: admits impact of doing systems programming on these preferences, suggesting graphics programmers may develop others, also religious connotations.

(65-66) They form a tight-knit community, hold to certain beliefs, and follow certain rules in their programming. It's like a church with a programming language for a Bible.
(67) Ultimately the problem is that we, as a society, took the big computers that we understood and applied their underlying architectures, languages, and concepts to the development of microcomputers. As we move toward using computers as controllers, we will find that communication between processors will become more important than the processes they are carrying out. Then we will be forced to change the way we code. That will be a very slow evolutionary process.


Bill Gates
(72) I'd have to say BASIC for the 8080, because of the effect it's had, and because of how appropriate it was at the time, and because we managed to get it so small. It was the original program we wrote when we decided to start Microsoft.
(72) Three of us knew that original program by heart.

Gates: style of thorough ideation first, most like Turkle hard mastery; simplicity, rule based.

(73) You have to simulate in your mind how the program's going to work, and you have to have a complete grasp of how the various pieces of the program work together. The finest pieces of software are those where one individual has a complete sense of exactly how the program works.
(75) Some people just jump in and start coding, and others think it all through before they sit down, but I think you'd find that the programmers who sit down and code at the beginning are only using that as a scratch pad. It's what's going on in their heads that's most important.
(78) One sign of very good programs is that even internally they follow that philosophy of simplicity. If they want to do something complex, they call the code with simple operations internally, rather than doing the complex operation from scratch.

Gates: hope of a factory owner that most programming tasks can be automated, compare to dreams of autoprogramming and management studies.

(81) People will still design algorithms, but a lot of the implementation could be done by machines. I think that within the next five years we'll have tools that will be able to do as good a job as a human programmer.
(81) The fact that people are getting exposed to computers at such young ages now will help change the thinking in the field. A lot of great programmers programmed when they were in their teens, when the way you think about things is perhaps more flexible.

Gates: hermeneutic code study reveals competency.

(83) I still think that one of the finest tests of programming ability is to had the programmer about 30 pages of code and see how quickly he can read through and understand it.
(83) If you ever talk to a great programmer, you'll find he knows his tools like an artist knows his paintbrushes. It's amazing to see how much great programmers have in common in the way they developed—how they got their feedback, and how they developed such a refined sense of discipline about what's sloppy and what's not sloppy.
(85) Rule-based programming is the idea of having the derivations done through a proving machine, not just laid out explicitly in the program. Perhaps these techniques won't have an impact for four or five more years.
(87) It's a new interface; it's got nothing to do with productivity tools like word processors or spreadsheets. CD ROM programs will solve totally different problems. Like any new media, it'll be incredibly competitive.


John Page
(94)
He thought a code sample would be relatively meaningless to the reader. Instead he suggested we list his many achievements and contributions to the computer world. It was this remark, more than any other, that exemplified Page's approach to programming. He has the ordinary user in the forefront of his thoughts as he goes about the task of developing software. It is the end result, not so much the means used in getting there, which fascinates and motivates Page.

Page: style of prioritizing end user, setting goal and executing with tunnel vision, C, single mind design, not hiding technology from user, high productivity over high control, working solutions trump conforming with ideals of computer science.

Page: complicated programs easier to write because complexity projected onto user like difficult to read technical or philosophical texts.

(95) In designing PFS, I stumbled over an odd software design principle: Complicated programs are far easier to write than straightforward programs—the exact opposite of what you'd expect. It's easy to write complicated programs because you reflect the complexity back onto the user; you force the user to make all the hard decisions.
(95-96) Don't forget the PFS program is the most long-lived program on the market now that VisiCalc is gone. Back then, five years ago, there was no C, so it was a choice between BASIC, Assembler, or Pascal. . . . Remember, too, this was before the invention of the IBM PC, so the only machine on the market worth considering was the Apple II, and Pascal was the only program language that met my needs on that machine.

Page: prefers compiled C over interpreted Pascal and BASIC.

(96) We're switching to C as we develop new versions because it is a better development language than Pascal.
(96) The Pascal was interpreted, which meant its performance left a whole lot to be desired. And once the program was finished, it was extremely slow, so I isolated all of the areas where the performance bottlenecks occurred and recoded those in Assembly language.
(97) What I tend to do in life is work out my goals, and once they're set, I never re-examine them, or think about how hard it is, or whether it's still worth doing, or whether it will be successful.
(98) I believe very strongly that one person, certainly no more than two, should do the design and high-level structure. You get a consistency and elegance when it springs from one mind.
(100) Computers are stuck in a rut because nothing new has happened in quite a while. The market has sucked us into overly complicated systems and the fault is mostly IBM's. All the “new” features being installed are borrowed from minicomputers and mainframes. . . . Even the poor old Macintosh is being battered because it doesn't have all the things that managers of management information systems love.
(101) I'm also optimistic that the industry will return to making proper personal computers that people will be able to use, like the original Apple.
(102) The trick is to get around that infatuation with technology. Unfortunately, because SPC deliberately hides the technology from the user, we are often regarded as a company not dedicated to sound technologies.
(103) The design problem becomes an issue of control versus productivity. You can have either high productivity or a great deal of control.
(107) The lack of physical exercise does most programmers in.
(107) You constantly try to hold the state of the entire system you're working on in your head. If you lose the mental image, it takes a long time to get back into that state.
(108) But often, if I think about it long and hard enough, I'll find a way around the problem. It may not be an elegant solution and it might not conform to all the rules of computer science, but to heck with that if it works.


C. Wayne Ratliff

Ratliff: example code is C subroutines from dBASE III illustrating style.

(114) I decided that the world needed a natural-language database manager.

Ratliff: style of open-ended toolmaker, enough planning to get to next step, which is reached emotionally and intuitively; ideal modules are all page length, equally distributed hierarchy; alphabetizing, few comments; enjoys challenge over addressing social needs.

(116) dBASE caught people's imaginations because it's very open-ended. The way I've programmed all my life is as a toolmaker.
(118) So now, programming is much more evolutionary, when before it was sort of a big bang.
(119) I'm the kind of programmer who likes to do some planning, but I don't plan everything out in infinite detail. I have an idea of what the goal is, but the real job is to find out what the next step is to get toward that goal. I try to do the minimum that will get me one step further. . . . It's not mathematically defined. It's emotionally and intuitively defined.
(120) The ideal module should be a page long. . . . Part of the elegance, and the balance, is that at a certain level, in this layer-cake hierarchy of a program, all the modules should be about the same weight, same size, same duty, and same functionality.
(121) I was really impressed by a book by Glenford J. Meyers, called Software Reliability. . . . Putting things in alphabetical order is a trick I learned from programming style books.
(121) I am almost of the opinion that the more comments you need, the worse your program is and something is wrong with it.
(121) You definitely need one line of comment at the top of each module, which explains what the module does in one sentence.
(122) Curiously enough, game writers are most in tune with the user.
(123) I even modified one program, a C-beautifier program, to do it automatically. I can take someone else's code and run it through this program, and it will be indented the way I indent.
(123) So this long process necessary for training the machine kills AI, as far as it being a turnkey product.
(124) I'm really enamored with a UNIX program called
yacc that builds you a parser. You give it specifications for your language in Backus-Naur form, which is widely accepted in the computer-science industry. It will crank out a C module that parses a language that fits the specs. I'd love to be able to do that for a higher-level program.

Ratliff: arriving from Kildall articulating preconditions of creating human programmers, parser building software embodies goal Gates and other identify of code generated code generation permitting large scale programming operations to continue to be performed replacing repetitive coding previously performed by masses of clueless programmers doing menial repetitive object definitions akin to setting parameters in run time dynamic configuration required for the software to run as precondition of emergent distributed local and world network planetary machine intelligence; thus we should not be surprised that the community building sense of social machines have been working us all along. Must concurrently consider Floridi characterization of ISA affects philosophies of computing let alone programming. Applying Applen and McDaniel rhetorical XML closes the loop for self reprogramming preconditions of machine intelligence PHI.

(124) You have some little spark, and then you keep tacking other capabilities onto it. When that euphoria fades and you have to start coding, it gets tough.
(126) My goal is to write neat software, programs that are challenging. It's not my mission to solve social needs, but that can be another nice outcome for software.


Dan Bricklin

Bricklin: style of cultivating a garden of software that meets his needs; laying out data structure and human interface.

(132) As Bricklin says, his intent is not to run a ranch or tend a farm, but to cultivate a garden of software, just like a garden in the backyard; one that is sufficient to meet his needs and from which he can gain pleasure and satisfaction.
(139) To me, the most important part of a program is laying out the data structure. You also have to know what the human interface is going to be like.

Bricklin: users do programming via style sheets and spreadsheets.

(147) We're just making the users do more and more of the programming themselves, but they don't know it. Using different style sheets with Microsoft Word is doing programming; using spreadsheets is doing programming.


Bob Frankston

Frankston: style of code that is easy to pick up and modify.

(159) I've had people say that it's easier to pick up my code, and I really do write it so people can pick it up. Also, I write so I can pick up the code and make local changes without worrying too much about the effect. The comments are mainly to warn about surprises.


Jonathan Sachs
(164) I don't have anything against FORTRAN, but getting only a couple tries per day to run your program is pretty frustrating.
(166-167) I can to the office about once a week and brought in a new version [of 1-2-3]. I fixed any bugs immediately in the next version. Also, people at Lotus were using the program continuously.

Sachs: style of rapid iterations starting with basic working unit; visualizing then writing automatic; avoids immutable third party tools.

(167) That's how I've always done things when I work by myself. I get the program up so that it just begins to work, and then I add features to it.
(169) Math is too hard. I can do mathematics up to the point where I stop being able to visualize the problem. When it gets abstract, I can't do it.
(169) Once you get a certain level of experience, you go from the idea to the program without even thinking about all the intermediate steps; the process becomes automatic.
(171) First, I start out with a basic program framework, which I keep adding to. Also, I try not to use many fancy features in a language or a program. . . . I don't like using any tools or programs I didn't write myself or that I don't have some control over. That way if I don't like some part, I can change it. As a rule, I like to keep programs simple.
(172) I'm not a particularly creative person; my real skill is taking ideas and integrating them to make a nice package.


Remaining programmers are more men: Ozzie, Roizen, Carr, Raskin, Hertzfeld, Iwatani, Kim, Lanier, Hawley.

Ray Ozzie
()


Peter Roizen
()


Bob Carr
()


Jef Raskin
()


Andy Hertzfeld
()


Toru Iwatani
()


Scott Kim
()


Jaron Lanier
()


Michael Hawley
()



Lammers, Susan. Programmers at Work: Interviews with 19 Programmers Who Shaped the Computer Industry. Redmond, WA: Tempus, 1989. Print.