Best Software Writing I 102
meryl (Meryl K. Evans) writes "Having been in process management in a software organization for over ten years, I've seen too many articles and books on the topic that worked better than Valium for putting me to sleep especially since they have no side effects. You know that Joel Spolsky is one of the best writers on the topic of software. However, in this book he stands aside and lets others demonstrate that he isn't the only one who can write about software in English and captivate you." Read on for Evans' review.
Joel on Software fans won't be disappointed in the selection of authors as they deal with the concepts Spolsky writes about on his site. Some readers may be expecting a book solely on software development. Even Joel goes beyond this. Some folks might be disappointed that most of the articles, blog entries, speeches, and essays are available somewhere on the Web. I only recognize a few of the authors and their articles, though, so I would've never known about the others had I not found this book.
| Best Software Writing I: Selected and Introduced by Joel Spolsky | |
| author | Joel Spolsky, editor |
| pages | 328 |
| publisher | Apress |
| rating | 8 |
| reviewer | Meryl K. Evans |
| ISBN | 1590595009 |
| summary | 29 essays by multiple authors covering a range of development-related topics. |
The essays cover a wide range of development-related topics. They include coding style, outsourcing programmers, dealing with Excel as a database (gag, gag), using social software (and the things that are right and wrong with these shared spaces), emerging digital rights, and defining the two-phase commit process a la Starbucks. A few of them are nothing but comics. The one on Windows search will knocks readers out of their chairs laughing, at least it did me.
The book also contains business-related essays that address a few problems affecting many companies -- namely team compensation and forced overtime which often spills over the weekend. Joel introduces every essay and includes notes clarifying abbreviations, names, or terms that you most likely know. But other people who would benefit from the book may not -- cut Joel some slack for providing these notes.
The manager benefits from the book because she gains insight into the developer's perspective, which could help her become a better leader. The developer benefits because many of the issues covered can affect him no matter what language he uses for development. If you belong to neither management nor development, the best way to decide if the book is for you or not is to review the table of contents and reviews. If you find only one or two interesting possibilities, search for them online instead.
I'm one of those who belong to neither group. My software organization background has been along the lines of an analyst and process manager. Even I find that most of the essays are enjoyable or educational. Only one or two lost me.
While most of the content is available on the Internet for free and all of you can find it, the book is worth the bucks. It's nice having a collection of high-quality writing related to software and the business in one place instead of trawling the Web for it. Furthermore, you get an opportunity to read offline -- if you manage to tear yourself away from the monitor every now and then at least; I read most of the book while traveling on an airplane. The flight flew by, thanks to the book. I appreciated and absorbed the essays better by reading them in the book than I would have had I read them online.
You can purchase Best Software Writing I from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
It would be nice to get a view from the other side (Score:5, Insightful)
Re:If it were from MS Press... (Score:2, Insightful)
It's more about the author than the publisher.
Re:It would be nice to get a view from the other s (Score:5, Insightful)
There's a lot of good writing in the world. Some of that has to do with software. So hey, why not put some of it in a book?
Therein lies the apparent purpose of The Best Software Writing I, brought to us by software bloggerexpertpundit Joel Spolsky. Beyond that broad categorical relationship, it's hard to see how everything in the book relates, either to each other, or to the reader.
I like tables, but I don't buy a book with various articles written about tables. If I want to build a table, I buy a book on building tables. If I want to look at antique tables, I'll buy a book about antique tables. I won't buy a book about tables and hope it has something I am interested in.
I don't want to say this is a bad book, because that might imply the content is bad, and hardly any of it is. Some of it to me is quite boring--which highlights my main problem with the book--but most of it is quite good.
The opening chapter by Ken Arnold on why languages should enforce strict whitespace use at the compiler level was useless. And the final chapter, by "why the lucky stiff," which attempts to teach Ruby with a few short guidelines and cartoon foxes, had me skimming the pictures before gratefully reaching the conclusion.
But in between there was some really good stuff, including Paul Graham's OSCON 2004 keynote address about what makes a great hacker, Raymond Chen's piece on why Windows retains backward compatibility for broken apps, and danah boyd's article about social software. There's an insightful piece by Clay Shirky about how to encourage good discussion and discourage bad discussion online, a perceptive article by John Gruber about how the browser's location field is the new command line, and an amusing PowerPoint presentation outline by Aaron Swartz about why you shouldn't use PowerPoint.
And you know they are good, because each piece has an introduction by Spolsky, telling you not just how good they are, but that Spolsky thought of it first. Some of the articles even refer back to Spolsky, which is nice, in case you forgot how great he is. Not that other people don't engage in similar practices: the last three pieces I mentioned above are related to me, in that Shirky favorably mentions Slashdot (where I work), and Gruber and Swartz are my acquaintances, and that's a big part of why I singled them out for mention. It just seems to me that Spolsky shines the light far too much on himself, to make the book almost as much about himself as the writing.
What's especially odd is that this book couldn't appeal to people who are not already into software, who don't already know who some of these people are, or who are familiar with the issues they are writing about. They won't get any of it. Yet the book is littered with footnotes from Spolsky explaining things like "iTunes" ("Apple's online music store") and "dev" ("Dev = developer = an actual computer programmer").
Which brings me back to the point of the book. It's not for non-software people, and it is not for software people, including those who enjoy this sort of thing so much that they already read it when it went online.
So what is the point? I don't know. Maybe it is just to make more of a name for Apress, by saying they published a book by known software bloggerexpertpundit Joel Spolsky.
Re:Could be for managers (Score:3, Insightful)