- Paperback: 632 pages
- Publisher: Apress; 1st ed. edition (September 16, 2009)
- Language: English
- ISBN-10: 1430219483
- ISBN-13: 978-1430219484
- Product Dimensions: 7 x 1.4 x 10 inches
- Shipping Weight: 2.3 pounds (View shipping rates and policies)
- Average Customer Review: 4.3 out of 5 stars See all reviews (82 customer reviews)
- Amazon Best Sellers Rank: #65,192 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Coders at Work: Reflections on the Craft of Programming 1st ed. Edition
Use the Amazon App to scan ISBNs and compare prices.
See the Best Books of 2017 So Far
Looking for something great to read? Browse our editors' picks for the best books of the year so far in fiction, nonfiction, mysteries, children's books, and much more.
Frequently bought together
Customers who bought this item also bought
About the Author
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.
If you are a seller for this product, would you like to suggest updates through seller support?
Top customer reviews
Though weighty, there are numerous great sound bites throughout. Jamie Zawinski, "one of the prime movers behind [...], the organization that took the Netscape browser open source", is quoted as saying "I hope I don't sound like I'm saying, 'Testing is for chumps.' It's not. It's a matter of priorities. Are you trying to write good software or are you trying to be done by next week? You can't do both. One of the jokes we made at Netscape a lot was, 'We're absolutely 100 percent committed to quality. We're going to ship the highest-quality product we can on March 31st." Seibel poses the following question to Douglas Crockford, inventor of JSON: "In one of your talks you quoted Exodus 23:10 and 11: 'And six years thou shalt sow thy land, and shalt gather in the fruits thereof: But the seventh year thou shalt let it rest and lie still' and suggested that every seventh sprint should be spent cleaning up code. What is the right time frame for that?" To which Crockford replies: "Six cycles - whatever the cycle is between when you ship something. If you're on a monthly delivery cycle then I think every half year you should skip a cycle and just spend time cleaning the code up."
Joshua Bloch, Chief Java Architect at Google at the time this book was written, comments that "there's this problem, which is, programming is so much of an intellectual meritocracy and often these people are the smartest people in the organization; therefore they figure they should be allowed to make all the decisions. But merely the fact that they're the smartest people in the organization doesn't mean they should be making all the decisions, because intelligence is not a scalar quantity; it's a vector quantity. And if you lack empathy or emotional intelligence, then you shouldn't be designing APIs or GUIs or languages. What we're doing is an aesthetic pursuit. It involves craftsmanship as well as mathematics and it involves people skills and prose skills - all of these things that we don't necessarily think of as engineering but without which I don't think you'll ever be a really good engineer."
Summarized as the "mother" of Smalltalk (the counterpart to Alan Kay, the "father" of Smalltalk), Dan Ingalls comments that "people should learn to think clearly and to question. And to me it's very basic. If you grow up in a family where when the cupboard door doesn't close right, somebody opens it up and looks at the hinge and sees that a screw is loose and therefore it's hanging this way vs. if they say, 'Oh, the door doesn't work right; call somebody' - there's a difference there. To me you don't need any involvement with computers to have that experience of what you see isn't right, what do you do? Inquire. Look. And then if you see the problem, how do you fix it? To me it's so basic and human and comes so much from parent to child. Computers are certainly a medium for doing that. But they're just computers. There's a lot of that that will transfer, but to me it's really big and basic and human, so it's not like we're going to enlighten the world just by teaching them computers."
Sometimes we take the leaders of an industry and blow their importance and worth out of proportion: "Only THEY could have done it." That doesn't make their accomplishment any lesser and I like that this book shows the humanity that hides behind code and products they've built.
It's tough to predict if this book will appeal to you. If you're a seasoned software industry professional with a deep love for the 'craft' of coding then you'll love this collection if interviews. I certainly did and it reminded me of why I got into this industry in the first place and it rekindled a love for coding.
At least one reviewer has complained that this title didn't "detail" how these programmers worked and how they approached programming. I must thoroughly disagree. The opinions of these people on common points of disagreement from type systems to tools and coding styles to debugging methods was explored. If you are hoping that you will be able to watch the subjects solve a complex problem or go through a typical day's work than you are in the wrong place. This isn't a screencast or a tutorial. On the other hand, there are a wide variety of opinions on display from experts in different areas of the field across different generations on numerous contentious issues.
This book is filled with words worth chewing on. On the first read, the interviews of Crockford, Deutsch, Eich, and Peyton-Jones stuck out to me in particular. In subsequent readings I expect that set to be different. All of the interviewees did agree on the importance of one thing, reading and writing code. For a beginner, this book is likely to point out some pitfalls that otherwise would've been missed and suggests valuable sources of intuition and insight. Perhaps most importantly, it may help popularize some knowledge of the history of our field. As Knuth laments, "The idea that people knew a thing or two in the '70s is strange to a lot of young programmers." There is some valuable distilled experience and wisdom here. At the very least, the book should help you hash over your own opinions on the issues discussed.