“Absolutely amazing! A page turner, just like Harry Potter for the technically minded.” —Tobias Svensson from review at return 42;

“This book is so interesting I did 60 minutes on the treadmill yesterday instead of the usual 30 because I couldn’t stop reading.” —Joel Spolsky on Joel on Software

“Coders at Work should inspire readers to learn about the wider context of their craft and stop the reinvention of the proverbial wheel” —Vladimir Sedach from review at Slashdot

“Peter Seibel asks the sort of questions only a fellow programmer would ask. Reading this book may be the next best thing to chatting with these illustrious programmers in person.” —Ehud Lamm, Founder of Lambda the Ultimate - the programming languages weblog

“I highly recommend it.” —Andy Mulholland, CTO, Capgemini

“I have long known the names and of the work of about half of the programmers in Peter Seibel’s wonderful book, Coders at Work; and it is fascinating to read their ideas about their lives and their ideas about programming. Better yet, I have now learned about the lives and philosophies of the other half of the programmers in the book, whose systems were known to me but the programmers themselves were not. Anyone interested in computer programming and what makes a great computer programmer will enjoy this book.” —Dave Walden, original member of the BBN ARPANET team

“These are wonderful interviews and this looks to be a bible for any programmer who aspires to be better.” —Peter Christensen, Founder of GeekStack.com

“This book is dead sexy. When it comes out, you should definitely get a copy.” —Joseph F. Miklojcik III from review at jfm3> _

“Superb book!” —Prakash Swaminathan from review at CloudKnow

“Read it, because then you will know the greatest coding brains.” —Amit Shaw from review at Teleported Bits

“One of the other core questions Peter asks is, what books would you recommend to help a developer learn programming? For me, this book joins my short list—it takes you away from the limitations of learning within a single company or community, and shows you the breadth of experiences that can make someone a great developer.” —Marc Hedlund from review at O’Reilly Radar

“The range of topics covered is just astounding.” —Chris Hartjes from review at @TheKeyboard

Peter Norvig

Peter Norvig is a broad thinker and a hacker at heart. He once wrote a program to find in Google’s search logs series of three consecutive searches by the same user that, when put together, made a haiku (one of the most memorable: “java ECC / java elliptical curve / playboy faq”).

On his web site Norvig has links to the usual stuff: books and papers he’s written, slides from talks he’s given, and various bits of his code. But there are also links to items he’s had published in McSweeney’s Quarterly Concern, his witty recounting of writing a program to generate the world’s longest palindromic sentence, and his “Gettysburg Powerpoint Presentation,” a send-up of Microsoft’s PowerPoint software, which has been cited by Edward Tufte and which appears on the first page of results if you Google “PowerPoint.”

He is now the Director of Research at Google, after having been the Director of Search Quality. Prior to that he had been the head of the Computational Sciences Division at NASA Ames Research Center and before that, an early employee at the late-’90s Internet startup Junglee. He won the NASA Exceptional Achievement Award in 2001 and is a Fellow of the American Association for Artificial Intelligence and the Association for Computing Machinery.

Between Google, NASA, and Junglee, Norvig has experience with both the “hacker” and “engineer” approaches to building software and talks in this interview about the advantages and disadvantages of each. As a former computer-science professor and now an insider at one of the biggest industrial software shops in the world, he also has an interesting perspective on the relation between academic computer science and industrial practice.

Other topics in our conversation included how programming has changed in recent years, why no design technique can make up for not knowing what you’re doing, and why NASA might be better off with less-reliable but cheaper software.