Just finished reading [http://www.bookpool.com/sm/1590593898 Joel On Software] and my first reaction to it was “everyone should read this book”. For those who are unaware, Joel Spolsky is a software developer/program manager who worked for micro$oft and juno among other places, and runs a [http://www.joelonsoftware.com/ blog] where he pontificates about various topics on a semi-regular basis. Now I have read his blog, although I don’t read it regularly, and found he often has high grade content in his entries, and thats the best part of the book. Basically the book takes you through a sort of “best of” his blog, which really provides a lot of good information. Some of it won’t be new to you, but even then it’s a nice refresher for things you may have gotten away from. More importantly, folks who read the book are likely to learn things that will make the software they work on better (and if you happen to work on [http://www.postgresql.org/ PostgreSQL] all the better). A good example is his chapter on “The Joel Test”, which is a list of key items that will determine how good your development environment is. Now this is something I had read before, but reading it again certain things jump out at you, like the item “do you make daily builds?”. In the PostgreSQL project, we’ve probably had someone somewhere building the cvs everyday for many years now, but this really wasn’t as good as the [http://www.pgbuildfarm.org/cgi-bin/show_status.pl buildfarm system] that [http://people.planetpostgresql.org/andrew/ Andrew Dunstan] put together which really helped push the project forward. Now not all of his suggestions are appropriate for an open source project of postgresql’s nature, but it get’s you thinking about things that could be done to help improve the project. Even if you not a developer, there are still many things in this for you. Everyone who has ever been involved in a “how do we get users to switch from my$ql thread” should really read his strategy sections, like Ben & Jerry’s vs. Amazon (slow growth postgresql vs. land grab my$ql), the chicken and egg problem (you can’t get people to write software for postgresql because the install base is smaller than others, but you can’t grow the install base without having an abundance of software that works with postgresql; one answer might be to [http://archives.postgresql.org/pgsql-hackers/2005-07/msg01068.php focus on porting popular packages]), and the Let Me Go Back chapter, which reminds us that one of PostgreSQL’s strengths is that its easy to port your way out of it compared to many other rdbms due to it’s standards compatability. Again a lot of this stuff is not news, and you can also probably find it all on his blog site, but having it all in one place where you can really soak it in is great. Go read this book.