Review: The Best Software Writing I by Joel Spolsky

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

Rating: 4 stars