Peter Seibel is either a writer turned programmer or programmer turnedwriter. After picking up an undergraduate degree in English and workingbriefly as a journalist, he was seduced by the web. In the early '90s hehacked Perl for Mother Jones Magazine and Organic Online. He participatedin the Java revolution as an early employee at WebLogic and later taughtJava programming at UC Berkeley Extension. In 2003 he quit his job as thearchitect of a Java-based transactional messaging system, planning to hackLisp for a year. Instead he ended up spending two years writing the JoltProductivity Award–winning Practical Common Lisp. Since then he’s beenworking as chief monkey at Gigamonkeys Consulting, learning to trainchickens, practicing Tai Chi, and being a dad. He lives in Berkeley, California,with his wife Lily, daughter Amelia, and dog Mahlanie.

Leaving aside the work of Ada Lovelace—the 19th century countess who devisedalgorithms for Charles Babbage’s never-completed Analytical Engine—computerprogramming has existed as a human endeavor for less than one human lifetime:it has been only 68 years since Konrad Zuse unveiled his Z3 electro-mechanicalcomputer in 1941, the first working general-purpose computer. And it’s beenonly 64 years since six women—Kay Antonelli, Jean Bartik, Betty Holberton,Marlyn Meltzer, Frances Spence, and Ruth Teitelbaum—were pulled from the ranksof the U.S. Army’s “computer corps”, the women who computed ballistics tablesby hand, to become the first programmers of ENIAC, the first general-purposeelectronic computer. There are many people alive today—the leading edge of theBaby Boom generation and all of the Boomers’ parents—who were born into a worldwithout computer programmers.

No more, of course. Now the world is awash in programmers. Accordingto the Bureau of Labor Statistics, in the United States in 2008 approximatelyone in every 106 workers—over 1.25 million people—was a computerprogrammer or software engineer. And that doesn’t count professionalprogrammers outside the U.S. nor the many student and hobbyistprogrammers and people whose official job is something else but who spendsome or even a lot of their time trying to bend a computer to their will.Yet despite the millions of people who have written code, and the billions, ifnot trillions of lines of code written since the field began, it still often feelslike we’re still making it up as we go along. People still argue about whatprogramming is: mathematics or engineering? Craft, art, or science? Wecertainly argue—often with great vehemence—about the best way to do it:the Internet overflows with blog articles and forum postings about this orthat way of writing code. And bookstores are chock-a-block with booksabout new programming languages, new methodologies, new ways ofthinking about the task of programming.

This book takes a different approach to getting at what programming is,following in the tradition established when the literary journal The ParisReview sent two professors to interview the novelist E.M. Forster, the firstin a series of Q&A interviews later collected in the book Writers at Work.

I sat down with fifteen highly accomplished programmers with a wide rangeof experiences in the field—heads down systems hackers such as KenThompson, inventor of Unix, and Bernie Cosell, one of the originalimplementers of the ARPANET; programmers who combine strongacademic credentials with hacker cred such as Donald Knuth, Guy Steele,and Simon Peyton Jones; industrial researchers such as Fran Allen of IBM,Joe Armstrong of Ericsson, and Peter Norvig at Google; Xerox PARCalumni Dan Ingalls and L Peter Deutsch; early Netscape implementers JamieZawinski and Brendan Eich; folks involved in the design and implementationof the languages the present-day web, Eich again as well as DouglasCrockford and Joshua Bloch; and Brad Fitzpatrick, inventor of Live Journal,and an able representative of the generation of programmers who came ofage with the Web.

I asked these folks about programming: how they learned to do it, whatthey’ve discovered along the way, and what they think about its future.More particularly, I tried to get them to talk about the issues thatprogrammers wrestle with all the time: How should we design software?What role do programming languages play in helping us be productive oravoid errors? Are there ways we can make it easier to track down hard-tofindbugs?

As these are far from settled questions, it’s perhaps unsurprising that mysubjects sometimes had quite varied opinions. Jamie Zawinski and DanIngalls emphasized the importance of getting code up and running right awaywhile Joshua Bloch described how he designs APIs and tests whether theycan support the code he wants to write against them before he does anyimplementation and Donald Knuth described how he wrote a completeversion of his typesetting software TeX in pencil before he started typing inany code. And while Fran Allen lay much of the blame for the decline ininterest in computer science in recent decades at the feet of C and BernieCosell called it the “biggest security problem to befall modern computers”,Ken Thompson argued that security problems are caused by programmers,not their programming languages and Donald Knuth described C’s use ofpointers as one of the “most amazing improvements in notation” he’s seen.Some of my subjects scoffed at the notion that formal proofs could be usefulin improving the quality of software, but Guy Steele gave a very niceillustration of both their power and their limitations.

There were, however, some common themes: almost everybodyemphasized the importance of writing readable code; most of my subjectshave found that the hardest bugs to track down are in concurrent code; andnobody seemed to think programming is a solved problem: most are stilllooking for a better way to write software, whether by finding ways toautomatically analyze code, coming up with better ways for programmers towork together, or finding (or designing) better programming languages. Andalmost everyone seemed to think that ubiquitous multi-core CPUs are goingto force some serious changes in the way software is written.

These conversations took place at a particular moment in our field’s history,so no doubt some of the topics discussed in this book will fade from urgentpresent-day issues to historical curiosities. But even in a field as young asprogramming, history can hold lessons for us. Beyond that, I suspect that mysubjects have shared some insights into what programming is and how wecould do it better that will be useful to programmers today and toprogrammers several generations from now.

Finally, a note on the title: we chose Coders at Work for its resonance withthe previously mentioned Paris Review’s Writers at Work series as well asApress’s book Founders at Work, which does for starting a technologycompany what this book tries to do for computer programming. I realizethat “coding” could be taken to refer to only one rather narrow part of thelarger activity of programming. Personally I have never believed that it ispossible to be a good coder without being a good programmer nor a goodprogrammer without being a good designer, communicator, and thinker.Certainly all of my subjects are all of those and much more and I believe theconversations you are about to read reflect that. Enjoy!