Peter SeibelKirja-arvosteluja

I give the interviewees four stars, and the final result fewer stars. Interviewees repeated each other and were too rambly for book. What passes for a good podcast transcript doesn't meet my expectations for what a good interview driven book is.

very cool book. interesting to hear in their own words from some famous computer people. my favorite theme from the book was the ultimate importance of enthusiasm as an indicator of someone being good. enthusiasm is everything . also reassuring know that even some of these people who have done amazing things don't comment much and use print statements to debug. basically just do cool stuff that interests you always

This was an interesting read but definitely one that is better read in parts. The interviews start getting a little repetitive, you'll appreciate taking a breather now and then. Definitely get through to the end, though. I don't want to give it away but Knuth talks a little bit about The Art of Computer Programming: The Movie.

I loved "Coders at work". It consists of in-depth interviews with 15 very accomplished and famous programmers. The author Peter Seibel has, in my opinion, done an outstanding job with these interviews.

First, he picked a stellar set of super star programmers to interview. Second, he asked very interesting questions, some of which only a fellow programmer would ask. Third, he asked several questions to all of his subjects, which allows the reader to compare and contrast the answers, while also asking questions about each programmer's special areas of interest.

To give you a sense of the questions he asked, here are some samples: "How do you design code?", "What is the worst bug you've ever had to track down?", "What's your preferred debugging techniques and tools? Print statements? Symbolic debuggers? Formal proofs?" and "As a programmer, do you consider yourself a scientist, an engineer, an artist, or a craftsman?". I think these are all excellent questions, and I learned a lot by reading all the different answers.

Each interview is on average 40 pages long (the whole book is about 600 pages), so it took me a while to read it, even though it was a pretty easy read. But this also means that there is room to ask a lot of questions. You can tell from the questions and follow-up questions that Peter Seibel is himself an experienced programmer. In addition, he seems very well read. He recognizes and comments on almost any book or research paper that is mentioned during the interviews. For example, Joshua Bloch mentioned the book Hacker's Delight, and Peter Seibel's comment is "that's the bit-twiddling book?".

Occasionally there are some pretty funny comments from Peter Seibel too. When Simon Peyton Jones talked about how he had not had a lot of experience with C , he ended by saying "... I never really spent several years writing big C programs. That's how you get some kind of deep, visceral feel and I never have". To which Peter Seibel replied "I think that feeling is usually revulsion".

While reading the book, I wondered whether I would get tired of the interviews by the end, but that did not happen. It kept being interesting till the end (and that's not just because Donald Knuth, arguably the most famous of them all, is last). For me, the most interesting interviews were the ones with Simon Peyton Jones and Peter Norvig. But even the least interesting interviews (for me that was the ones with L Peter Deutsch and Fran Allen) were still very good. In fact, even a single one of these interviews is worth the price of the book in my opinion.

There is also a historical quality to the book. The majority of the people interviewed started programming in the 50s or the early 60s. One of the standard questions was "How did you learn to program?" and I thought it was quite interesting to read about the old computers they used, the punch cards etc. It was almost like little history lessons from the computing field.

Almost as soon as I started reading this book, I grabbed a piece of paper and jotted down things of interest: concepts I hadn't heard about before, quotes, new languages to try, references to papers and blog posts, books that were recommended etc. When I got to the end, I had accumulated 6 full pages worth of notes. To me, that's an indication of the quality of the interviews, and of the value I got out of the book.

OK, one small complaint: it would have been nice with a picture of each of the interviewees, so we can see what they look like.

It is also worth mentioning that both Joe Armstrong and Simon Peyton Jones have been interviewed at Software Engineering Radio ([...]) - both those interviews were very good, definitely worth listening to. Also, Peter Seibel was interview about "Coders at work" by Jeff Atwood and Joel Spolsky on the StackOverflow podcast (episode 69). And Peter Seibel has some interesting blog posts with excerpts from the book at his site [...] - check them out.

If you are seriously interested in programming, this is definitely one of the books you should read. Highly recommended.

I thought it was a pretty great book on Lisp, although it's hard to distinguish how much of this is from the elegance of the language itself, my understanding of computer languages in an abstract sense, or the writer's ability to put together a sticky and comprehensive tutorial.

I certainly didn't feel like this book went overlong, as many tutorials so. Every chapter felt really short, and explained everything relatively tersely. The author seemed happy to talk about theory and esoteric concerns in the footnotes, which I chose to read and sometimes become overwhelmed by, but this was an option I had.

While the book is organized well as a primer, it is somewhat overwhelming in that functions are just thrown at you in related groups for each chapter. Having read through this book once has taught me the basics of the language but hasn't necessarily taught me how to *think* in LISP (the way [b:Land of LISP: Learn to Program in LISP, One Game at a Time!|6905041|Land of LISP Learn to Program in LISP, One Game at a Time!|Conrad Barski|https://i.gr-assets.com/images/S/compressed.photo.goodreads.com/books/1403198191l/6905041._SX50_.jpg|7129234] seems to be approaching it. That being said, when I finally say "I should really get familiar with doing X in Lisp" I will probably know exactly where in PCL to look. I have a feeling that every primary feature of Lisp is touched upon in the book, it's just a matter of retaining it and perhaps understanding the context.

It's hard for me to gauge because I have programming languages (including functional ones like Scheme) under my belt already, but if you want to learn Common Lisp I'd definitely pick up this book as one of my first. I wouldn't sweat comprehending it too much, but it would at least give me an overall view of the terrain before I went into books like Land of Lisp or other books on functional programming before coming back and constantly referencing this book as I was getting my sea legs going.

Software developers are typically bright people but possess few social contacts who approach the world like them. Such loneliness is famously parodied by stereotypes. Even the most social among us have a difficult time relating to others what programming is like. In this work, Seibel provides interviews with 15 accomplished programmers and alleviates some of that alone-ness. In so doing, he explains to the English-speaking world how computer programming has grown and is currently practiced.

The interviewees compose a veritable who’s who of computer science – including, at the end, Donald Knuth, who is widely regarded as the best programmer of all time. Fran Allen, a widely recognized female programmer, is included. Some were educated well at Harvard or MIT. Others were, to a large degree, self-taught before the discipline of computer science was established. All convey a unique perspective about how they write code.

For the most part, Seibel asks each person a similar set of questions: about their background, formative experiences, approach to the craft of coding, and their approach to a new trend of literate programming. It’s amazing to see how wide the range of different opinions is! They all seem to disagree, especially about very important things. Providing room for (sometimes heated) disagreements is healthy for computer programmers who are smart but have few companions. After all, we must work together to accomplish work.

This is not a technical work. Neither code nor math is presented. It’s more of a biographical work of 16 different programmers. It spans the lanes of human interest and computer science. Non-programmers might be interested in learning how IT people work, but the obvious audience here consists of software developers. By grabbing big-name interviews, Seibel hits the sweet spot for this audience and knocks a homer out of the park.

In particular, expositions such as this allow people to see the history of computing. Readers get to see innovators, spanning back to the 1950s until the date of publication in 2009. These people changed the world such that a mini-computer resides in many people’s pockets in the developed world, in the form of a smart phone. They went from coding in assembly code to writing in higher-level languages to co-writing in more everyday language. That history of science will be of interest to readers in the future when future students seek to learn about the “old days” when computers were young. And we will have the writer Peter Seibel to thank.

I read this over several months, in 10-minute bursts on my daily T ride to work. I'd have bits and pieces of this rattling around in my head at work some days.

It was an odd feeling reading the experiences and thoughts of programmers who by and large came of age during a time where it was quite reasonable for a human to understand the entirety of what a computer was doing. We now work instead in a world of dizzying but invisible depth in technology; able to do amazing things, but no single human can comprehend the whole of it.

Truely inspiring and interesting collection of interviews with well known programmers. The only thing bothering me slightly while reading the book is that Seidel seems to stick to his collection of pre baked questions a bit too rigorously. In quite a few cases he misses obvious follow up questions. An overview of all the works recommended by the interviewees would have been nice as well.

A great book for old guys like me who started programing with punched cards.

A fun read to hear the stories of famous programmers and to understand how they think about their specialties. It's inspiring to see that almost all of them come across as normal, humble people that are started like everyone else. Unfortunately, not all the interview questions brought out interesting responses: the questions that focused on the programmer's expertise and history were great; the canned/rigid questions like "how do you read code" or "do high level degrees matter" were less great, often resulting in "it depends" or vague answers.

Some fun quotes from the book:

Zawinski: Your competitor’s six-month 1.0 has crap code and they’re going to have to rewrite it in two years but, guess what: they can rewrite it because you don’t have a job anymore.

Zawinski: I find that getting something on the screen as soon as possible really helps focus the problem for me. It helps me decide what to work on next.

Fitzpatrick: In practice, nothing works. There are all these beautiful abstractions that are backed by shit. The implementation of libraries that look like they could be beautiful are shit.

Seibel: any piece of code contains bits of embedded knowledge—little bits of cruft that are hard-won functionality that you don’t think of when you say, “Oh, we can just rewrite this.”

Crockford: I haven’t figured out a sufficiently useful way of testing units of JavaScript yet.

Eich: While producing a lot of code is still important, what has interested me—and this is something that we talked about at Netscape when we talked about their track for principal engineer—is somebody who isn’t management but still has enough leadership or influence to cause other programmers to write code like they would write without them having to do it, because you don’t have enough hours in the day or fingers.

Bloch: when you choose a language, you’re choosing more than a set of technical trade-offs—you’re choosing a community. It’s like choosing a bar. Yes, you want to go to a bar that serves good drinks, but that’s not the most important thing. It’s who hangs out there and what they talk about. And that’s the way you choose computer languages. Over time the community builds up around the language—not only the people, but the software artifacts: tools, libraries, and so forth. That’s one of the reasons that sometimes languages that are, on paper, better than other languages don’t win—because they just haven’t built the right communities around themselves.

Bloch: Many customers won’t tell you a problem; they’ll tell you a solution.

Bloch: But the fundamental rule is, write the code that uses the API before you write the code that implements it.

Bloch: there are some people who, in Kevin Bourrillion’s words, “lack the empathy gene.” You aren’t going to be a good API designer or language designer if you can’t put yourself in the shoes of an ordinary programmer trying to use your API or language to get something done.

Armstrong: To me programming isn’t about typing code into a machine. Programming is about understanding.

Armstrong: the central core of functional programming is the idea of nonmutable state—that x isn’t the name of a location in memory; it’s a value.

Armstrong: Then there’s—I don’t know if I read it somewhere or if I invented it myself—Joe’s Law of Debugging, which is that all errors will be plus/minus three statements of the place you last changed the program.

Armstrong: The code shows me what it does. It doesn’t show me what it’s supposed to do. I think the code is the answer to a problem. If you don’t have the spec or you don’t have any documentation, you have to guess what the problem is from the answer. You might guess wrong. I want to be told what the problem is.

Armstrong: You were asking earlier what should one do to become a better programmer? Spend 20 percent of your time learning stuff—because it’s compounded.

Armstrong: I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. If you have referentially transparent code, if you have pure functions — all the data comes in its input arguments and everything goes out and leave no state behind — it’s incredibly reusable.

Jones: This was my main insight about small companies: to be an entrepreneur you need to get energy from stressful situations involving money, whereas my energy is sapped by stressful situations involving money.

Jones: when the limestone of imperative programming is worn away, the granite of functional programming will be observed.

Jones: One thing that is hard, even for professional software engineers and developers, is to viscerally grok the size of the artifacts on which we work. You’re looking at the Empire State Building through a 1-foot-square porthole, so it’s difficult to have a real feel for how gigantic the structure you’re looking at is. And how it’s interconnected.

Deutsch: Language systems stand on a tripod. There’s the language, there’s the libraries, and there are the tools. And how successful a language is depends on a complex interaction between those three things.

Allen: Part of it is that there’s the potential for new ideas every day. One sees something, and says, “Oh, that’s new.” The whole field gets refreshed very frequently. It’s very exciting to think about what the potential for all of this is and the impacts it can have.
Isaac Asimov made a statement about the future of computers—I don’t know whether it’s right or not—that what they’ll do is make every one of us much more creative. Computing would launch the age of creativity.

Knuth: I think that’s a fundamental error made by scientists in every field. They don’t realize that when you’re learning something you’ve got to see something at all levels. You’ve got to see the floor before you build the ceiling. That all goes into the brain and gets shoved down to the point where the older people forget that they needed it.

Knuth: I try to give the key ideas and I try to simplify them the best I can, but then what happens is every five pages of my book is somebody’s career.

Knuth: The first rule of writing is to understand your audience—the better you know your reader the better you can write, of course. The second rule, for technical writing, is say everything twice in complementary ways so that the person who’s reading it has a chance to put the ideas into his or her brain in ways that reinforce each other.

Knuth: Pretty much a constant in my experience, over a long period of years, is that every time I’m exposed to 100 people from some population or other, except majors in computer science, 2 of them are programmers in the sense that they really resonate with the machine.

A very interesting book which I read quickly, despite its size. It contains interviews by Peter Seibel with renowned programmers covering a range of topics related to experiences throughout their careers. The fact that the author himself has worked as a programmer definitely helps to steer the conversations, without this the book would have been more of a series of monologues.

The format of each interview is very similar, with some questions appearing more or less in every interview, such as how the interviewee started out, opinions on formal proof and debugging methods of choice. Some discussions went in too deep for my liking, for instance almost everyone got asked to describe the worst bug they had to deal with, and a lot of the answers seemed interesting to me only from the historical perspective, as the bugs/techniques described were often decades old.

An interesting question that everyone got asked was whether they see themselves as a scientist, an engineer, a craftsman or an artist - these kinds of more philosophical discussions are something that I miss in this industry, as most literature focuses on the very hands-on and technical sides of programming.

There were some other interesting trends that I picked up from this book - for example that quite a few of these renowned programmers have been subsequently hired by Google, most criticised C/C++ quite heavily, most used Emacs, and unfortunately, quite a few didn't seem particularly optimistic about their craft and the future of computer science any more.

The main thing that I got out of "Coders at work" was inspiration and a historical perspective on the craft of programming.

It took me a long time to get through this book, but it was worth it! The interviews are very interesting and range from people who have been in the CS field for decades to relative newcomers. The author asks the same set of questions to each person, which I found both good and bad. It was good because I could compare how different people think about different situations, but at the same time, the author sometimes cut off interesting conversations to get to the next question on his list. This book made me want to track down longer interviews with each of the subjects to read more about their thoughts on programming. A great addition to my self of programming books!

What felt missing to me, and why this is only 4 stars, was any attempt to pull the interviews together and synthesize something from them.
Instead, we get a book where, for example, N-1 coders are asked if they read Knuth right through, or use it for reference, or have not read it; and this is followed by Knuth basically demolishing the foundations of any conclusions you might be able to make from their answers, with a offhand comment that "I sometimes wonder if I can read them."

Anyway, this book was a much happier book for me than Beautiful Code. The interview style does mean that you feel you get to know most of the participants, and there is plenty of humbling and inspirational stuff, lots of interesting history, as well as lots of places where these big names show they're only human too -- for example, coder after coder fesses up to using print statements for debugging.

Seibel got access to a great set of people, gave some quite good interviews where he managed some impressive followup questions on a wide and historically deep set of topics, and somehow got it to all hold together. Well done.

A practical book shows you many hand-on experiences

The best of the recent spat of interview books I've read. I loved the interviews with Fran Allen, Don Knuth and Guy Steele. Some of the other ones are interesting also in that the people just seem to communicate with the machines on a different level than most people. They also tend to not really think about Software Development as a profession they were just really good programmers. Well worth your time.

Very good book. A wide variety of people and experiences. The interviewer asks good questions. Inspiring in parts, although there are parts that made me feel like an vast underachiever as well.

Probably my favorite collection of interviews with programmers, followed by Programmers at Work.

Fascinating interviews with programmers, mostly old and famous hackers. Great insights about computing past, present and future. Siebel's questions are intelligent and the responses even more so.

After the reading of "Founders at Work" sharing the same interview format, "Coders at Work" is also very interesting and a very convenient way to read a book about programmers. The interview is a simple interaction but provides an easy way to access the discussion. The interesting part of the book is the common "crafting" techniques shared and used by programmers even if they have an academic background (e.g. debugging using printf statement at the right place). The discussions show a common pattern regarding software engineering or "software crafting", it's very difficult to make good software and even reaching the "good enough". That's maybe the reason why software is a nice way to make beautiful crafts.

In my opinion and like some of the other readers have already said, some boring stuff could easily be cut out (or at least made shorter) and the book would be 100 pages or so shorter.

Overall, the book is very good and insightful.

I found myself glued to this book. I never read a book in the interview format before, and found that the conversation style was very readable and felt that I was getting into the mind of the interviewee as a result. I appreciated a number of the common themes that the interviewer raised in every interview.

Review volume for Computing Reviews.