I read a book!

That's right... I read a book. Planes will do strange things to a man. I finally got around to reading Joel on Software on the flight back, which was actually quite good. (Two, if you include Penny Arcade Volume II: Epic Legends of the Magic Sword Kings.) The full title as listed on the cover is:

"Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity."

To save my fingers, I'll continue to refer to it as "the book" or "Joel on Software," and I will continue my trend of not italicizing book titles because I think it's silly and inconsistent.

Really, the title tells you a lot about the book, which you might expect, since it is a paragraph unto itself. It's an example of the writing style contained therein. Joel Spolsky is a rather well-respected tech writer, and this is essentially a collection of the best stuff he's written over the past six years or so. I'd read scattered bits that he had written, but certainly not a whole book's worth of them. If you're not going on a long flight anytime soon, and don't mind reading long passages on a computer screen, there's no strong reason to buy the book, as it's all online. But, it's great stuff.

Joel has a lot of good ideas—some ideas that every good software developer probably already has, and some that are a bit more controversial. I'd like to share a couple interesting passages. The first is The Joel Test. Joel lists twelve things that every software team should have and do. (It's right at the beginning of that page I linked to. I'll wait.) It's a great checklist to anyone who's looking for a place to work in the computer industry—if your prospective employer scores in the single digits, and it doesn't look like you'd have the authority to make the kinds of changes required to increase the score, you probably should look elsewhere.

Probably my favorite part of the book is one that I had read before, from Painless Functional Specifications, Part Four: Tips. Rule number one when writing a spec is to be funny: "Oh, and, by the way, if you think that it's unprofessional to be funny, then I'm sorry, but you just don't have a sense of humor. (Don't deny it. People without senses of humors always deny it. You can't fool me.) And if you work in a company where people will respect you less because your specs are breezy, funny, and enjoyable to read, then go find another company to work for, because life is just too damn short to spend your daylight hours in such a stern and miserable place."

Another great article is Fire and Motion. Not every day will be productive. Some days you just can't get "in the zone." Learn to live with those days. Make a little progress each and every day, and things will work out in the end.

Those who need to regularly present their project to non-developers, people who don't really understand how software is built, should read The Iceberg Secret, Revealed. Make unfinished parts of your software look unfinished. That way, they won't assume you're 90% done when you've really just made a nice mockup. And, make high-quality parts of your software look high-quality. It's good advice.

I'd recommend Joel on Software to anyone who's interested in developing software. It's a good read, even if done in a dark plane when you can't feel your legs and your back is in excruciating pain.