Coders at Work: Reflections on the Craft of Programming (英语) 平装 – 2009年9月16日
Peter Seibel is a serious developer of long standing. In the early days of the Web, he hacked Perl for Mother Jones and Organic Online. He participated in the Java revolution as an early employee at WebLogic which, after its acquisition by BEA, became the cornerstone of the latter's rapid growth in the J2EE sphere. He has also taught Java programming at UC Berkeley Extension. He is the author of Practical Common LISP from Apress.
- Jamie Zawinski
- Brad Fitzpatrick
- Douglas Crockford
- Brendan Eich
- Joshua Bloch
- Joe Armstrong
- Simon Peyton Jones
- Peter Norvig
- Guy Steele
- Dan Ingalls
- L Peter Deutsch
- Ken Thompson
- Fran Allen
- Bernie Cosell
- Donald Knuth
Seibel (a hacker-turned-writer himself) talked to some big names in our field. Topics covered include: How do you learn to be a programmer? How do you perfect your skills? How important is formal education? Which programming languages are good and which are terrible? What kinds of tools do great programmers use? (Which text editors? IDEs? Debuggers?) How do you reason about a program, bottom-up or top-down? What's the best way to collaborate with other coders? etc. etc.
As you might expect, the interviewees agree in some areas and wildly disagree in others, but there are insights aplenty. Some answers may surprise you, like how many of these coders shun formal debuggers and use mostly print statements, or how many of them shun IDEs for Emacs (or even pen-and-paper).
Aside from the broad questions, Seibel gets the interviewees to open up about what it was like to work on the projects they are famous for. These stories are engaging and entertaining. Any coder who has stayed up till 4AM squashing bugs will find kindred spirits in these books. And the stories are somehow inspiring, as you realize that even great programmers suffer through the same frustrations and ups and downs that all of the rest of us go through.
Those interviewed also share insights into what they think of our modern world of programming. Most agree that we live in complicated and troubled times as we battle layer upon layer of software complexity. This book has lessons to be learned from the very brief history of our field, and advice for the future ("Keep it simple!").
This book is deliciously buzzword-free and the programmers interviewed give their honest (sometimes brutally honest) opinions about what they love and what they hate.
The author and all of those interviewed share a passion for programming and it's hard not to be swept up into it. Very good book.
The first questions asked of each interviewee serve to set the stage; "How did you get into programming". The detailed answers given allow the reader to relate to the interviewee as an individual. Did they fall into programming by accident as part of their existing job? Did they train to be a programmer? Did they start on a Lisp machine or an Atari 800?
From this initial introduction the author begins to dig deeper. These questions are not formulaic. The author does not rattle off the same 40 questions to each subject but has a deep understanding of the domain. Questions demand answers to problems or serve to highlight issues that the interviewee presents.
Ran into a problem? Was it a language problem? A design problem? A management or coworker problem? What issues lead up to the problem? Could anything have been done differently? Questions are asked on working conditions, languages, approaches to problem solving, influences from upper management, influences from other programmers, burn out, love for programming (do they still like it).
In the first interview in the book with Jamie Zawinski; we know his approach to software design, his approach to programming (top down/bottom up) his feelings on over-engineering, crunch-time, refactoring, how he knows when he is in over his head, his philosophy to coding in general "At the end of the day, ship the **** thing... You are not here to write code, you are here to ship products."
This is not a "Coders at work for Dummies". There is no appendix tallying up how many of the interviewee's prefer waterfall to agile, functional to imperative and there shouldn't be. Each interview requires thought and reflection from the reader.
I read until 3:30 am and then wrote this review. This is a good book.
I have to say that the first thing I noticed about the book was the cheap binding. The paper and print quality are not very good, I can't say I liked the basic typesetting or sans serif typeface very much, and I found quite a few typos despite not being a person who looks for (or generally finds) typos in published material. The small Related Titles ad on the back cover is a bit annoying as well - that sort of thing used to be tucked away in the front matter and restricted to a list of the author's other work. Ah well.
There is a short introduction describing the author's inspiration and a few themes he picked out after the interviews were completed, but not much else in the way of structure; the entire content of the book is the series of fifteen transcript style interviews, prefaced by short introductions. Many of the same questions are asked of each interviewee, which is nice for comparing their answers, but I got the impression that Seibel was pushing some people harder on certain issues: Ken Thompson on the wisdom of pointers for example, or Fran Allen on why it's really necessary to have more women in computer science, or Don Knuth on why it's important to pry open black boxes. It felt a bit like prefigured puzzlement in the face of programmers who hold on to ideas that go against what passes for conventional wisdom nowadays, and I would have preferred a more thoughtful and after the fact summary of what the author thought these less common ideas might have to contribute to the mainstream.
But analysis is not what this book is about, and that may be a good thing. As a programmer himself, the author is able to ask the questions that most programmers would probably ask without forcing the interviews to conform to a rigid agenda, and the result is six hundred pages of consistently fascinating material. What impressed me most was the sheer range of approaches and motivations on display: everything from Jamie Zawinski's largely unschooled route to a formidable level of skill and subsequent major contributions to influential projects, to to Peter Norvig's uncommon combination of practical hacker wizardry with an almost ethereally playful interest in a variety of higher level topics, to Fran Allen's old school appreciation of quality systems and frustration at the amount of regression and small-concept thinking in the current state of the art, to Dan Ingalls' desire to make his software as flexible and alive as possible. If you think you know what the programming world looks like, this book will show you that not even the giants really grasp the sheer diverse extent of it.
Interestingly, nearly everyone interviewed expressed dissatisfaction with the inflexibility, complexity, low quality, and sheer size of the modern software edifice, and those who had burnt out or who expressed interest in quitting programming were the youngest and closest to the mainstream. Sobering observation, or artifact of the interview selection process? Read and decide for yourself.
I'm a programmer who's read a lot of stuff about programming, including a lot of material by and about some the people in these interviews, and I could barely put the book down. If you're anything like me, you should get a lot out of this book.
The upside is that the interviews are often really fascinating. Siebel does a good job; he has a set of stock questions that everyone gets asked, and seeing how different people respond to them is great, but he also does a good job of getting the interviewees talking about things they think are interesting and just letting them talk. Contrasting how different people tackle problems, listening to what these folks think are the big issues in programming today and seeing common threads; there's a lot of good stuff. It's worth reading. I'm giving it three stars because I don't think it's a book that will be worth reading a second time, and because it's so sloppily put together.
About a year ago, I decided to ask a number of people what I should read, and what I should do to be a better programmer. Over the next year I spent a lot of time with these same people trying to learn how to be a better programmer. This book, Coders at Work, is one of those books which turns out to be one of the most helpful programmer-guides I've come across.
- Structure of the book:
At the start of each "chapter" (which is really an interview), there's a short description about who each individual is. From there the chapter continues with a basic "interview-style" format, where Peter asks a question, and the interviewee answers it. Usually there's a followup question to clarify the previous answer - which has both the positive and negative effects to say "Person A answered this way, person B answered this way" - so in other words, at times it's hard to say, for example, how Zanwinski's answer differed from Peyton's.
The first question asked is one very crucial for most people, though, which is more or less, "How did you get into this?"
- Topics Covered:
The topics covered is not specific to only coding - some of the topics include:
- How did one get into coding?
- What were some successful projects?
- What were some less-successful/failure projects and why?
- What type of education is useful (e.g. is a PhD useful?)
- What tools does one use and why?
- What does one enjoy about programming?
- How one works with others and the dynamic of that.
This book is *not* only about coding though! That's an important thing to recognize about this book - it's leaned a bit toward programmers in general, but these topics help to make a better programmer in general - not simply specific to just coding better.
Some of the topics discussed feels a little dated, with some technology that's being discussed well before I was born, but since many of these challenges exist as timeless and I see in my everyday life, they are still valuable to hear about.
The main thing I enjoyed about this book was the fact that it's extremely applicable to what I see each day. A perfect example was the very first chapter in talking with Zanwinski. In this chapter, he discusses the concept of "Worse is Better", and how the strive for perfection caused a company to fail. This very concept rings extremely clear to me, in I've seen a system that was developed in the "Worse is Better" philosophy, and the development of the current system has seen times where the "Right Way" caused huge delays in the development of the system. It was a breath of fresh air to hear someone else discuss a situation that was really close to one that I've been, and in some ways continue to be, in. This is the main thing that I feel I enjoyed about the book itself.
Another applicable thing I read was the reasons for getting a PhD - which I've been contemplating for well over a year now. To hear perspectives about the reasoning to get or avoid one helps a lot in the contemplation.
Along with that, the topics were very interesting - and many of the answers were very clear and to the point. One can tell that these words were exactly the way the person said it - and not edited. This is a great feature because it feels more like a dialog than just a story-telling session.
There are a few areas of the book that I feel could have been done a bit better.
- When describing more old technology (e.g. the computer that Peyton learned on), I felt I had no clue what this device looked like or anything. A quick google can help in a lot of these situations, but there's a certain disconnect from the book itself as one's reading. This can happen especially for younger developers who haven't heard of some of this technology.
- The rants on some of the languages (e.g. Perl) can be taken poorly by some. I found it kinda funny, and it's clear that it's the individual's opinion, but I can see some people being annoyed by that. There's not a lot that can be done about this besides cutting out content.
- Better identifying similar crucial questions that are asked to each individual would be helpful to hear the ideals that are different between each person. Those, with a special icon or something, would have been very helpful for comparing and contrasting differences.
Overall, I feel this book is quite good, a definite 4.5/5 stars. This book gives a "mentor feeling", when I honestly don't have a mentor at this point at my job. I found that many of the questions in this book provided insights into the difficulties I'm currently presented with, and offers suggestions on how to approach them. While this book will likely not be the totally definitive guide for all programming-related knowledge, it's definitely something I feel fits in a niche that currently isn't occupied by other books. I feel this will benefit all levels of programmers.