What do you think?
Rate this book
The Best Software Writing I: Selected and Introduced by Joel Spolsky
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. Meryl K. Evans, meryl. ...an entertaining read with a number of enlightening insights into what I do for a living... The whole book is fantastic though, and you should absolutely pick it up...in dead tree form. This is a book worth checking out, even if you're not a software developer. With a nod to both the serious and funny sides of technical writing, The Best Software Writing Selected and Introduced by Joel Spolsky is an entertaining read and a guide to the technical writing literati. The Best Software Writing contains writings
346 pages, Paperback
First published January 1, 2005
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 53 reviews
January 2, 2018
A nice collection of blog posts and essays on software. Even though most of these are available online for free, there is so much crappy writing out there, that it's nice to come across a curated, pre-vetted collection from a trusted source. I also wholeheartedly agree with Spolsky's desire to see more quality writing about software, and applaud him for encouraging this sort of work by publishing a book like this. I'm a fan of anything that tries to make the software industry more accessible and interesting.
As with any curated collection, some of the essays were better than others. In particular, "The Pitfalls of Outsourcing Programmers" (Michael Bean), "ICSOC04 Talk" (Adam Bosworth), "Great Hackers" (Paul Graham), and "A Group is its Own Worst Enemy" (Clay Shirky) stand out above all the others (Shirky's work in particular is a must-read). A few of the other essays feel a bit dated, which is understandable, given the book came out in 2005, and the software industry moves quickly. And a few are just silly, short jokes or comics, which serve as nice breaks between the more serious writing.
Overall, a nice quick read.
As always, I saved some of my favorite quotes from the book:
"I've read entire books about outsourcing, and fundamentally nobody seems to understand that software development is design, not manufacturing. Every single line of code that gets written involves making a decision about the design of the software. And for software companies, and any other company that derives competitive advantage from proprietary software, outsourcing design is, eventually, fatal." -- Michael Bean
"The thing about the too-complicated specs is that nobody wants to look stupid, so they never call the designers on designing something too complicated." -- Adam Bosworth
"It is an ironic truth that those who seek to create systems that most assume the perfectibility of humans end up building the systems that are the most soul destroying and most rigid—systems that rot from within, until like great, creaking, rotten oak trees, they collapse on top of themselves, leaving a sour smell and decay. We saw it happen in 1991 with the astonishing fall of the USSR. Conversely, those systems that best take into account the complex, frail, brilliance of human nature and build in flexibility, checks and balances, and tolerance tend to survive beyond all hopes.
So it goes with software. That software which is flexible, simple, sloppy, tolerant, and altogether forgiving of human foibles and weaknesses turns out to be actually the most steel-cored, able to survive and grow, while that software which is demanding, abstract, rich but systematized turns out to collapse in on itself in a slow and grim implosion." -- Adam Bosworth
"An unacknowledged war goes on every day in the world of programming. It is a war between the humans and the computer scientists. It is a war between those who want simple, sloppy, flexible, human ways to write code and those who want clean, crisp, clear, correct ways to write code. It is the war between PHP and C++/Java." -- Adam Bosworth
"Along with interesting problems, what good hackers like is other good hackers. Great hackers tend to clump together—sometimes spectacularly so, as at Xerox Parc. So you won't attract good hackers in linear proportion to how good an environment you create for them. The tendency to clump means it's more like the square of the environment. So it's winner take all. At any given time, there are only about ten or twenty places where hackers most want to work, and if you aren't one of them, you won't just have fewer great hackers, you'll have zero." -- Paul Graham
"Because you can't tell a great hacker except by working with him, hackers themselves can't tell how good they are. This is true to a degree in most fields. I've found that people who are great at something are not so much convinced of their own greatness as mystified at why everyone else seems so incompetent." -- Paul Graham
"So if you ask a great hacker how good he is, he's almost certain to reply, I don't know. He's not just being modest. He really doesn't know. And none of us know, except about people we've actually worked with. Which puts us in a weird situation: we don't know who our heroes should be. The hackers who become famous tend to become famous by random accidents of PR." -- Paul Graham
"If there is a Michael Jordan of hacking, no one knows, including him." -- Paul Graham
"Software for groups is different. Prior to the Internet, the last technology that had any real effect on the way people sat down and talked together was the table." -- Clay Shirky
"Nothing causes a group to galvanize like an external enemy. So even if someone isn't really your enemy, identifying them as an enemy can cause a pleasant sense of group cohesion. And groups often gravitate toward members who are the most paranoid and make them leaders, because those are the people who are best at identifying external enemies." -- Clay Shirky
"Groups often have some small set of core tenets, beliefs, or interests that are beyond criticism, because they are the things that hold the group together. Even in groups founded for fairly intellectual discussion, the emotional piece comes out whenever you threaten one of these core beliefs, because when you take on those beliefs, you are not just offering an opinion, you are threatening group cohesion." -- Clay Shirky
"People who work on social software are closer in spirit to economists and political scientists than they are to people making compilers. They both look like programming, but when you're dealing with groups of people as one of your runtime phenomena, you have an incredibly different practice." -- Clay Shirky
"Reputation is also not generalizable or portable. There are people who will cheat on their spouse but not at cards, and vice versa, and both, and neither. Reputation in one situation is not necessarily directly portable to another." -- Clay Shirky
"Ease of use is the wrong goal for social software. Ease of use is the wrong way to look at the situation, because you've got the Necker cube flipped in the wrong direction, toward the individual, when in fact, the user of a piece of social software is the group." -- Clay Shirky
"You have to find some way to protect your own users from scale. This doesn't mean the scale of the whole system can't grow. But you can't try to make the system large by taking individual conversations and blowing them up like a balloon; human interaction, many-to-many interaction, doesn't blow up like a balloon. It either dissipates, or turns into broadcast, or collapses." -- Clay Shirky
As with any curated collection, some of the essays were better than others. In particular, "The Pitfalls of Outsourcing Programmers" (Michael Bean), "ICSOC04 Talk" (Adam Bosworth), "Great Hackers" (Paul Graham), and "A Group is its Own Worst Enemy" (Clay Shirky) stand out above all the others (Shirky's work in particular is a must-read). A few of the other essays feel a bit dated, which is understandable, given the book came out in 2005, and the software industry moves quickly. And a few are just silly, short jokes or comics, which serve as nice breaks between the more serious writing.
Overall, a nice quick read.
As always, I saved some of my favorite quotes from the book:
"I've read entire books about outsourcing, and fundamentally nobody seems to understand that software development is design, not manufacturing. Every single line of code that gets written involves making a decision about the design of the software. And for software companies, and any other company that derives competitive advantage from proprietary software, outsourcing design is, eventually, fatal." -- Michael Bean
"The thing about the too-complicated specs is that nobody wants to look stupid, so they never call the designers on designing something too complicated." -- Adam Bosworth
"It is an ironic truth that those who seek to create systems that most assume the perfectibility of humans end up building the systems that are the most soul destroying and most rigid—systems that rot from within, until like great, creaking, rotten oak trees, they collapse on top of themselves, leaving a sour smell and decay. We saw it happen in 1991 with the astonishing fall of the USSR. Conversely, those systems that best take into account the complex, frail, brilliance of human nature and build in flexibility, checks and balances, and tolerance tend to survive beyond all hopes.
So it goes with software. That software which is flexible, simple, sloppy, tolerant, and altogether forgiving of human foibles and weaknesses turns out to be actually the most steel-cored, able to survive and grow, while that software which is demanding, abstract, rich but systematized turns out to collapse in on itself in a slow and grim implosion." -- Adam Bosworth
"An unacknowledged war goes on every day in the world of programming. It is a war between the humans and the computer scientists. It is a war between those who want simple, sloppy, flexible, human ways to write code and those who want clean, crisp, clear, correct ways to write code. It is the war between PHP and C++/Java." -- Adam Bosworth
"Along with interesting problems, what good hackers like is other good hackers. Great hackers tend to clump together—sometimes spectacularly so, as at Xerox Parc. So you won't attract good hackers in linear proportion to how good an environment you create for them. The tendency to clump means it's more like the square of the environment. So it's winner take all. At any given time, there are only about ten or twenty places where hackers most want to work, and if you aren't one of them, you won't just have fewer great hackers, you'll have zero." -- Paul Graham
"Because you can't tell a great hacker except by working with him, hackers themselves can't tell how good they are. This is true to a degree in most fields. I've found that people who are great at something are not so much convinced of their own greatness as mystified at why everyone else seems so incompetent." -- Paul Graham
"So if you ask a great hacker how good he is, he's almost certain to reply, I don't know. He's not just being modest. He really doesn't know. And none of us know, except about people we've actually worked with. Which puts us in a weird situation: we don't know who our heroes should be. The hackers who become famous tend to become famous by random accidents of PR." -- Paul Graham
"If there is a Michael Jordan of hacking, no one knows, including him." -- Paul Graham
"Software for groups is different. Prior to the Internet, the last technology that had any real effect on the way people sat down and talked together was the table." -- Clay Shirky
"Nothing causes a group to galvanize like an external enemy. So even if someone isn't really your enemy, identifying them as an enemy can cause a pleasant sense of group cohesion. And groups often gravitate toward members who are the most paranoid and make them leaders, because those are the people who are best at identifying external enemies." -- Clay Shirky
"Groups often have some small set of core tenets, beliefs, or interests that are beyond criticism, because they are the things that hold the group together. Even in groups founded for fairly intellectual discussion, the emotional piece comes out whenever you threaten one of these core beliefs, because when you take on those beliefs, you are not just offering an opinion, you are threatening group cohesion." -- Clay Shirky
"People who work on social software are closer in spirit to economists and political scientists than they are to people making compilers. They both look like programming, but when you're dealing with groups of people as one of your runtime phenomena, you have an incredibly different practice." -- Clay Shirky
"Reputation is also not generalizable or portable. There are people who will cheat on their spouse but not at cards, and vice versa, and both, and neither. Reputation in one situation is not necessarily directly portable to another." -- Clay Shirky
"Ease of use is the wrong goal for social software. Ease of use is the wrong way to look at the situation, because you've got the Necker cube flipped in the wrong direction, toward the individual, when in fact, the user of a piece of social software is the group." -- Clay Shirky
"You have to find some way to protect your own users from scale. This doesn't mean the scale of the whole system can't grow. But you can't try to make the system large by taking individual conversations and blowing them up like a balloon; human interaction, many-to-many interaction, doesn't blow up like a balloon. It either dissipates, or turns into broadcast, or collapses." -- Clay Shirky
April 9, 2010
Never has a book made the term 'dead tree' seem as true as this one. With minimal work, almost all of the content in this is freely available online, and I would highly recommend reading the introductions on paper, but viewing the pieces themselves in their original hyperlinked state. Cut off from their comments, with references reduced to footnotes rather than links, the writing shrinks. It feels much more alive in the context it was written.
That said, it is a fair collection of diverse and important technological writing. It feels like a good introduction to the online developer community. Someone who has been keeping up with software blogs for any time will already be familiar with some of the material - but that's how a best of collection should be.
at five years, the collection is already showing it's age. It was collected in a pre-iPhone, pre-facebook age. In some ways, this is a little funny, since you know the answers to many of the big questions being discussed. In other ways, it is a valuable snapshot of 2005 - giving perspective on just how fast things are changing in this world.
That said, it is a fair collection of diverse and important technological writing. It feels like a good introduction to the online developer community. Someone who has been keeping up with software blogs for any time will already be familiar with some of the material - but that's how a best of collection should be.
at five years, the collection is already showing it's age. It was collected in a pre-iPhone, pre-facebook age. In some ways, this is a little funny, since you know the answers to many of the big questions being discussed. In other ways, it is a valuable snapshot of 2005 - giving perspective on just how fast things are changing in this world.
August 31, 2021
A Wonderful Book with stories from various people.
I had a blast, while reading Eric Sink's Chapters.
I laughed so loud reading that passage.
I'd recommend this for people in Tech, easy read, fun.
Deus Vult,
Gottfried
I had a blast, while reading Eric Sink's Chapters.
I laughed so loud reading that passage.
I'd recommend this for people in Tech, easy read, fun.
Deus Vult,
Gottfried
April 1, 2022
Even setting aside the now-obsolete technologies described in a 2005 book: I wanted to read examples of effective writing about software topics. Instead, I read a collection of “my first draft is the best draft” blog posts aimed at a self-congratulatory, condescending echo chamber—which, by the way, doesn’t track at all with the attitudes of software developers and engineers I’ve known. I made myself finish because my employer purchased the book at my request. The best essays are by Clay Shirky and Mary Poppendieck.
June 3, 2018
It's always interesting to peek into the past, even if we're talking about a very recent one. This book is a collection of essays by several authors picked by Joel Spolsky to serve as the "best software articles of the year", it was published in 2005. Let that sink in, this is pre-social media. Stack overflow *did not* exist yet. It's a world where people still referred to blogs as weblogs. Quite honestly, it was difficult to hold a laugh.
For the most part, most of the articles didn't age well, but there are some pearls, for example the Rands in repose one and the article by Aaron Swartz, (yes, the internet hacktivist).
For the most part, most of the articles didn't age well, but there are some pearls, for example the Rands in repose one and the article by Aaron Swartz, (yes, the internet hacktivist).
January 5, 2020
This is a collection of 29 essays about software development, selected and introduced by Joel Spolsky (of Joel on Software fame).
I've been a regular reader of Joel's site for many years, and many of the themes Joel has been writing about (social software, outsourcing, the dangers of measuring the performance of individuals using simple bug metrics, and sales and marketing of software) are reflected in the included essays.
Many of the authors have already published books of their own (Bruce Eckel, Paul Graham, Mary Poppendieck and Ron Jeffries come to mind), but regardless of whether they've been published before or not, the writing is consistently good. This isn't surprising, since according to the back cover, the goal of the book is to show-case good writing, and since Joel himself is a very good writer.
I had read a few of the essays before the book was published (and in the case of "Great Hackers" by Paul Graham, I had actually listen to it, thanks to ITConversations), but most of them were new to me. They cover a lot of different angles on software development, from how to format your code, to forced overtime.
The best essays in my opinion are "The Pitfalls of Outsourcing Programmers" (a short but well argued piece on why outsourcing many times isn't such a good idea), "Strong Typing vs. Strong Testing" (on the benefits of automatic unit tests) and "Style is Substance" (why not standardizing on one coding style - why not indeed).
Actually, as I look through the contents to pick which essays I liked the most, it is hard to choose. Many of them are really good. I have to pick a few more: "Measuring Testers by Test Metrics Doesn't" (with a great example of exactly how this can create a lot of extra work without adding any value), and the cleverly named "How Many Microsoft Employees Does It Take to Change a Lightbulb?" (explaining how a seemingly small change ripples through a big company).
Also, honorable mentions to Clay Shirky's two entries about social software (I had read both before, but they are very insightful and worth re-reading) and to Eric Sink's about software sales and marketing.
The least interesting for me were "Processing Processing" (musings on the nature of the web) and "Passion" (about passion for programming, which is a good subject, but this essay just didn't work for me).
There are also a couple of entries in the "Humor" category. The second essay is a hilarious send-up of the crappy Windows search, and the last essay made me laugh aloud several times. It's a quick tour of Ruby (the programming language), but with lots of stream-of-consciousness side tracks. And cartoon foxes! Not to be missed.
Joel's introductions are generally good and add to the experience. There is also a liberal sprinkling of footnotes, where Joel explains certain names and terms. Mostly this is OK, but it goes over-board sometimes. Given that this presumably is a book the will mostly be read by software developers, do we really need explanations of API-call, iTunes or Skype?
I suspect this collection will be followed by a "The Best Software Writing II", and I'm looking forward to reading that one too. By the way, since all the essays were culled from the web, you can probably find all of them just by surfing. But for me, it was worth it to have them all collected in book-form.
To summarize, a varied collection of interesting and well written essays on software development. Recommended.
I've been a regular reader of Joel's site for many years, and many of the themes Joel has been writing about (social software, outsourcing, the dangers of measuring the performance of individuals using simple bug metrics, and sales and marketing of software) are reflected in the included essays.
Many of the authors have already published books of their own (Bruce Eckel, Paul Graham, Mary Poppendieck and Ron Jeffries come to mind), but regardless of whether they've been published before or not, the writing is consistently good. This isn't surprising, since according to the back cover, the goal of the book is to show-case good writing, and since Joel himself is a very good writer.
I had read a few of the essays before the book was published (and in the case of "Great Hackers" by Paul Graham, I had actually listen to it, thanks to ITConversations), but most of them were new to me. They cover a lot of different angles on software development, from how to format your code, to forced overtime.
The best essays in my opinion are "The Pitfalls of Outsourcing Programmers" (a short but well argued piece on why outsourcing many times isn't such a good idea), "Strong Typing vs. Strong Testing" (on the benefits of automatic unit tests) and "Style is Substance" (why not standardizing on one coding style - why not indeed).
Actually, as I look through the contents to pick which essays I liked the most, it is hard to choose. Many of them are really good. I have to pick a few more: "Measuring Testers by Test Metrics Doesn't" (with a great example of exactly how this can create a lot of extra work without adding any value), and the cleverly named "How Many Microsoft Employees Does It Take to Change a Lightbulb?" (explaining how a seemingly small change ripples through a big company).
Also, honorable mentions to Clay Shirky's two entries about social software (I had read both before, but they are very insightful and worth re-reading) and to Eric Sink's about software sales and marketing.
The least interesting for me were "Processing Processing" (musings on the nature of the web) and "Passion" (about passion for programming, which is a good subject, but this essay just didn't work for me).
There are also a couple of entries in the "Humor" category. The second essay is a hilarious send-up of the crappy Windows search, and the last essay made me laugh aloud several times. It's a quick tour of Ruby (the programming language), but with lots of stream-of-consciousness side tracks. And cartoon foxes! Not to be missed.
Joel's introductions are generally good and add to the experience. There is also a liberal sprinkling of footnotes, where Joel explains certain names and terms. Mostly this is OK, but it goes over-board sometimes. Given that this presumably is a book the will mostly be read by software developers, do we really need explanations of API-call, iTunes or Skype?
I suspect this collection will be followed by a "The Best Software Writing II", and I'm looking forward to reading that one too. By the way, since all the essays were culled from the web, you can probably find all of them just by surfing. But for me, it was worth it to have them all collected in book-form.
To summarize, a varied collection of interesting and well written essays on software development. Recommended.
July 17, 2018
Odd beast: a time capsule where half the items are of purely historical interest, and half are general and extremely wise arguments that are still not acted upon today. He had planned them to be annual collections, but they didn't happen, so this looks to represent more than one year's best.
Recent enough to tell us something about the internet, though with lots of anachronism. But it's more at the lexical level - "weblog", "Sociable media" - than the semantic.
Found (eminent media researcher) danah boyd ludicrous: she calls developers autistic, and calls people with several online identities multiple-personality disordered (a person is one person. So all their activities have to be one person!) Disappointing, typical social theory. She aggressively pushes a horrendous risky single-sign-in for all sites based on these shitty polemics and nothing else.
Contains helpful principles which will not age:, e.g. "if you can't understand the spec for a new technology, don't worry: nobody else will understand it either, and the technology won't be that important".
[Various]
Recent enough to tell us something about the internet, though with lots of anachronism. But it's more at the lexical level - "weblog", "Sociable media" - than the semantic.
Found (eminent media researcher) danah boyd ludicrous: she calls developers autistic, and calls people with several online identities multiple-personality disordered (a person is one person. So all their activities have to be one person!) Disappointing, typical social theory. She aggressively pushes a horrendous risky single-sign-in for all sites based on these shitty polemics and nothing else.
Contains helpful principles which will not age:, e.g. "if you can't understand the spec for a new technology, don't worry: nobody else will understand it either, and the technology won't be that important".
[Various]
March 22, 2017
I liked this. Published in 2005, some of the essays in this collection are starting to show their twelve-years-plus age, especially with regard to specific technologies and products. And it's an interesting glimpse of a software industry before the eras of smartphones and their apps, Twitter and Facebook, and the resurgence of JavaScript. But overall there's a lot that's still worthwhile to be found here.
To the criticism I've seen in other reviews that this book is somehow worthless because it's "only a collection of blog posts" which can be read on their original sites, I completely disagree. For one, Spolsky has some of his own commentary, introduction, and explanatory footnotes here. Maybe they're not essential, but they're nice. Also, especially as the years go on, not all of these sites are going to still be around. But mainly a collection is nice because it's a collection: specific choices, brought together in a specific order, and held together to make a whole that's greater than the sum of its parts.
Read this for the Austin Computer Book Club, for the March, 2017 meetup. Consensus seemed to similar to mine here: this was a good one, and worth a read.
To the criticism I've seen in other reviews that this book is somehow worthless because it's "only a collection of blog posts" which can be read on their original sites, I completely disagree. For one, Spolsky has some of his own commentary, introduction, and explanatory footnotes here. Maybe they're not essential, but they're nice. Also, especially as the years go on, not all of these sites are going to still be around. But mainly a collection is nice because it's a collection: specific choices, brought together in a specific order, and held together to make a whole that's greater than the sum of its parts.
Read this for the Austin Computer Book Club, for the March, 2017 meetup. Consensus seemed to similar to mine here: this was a good one, and worth a read.
May 23, 2018
There's a lot of good stuff in this one with a healthy variety. I think there are a few references that are outdated, but on the whole, most of it is timeless wisdom and tips for software. I also love the breadth covered as it will probably stretch most developers in one way or another.
Definitely worth a look if you're a software developer.
Definitely worth a look if you're a software developer.
July 20, 2022
Having read this book about 20 years after most of the articles had been written, I think it's a mixed bag. There are a couple chapters that I thought were really good (and still relevant today) , but the rest were either outdated or I just wasn't interested in reading at all. Luckily it's not a book you have to read sequentially, so you can skip the chapters you don't like.
September 7, 2017
2006년에 나온 책이라 요새 기술에는 좀 뒤떨어졌지만 뭐 괜찮다. 나중에 다시 읽어봐야지.
January 27, 2020
Essays from Spolsky's blog going back to the early days of the web. Interesting but some of it is a little dated
Want to read
December 3, 2020recommended by Albert L.
December 17, 2022
I’m sure it was at least 4 stars in its time, but 2004 was a long time ago
November 22, 2016
A good collection of essays on mordern programming culture and practice.
March 17, 2010
A nice selection of essays about software development. Not every story is great, but there aren't too many stinkers either. And the ones that are good are really good. Here are some of my highlights:
Style is Substance - Makes the argument that style (i.e. where you put your curly braces, how you indent, etc) should be built into the compiler (like python does) The argument is basically this: No formatting style adds any significant productivity at all. Unfortunately supporting whatever style a developer wants to use has decreased productivity over the history of programming significantly. Time is wasted arguing over the styles. Time is wasted as file diffs are messed up due to differing whitespace, etc. If the language designers picked a style and enforced it with the compiler all of these problems would go away, and people could just worry about their business problems. A great read. My synopsis won't do it justice.
EA the human story - A good description of a corporate sanctioned permanent death march. EA sounds evil. I'm glad I don't work there.
Strong Typing vs Strong Testing - Makes the argument that the compiler doesn't help you nearly as much as unit tests...
Great Hackers - Describes things that makes one a great hacker.
Team Compensation - Well written description of how bonuses and merit raises can hurt morale. Very interesting stuff.
Hazards of Hiring - discusses some of the common wisdom about hiring, but moves past the surface level to get into the different ways you can try to hire really good people, such as the difference between developers and programmers, and making sure that you hire people who would improve your team in some significant way.
Style is Substance - Makes the argument that style (i.e. where you put your curly braces, how you indent, etc) should be built into the compiler (like python does) The argument is basically this: No formatting style adds any significant productivity at all. Unfortunately supporting whatever style a developer wants to use has decreased productivity over the history of programming significantly. Time is wasted arguing over the styles. Time is wasted as file diffs are messed up due to differing whitespace, etc. If the language designers picked a style and enforced it with the compiler all of these problems would go away, and people could just worry about their business problems. A great read. My synopsis won't do it justice.
EA the human story - A good description of a corporate sanctioned permanent death march. EA sounds evil. I'm glad I don't work there.
Strong Typing vs Strong Testing - Makes the argument that the compiler doesn't help you nearly as much as unit tests...
Great Hackers - Describes things that makes one a great hacker.
Team Compensation - Well written description of how bonuses and merit raises can hurt morale. Very interesting stuff.
Hazards of Hiring - discusses some of the common wisdom about hiring, but moves past the surface level to get into the different ways you can try to hire really good people, such as the difference between developers and programmers, and making sure that you hire people who would improve your team in some significant way.
June 10, 2008
Reading well-written material on technology is still something exciting to me. We're at a cusp where the world is becoming more permeated with technology, my generation is growing up with tools that are as old as we are and thus our understanding and acceptance of technology is growing. Yet the stereotypical nerd is still out there, hammering out code while being incredibly inept at writing documentation. So finding collections of material like this, where people have a deep understanding of technology and software code yet also the eloquence to put their thoughts and opinions to paper, is a wonderful thing to me. But perhaps I'm only catching up to where the internet has been for some time. A lot of the writing in this book is taken from websites and blogs where good technology writers pour out well-written essays and clearly-defined opinions. As such, sometimes this book feels like it could have been better. Of course, I did read it a couple of months ago now and thus don't remember the content very clearly, but that should say something about the lasting power of this book. Still, nothing beats some clear technological rhetoric.
December 19, 2007
I liked Joel on Software, which is mostly a compilation of articles Joel Spolsky wrote for his blog. I thought the paper copy offered something beyond what I would get from just browsing through Spolsky's archives on the net. Sadly, I do not really have the same feeling about Best Software Writing. Most of these articles first appeared online somewhere, and while many of them are reasonably entertaining -- and the editorial footnotes are sometimes hilarious -- I'm no longer so sure that I would prefer to have the collection compiled as a book rather than as an annotated list of hyperlinks.
September 9, 2008
Kind of hard to get through this one, probably because it's a compilation of different authors' works and that articles are included not just because they're interesting but also because they are examples of good writing. Some of the articles are interesting and some not so much but that is probably due to my personal bias. I still haven't decided how many of the articles are not read-once. For me the book of collected JoelOnSoftware articles would be more relevant.
I haven't actually read all of the articles, but marking it read as I haven't picked it up in 6 months or so (which is telling in itself...)
I haven't actually read all of the articles, but marking it read as I haven't picked it up in 6 months or so (which is telling in itself...)
March 18, 2011
There's some good stuff in here but it's all stuff you can find online, and there's a lot of filler as well. I like the idea of this book but feel like they weren't able to keep the bar high enough for writing quality. e.g. "ea spouse" -- clearly a significant blog post and one that had a huge impact on the industry-- but is it great writing? Not really.
My favorite essay from the book was Strong Typing vs Strong Testing by Bruce Eckels. Really good discussion of the merits/drawbacks of dynamically typed languages (e.g. Python) relative to statically typed languages (e.g. Java/C++.)
My favorite essay from the book was Strong Typing vs Strong Testing by Bruce Eckels. Really good discussion of the merits/drawbacks of dynamically typed languages (e.g. Python) relative to statically typed languages (e.g. Java/C++.)
May 9, 2011
Not as good as the last collection of essays by Joel Spolsky, probably mostly because they were on topics that I was either not interested in or maybe just the overall divergence of topics. The collection brightened up considerably with the last essay, which was Why The Lucky Stiff's first chapter of his book on the Ruby programming language, which was a lot of fun to read. Sample moment from that chapter "I was there, eight years old, lying in my bed, when suddenly it struck me: there's nothing preventing me from becoming a child dentist." I'll be reading the rest of that software book, and maybe accidentally learning Ruby in the meantime.
January 21, 2016
Some of this can be attacked for its vintage, but it you read past the tech for technique, which I think is the point here, the lessons are timeless. Edward R. Tufte's skewering of PowerPoint as a tool and Paul Graham's "Great Hackers" are pieces worth the price of admission alone. And, don't discount the Ruby veneration or Rick Shaut's article on the birth of Mac Word due to the antiqueness therein because what they have to say about elegance and project management is still important, today.
January 27, 2010
A large part of the book describes Ruby language. Ruby is a great language, really. But this book is not an Ruby education guide and I prefer to see here some comparison or thoughts or something like this instead of that introduction to Ruby. It looks like the author didn't have enough articles to add to book or it was too attracted by Ruby.
But this book also shows some different problems of IT from side of non-developers - managers, CEO, customers. And that part, IMO, is very interesting.
But this book also shows some different problems of IT from side of non-developers - managers, CEO, customers. And that part, IMO, is very interesting.
April 9, 2008
Very nice. Spolsky’s introductions were typically Spolskyesque, and I really enjoyed almost every article. The individual authors are gifted writers, and the subject matter was interesting throughout (to me – I’m a software developer, but there were more articles than I expected that would mean something to the non-developer, and even to someone totally unconnected to the production of software).
September 23, 2009
Rating: 4.5/5 (unable to select 1/2 rating)
This is a really great collection. It can be read even if you are not in the IT industry as it is not a technical book, but rather a book with really great writings that help to illuminate the ideas.
I would recommend this book to everyone I know who wants to read a great non-fiction book. I'm serious.
This is a really great collection. It can be read even if you are not in the IT industry as it is not a technical book, but rather a book with really great writings that help to illuminate the ideas.
I would recommend this book to everyone I know who wants to read a great non-fiction book. I'm serious.
March 2, 2010
I really enjoyed this book a lot. Most of the articles were incredibly well written and entertaining as well as insightful.
This has definitely inspired me to read more technical blogs. If there are guys out there that can write like this and teach great things in this way then I want to read more of it.
This has definitely inspired me to read more technical blogs. If there are guys out there that can write like this and teach great things in this way then I want to read more of it.
January 21, 2011
Basically a random collection of blog posts and essays. I found maybe a few gems, but the majority were tedious and I really had to push myself to finish this book. Technology changes fast and very little in this book is 'timeless' material. Most of it felt quite dated...this was probably a much better read five years ago.
November 7, 2012
This was an entertaining and informative read. Most of the concepts discussed are timeless and therefore useful, but some of the stuff discussed seemed kind of dated, even though only from 2004-2005. For someone already in the software business, this is entertaining and helpful, and I would recommend it.
April 21, 2008
For Software Development Nerds only. It's not a classic in the tradition of The Mythical Man Month, Peopleware, or Code Complete, but most of the essays are reasonably interesting and well-written. But probably only if you're passionate about building software.
December 16, 2008
I've actually read a bunch of these essays on the intarwebs, but they're extremely well written and worth re-reading. I'd actually rate it 4.5/5. Well worth reading for any programmer, but I wouldn't say it's a must-read.
Displaying 1 - 30 of 53 reviews