What’s the point? Learn how to do usability testing yourself to gain most of the benefits of hiring someone to do it, and losing most of the negatives (e.g. Big Honkin’ Report, $$$). The book’s other motive is to make sure you start doing some kind of usability testing. ALL of our sites/applications have usability problems. We could eliminate the big ones just by spending a little time on it.
How was it? A pretty quick read. I’m a slow reader, and I made it through it in a couple hours a night for 3 nights. This thing is a prescriptive manual for conducting usability tests on a product you have (or on your competitors products, if you’d like to do that). It covers recruiting participants all the way to fixing the problems they discover. Usability testing doesn’t need to be a big production, hard to do, or scary. He lays it out step by step and give you (as the guy running the tests) guidance each step along the way, complete with checklists and scripts (I know, that sounds hokey, but I think it’ll actually work).
Who should read it? If you’re reading this, you probably ought to read the book. Realistically, anyone remotely interested in having a usable application and is actually partly responsible for said application (PM, Tech Lead, Dev, Designer, Marketing, Tech Writing, Tester, etc.). Even if you aren’t going to be the one running/moderating the tests, it’s good to know what the participant’s are going through, what the moderator is doing behind the scenes, and what your role is as an observer.
Book Club Foreword
A couple years ago I brought up the idea of doing a book club here at SEP because I had participated in a couple before coming to SEP, but we called them SEDG (coined by Steve McConnell in Professional Software Development). I don’t really like that term, so we called it book club instead.
We start up a new round a couple times a year, and small groups (3-8) break off and read different books (normally technical) that are interesting to them. We normally get together for an hour once a week to discuss/debate the chapter(s) we read for that week. I’ve participated in several including DDD (Evans), Code Complete 2 (McConnell), Programming Clojure (Halloway), and now Pro Git (Chacon). It’s a lot of fun, and I always learn a lot about the content of the book, and about the people I participate with.
I’d highly recommend starting one at your company, or in your community, it’s a great way to connect with people and learn new things at the same time.
First off, the book is available for free, online at progit.org. It’s also hosted in a repository on github, and there is an easy script to get it onto your kindle (with a little hacking of the script), so that was a win for me: free AND kindle-ized.
I’ll follow Raman’s Recipe to keep this short and simple. I’ll also mix-in the book club aspect to each section.
What’s the point? Become a git ninja (or at least be able to play one
on TV at work). Learn how to use git effectively, and give you the tools (ideas, knowledge, know-how) to give you a framework on how to effectively use it in your context. The cool thing about git, is that it gets out of your way and lets you work the way you and your team want to… not the other way around like SVN, TFS, P4, etc. It was also a great way to leech off of Matt and Todd’s knowledge.
How was it? Great. Scott (author) certainly knows how to git down (I’ll be here all week ). I feel comfortable participating on a project that uses git (hey look, I am already!), and also feel comfortable making recommendations about using git (e.g. “You should use git!”), though, I do still get lost in hairy situations every once in awhile (thanks Matt for always saving me!). We had some good discussions on how it relates to us as company, and how we might use it. We also had some good discussions on schoolin’ me, so that was always good. The book contains lots of examples, with corresponding diagrams to help n00bs like myself understand what’s going on.
Who should read it? Any developer planning on staying a developer for the next few years. DVCS seems to be on an up-tick, and I don’t really see it going away anytime soon (but hey, what do I know?). I don’t think you’ll be able to get by effectively in a DVCS world unless you’ve done at least some reading on the subject.
Instead, I ended up with a collection of stories from some people (some of which I've heard of, most of which I haven't) that have been on teams and are willing to share their stories.
Now, I know all teams and projects and organizations are different, so maybe my expectation of 'Here is how you build a team. Step 1:...' was a little naive, but I certainly wasn't expecting what I got. There were some interesting stories throughout the book (i.e. a team of folks whose conference room ended up with one of the hijacked planes from 9/11 in it, literally, it crashed into their conference room), but I had few takeaways of solid advice on how or what I could do to help nurture a great team or start to build/rebuild a failing team.
All in all, I'd say there were some entertaining stories, but if you're looking for some concrete takeaway's, look elsewhere. And on that note, if you're looking for entertaining stories, you may be better off reading some Stephen King or something like that as well. Sorry O'Reilly (and Stellman and Greene, also authors of Head First C#, which I do have and enjoyed thoroughly), this just wasn't for me. Probably my own fault for having false expectations.