I had not heard of the expression Game Jam, not being closely associated with the amateur game programming scene, at least in California. The closest thing we have to it is the Hackathon, where the task is to code up some problem not necessarily confined to a game scenario. In the Hackathon the prize could be seed funding for a company. Having said this, the similarities with what Kaitila describes are manifold. So treat the book as also germane to a Hackathon preparation, especially if you and a team are revving up for one and no one has participated before.
The book is a grab bag of hints contributed by game programmers who have been thru the experience. Several times for several of them, I suspect. There is not a line of code in the text. It is not about any specific language, but about general useful tips for getting your team through a deliberately gruelling weekend. Read the book if you will as a sociological commentary on a coding subculture. Oh, and speaking about programming languages, you are cautioned not to use the occasion to start writing in a newly learnt one. Pragmatically you don't have to ride that learning curve while competing against other teams well versed in their choices.
One contributor (Chevy Ray Johnston) suggests that the best aspect of a Jam is the intense time pressure to come up with a crazy shortcut that works. But he also opines that you should always pay attention to the visual polish of your solution. It is not just about the back end algorithmic ingenuity. The technical brilliance of the latter still needs the GUI shine to garner those crucial votes by the judges.
In a broader perspective, there are echoes of a weekend chess tournament. The steady time pressure. The short allegro games (1 hour at most) compared to a leisurely pace of 5 hour games during a full tournament. Of course, the greatest difference is the always solitary nature of chess. You play alone, never in a team. Indeed one distinguishing feature of a Jam is the need and ability to form a team. The sociological makeup of that team, and your hopeful ability to persevere in it can be a priceless professional networking experience. Not just with the team members, but with others at the Jam. Try to keep in continual touch with as many of them as you can afterwards. In looking for work, seriously consider asking them to act as references. And ask if they know of openings. This is the one problem I have with the last chapter, which is about the post mortem. It has good advice, but does not talk much about maintaining the networking. Rather, it focuses on lower level aspects like posting your game on the Web. All to the good; don't get me wrong. But those personal ties you can garner may be the most professionally useful.
While although this book specializes on giving advice from different experienced game jam developers, anyone looking for advice on creating games, how to manage everything that needs to be done, and how to prioritize and maximize their time on their project would find this extremely helpful.
It covers pitfalls that any game developer will run into, such as having to cut mechanics due to time, focusing on doing a few things very well vs. lots of things not as well, counting in time for things you might not have planned on, such as adding sound, packaging your game to distribute before the deadline, and planning on things usually going wrong.
Aside from avoiding pitfalls, he also introduced you to resources to improve the speed at which you can create games, such as free sound sites, resources for finding game frameworks/engines, and the best ways to prepare for a game jam (which contrary to what it sound like, does not mean starting from scratch after the game topic has been announced).
I would recommend it for anyone interested in participating in a game jam, building their own game, or interested in what goes into creating a game, and the types of things you'll have to plan on, and ways of avoiding pitfalls which may keep your game from being completed.