Tag: Books

I’m always reading something: blogs, magazines in the bathroom, books. The frequency of each ebbs and flows. Right now I’m amid a dearth of books half read:

	The Blank Slate by Steven Pinker – This book is an argument against the theory that humans are born without any innate knowledge or skills. He already convinced me in How the Mind Works, so it’s been slow going.
	Data Binding with Windows Forms 2.0 by Brian Noyes – This book is about exactly what you’d think it is. This is a fantastic technology that will save tons of lines of code. It’s part of the always excellent Addison-Wesley .NET Development Series. I’d recommend any book from the series; this one is no exception. I’m about half-way through it.
	The New Rules of Lifting by Lou Schuler and Alwyn Cosgrove – This is the first training book I’ve bought in a long time. It emphasizes just six movements that we use in daily lift as the basis of a strength conditioning program. It’s a great book for anyone who’s just starting or has been doing the same, damn thing for years and ain’t gettin’ no results. Great pictures of all the movements. I just started this one.
	Naked Conversations by Robert Scoble and Shel Israel – This book is about – surprise! – blogging. It’s for businesspeople, trying to convince them that blogging is a good thing for their business. Duh! I’m reading it to bone up for some plans I have. Muhahahaha!

 What’s curious to note is the approach and the language in each of the books. They are written to very different audiences and by authors with very different backgrounds. Pinker’s book is definitely from academia; I used to read books like that frequently, but I haven’t in a while. The text is small and dense, the words are big. And this is from a very readable author. It’s a what a journal article would be like if there weren’t so many rules that academics must follow for journal articles.

The computer book is what you would expect; the language is very plain and boring. There tables and diagrams, the font is big. It’s an extended MSDN article.

The lifting book is written in a conversational tone, the author’s joke around often. The language is light and it’s very readable. There are frequent pictures. It gives the impression that this guy is talking to a group of guys in the middle of the gym.

Scoble’s book is written for businesspeople, as I said above. I’m not half way and I’ve already noticed a pattern: blogging is great for business, here are some examples: yadda, yadda, yadda. Every chapter. Like the only way these suits are going to get it is if it’s repeated ad nauseum. Businesspeople are idiots.

Now playing: Headstones – Coffee Cup

I’ve been reading Brad’s blog for, well, as long as I’ve been reading blogs. I always found great little tidbits of .NET knowledge on his blog: performance tips, Framework conventions and idioms, as well as pointers into the .NET Design Guidelines. So when this book, Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries was announced, I was pretty excited about it; as soon as it came out, I made sure I got my hands on a copy. This book gives advice for programmers designing .NET libraries so that they resemble the .NET framework itself, allowing other programmers to pick it up more easily.

The book is very succinct, which I like. It’s arranged like a functional specification with chapters, headings, sub-headings, sub-sub-headings… Every section has a number and a title. It’s very orderly making it easy to read: everything is in digestable little chunks. With only nine chapters and topping out a lean and mean 327 pages including Annexes, the book has a very tight focus. For each section, they have a set of advice codified in quick little comments: DOs, DO NOTs, CONSIDERs, and AVOIDs. The bold highlights for those points make it easy to find when looking this up as a reference.

Like I mentioned at the beginning, I’ve been reading Brad’s blog for a couple of years (Krzysztof’s for about a year). I’ve also been using FxCop for a while on my projects, so a lot of the advice was already familiar to me, although there were a number of times that I went: “Oh yeah! I remember that.” Even still, I definitely learned something in every section. I also appreciated, even though .NET 2.0 hasn’t shipped yet, advice on generics; it means the book will last at least another version of the framework, probably more. The most helpful thing about the book were the annotations for the guidelines by Brad, Krzysztof, and other programmers both from within Microsoft and without. Those sections were great for two reasons: 1) since it reads like a technical document, the annotations put a human face on the writing; and 2) they point out where they screwed up the framework. All the little warts on the framework: misnamed classes, inappropriate interfaces, Exception types that are useless (like ApplicationException) are outlined in the text. That’s really good: it shows that these guys really care about putting out a great product and that creating a framework is f-ing hard; there’s a lot to consider. I recommend you follow all their advice. I’ve been trying to follow the guidelines for my project at work. Following the advice makes it a lot easier to version my framework and it makes it more .NET-like, so I can save time on documentation ;). I only disagree with one section on System.Uri for a special, but important, case that I happen to be stuck in. (Say, that sounds like a good idea for a blog post.)

I heartily recommend this book if you’re developing in .NET; even if you’ve got a one-project solution and you’re only using Framework classes (i.e. you’re not developing a framework), this book will benefit your efforts. If you are developing a framework targetting .NET, this should be mandatory reading.

DO buy this book.

DO read it cover to cover

DO review it periodically.

AVOID other books that claim to help you with this stuff. (More to follow on that.)

A few months ago, I was in my favourite, local, non-corporate giant bookstore looking at the computer books for anything worth looking at. Normally, general bookstores’ computer books collection is pretty anemic, but this one has always been quite good. Scanning the shelves, my eyes kept falling on this one book: The Art of Project Management by Scott Berkun. I had read the back (it sounded interesting), then put it back on the shelf. About a week later, I came back, picked it up, browsed through it, made a decision to buy it then put it back on the shelf. About a week later, it came in the mail from Amazon. These things are expensive, man!

A more accurate title is The Art of Project Management at Microsoft, but it’s no less valuable because of it. Berkun was a PM on Windows, IE4 and MSN teams at Microsoft from 1994 to 2003. Since, during this period, Micrsoft took over the world, they must be doing something right with how they manage their projects. Berkun’s book describes the whole process from planning a project, designing it, writing about the design of it, coding it, testing it, prioritizing its bugs and, finally, getting the damn thing out the door. Not only does he describe that nuts and bolts of the process, but he discusses how to manage the people involved in the project.

One of the key strengths of this book was that it acknowledged the people involved in projects. The entire thing is written in the first person, so you can relate to his experiences, some he learns the hard way. All throughout, his tips on email, meetings, acknowledging effort, decision making and leadership are refreshingly sensical. If you’re in project management role, and have no management training and no budget to get any, I recommend this book whole-heartedly. If Berkun were on my team as project manager, I’d be one happy camper. His perspective on the later stages of a project piqued my interest as well, since I have little experience with that aspect of the project, bug triage and war teams especially. Everyone should read his section on bug priority versus bug severity.

The book is about 450 pages with small type: it’s dense. It takes a while to read and some parts are dry; luckily though, it was written as a reference, so you can bounce around if you need to. However, I recommend reading the whole thing at least once. It’s definitely worth the time.

Recommended.

Pragmatic Unit Testing, by Andrew Hunt and David Thomas (The Pragmatic Programmers), is just the kind of software book I like: short, concise, laser-focussed on one topic. That topic, apparently, is unit testing with a pragmatic bent. There are two versions of the book: 1) In C# with NUnit; and 2) In Java with JUnit. I read the C# version, natch.

Ever since reading Coder To Developer and Test-Driven Development in Microsoft.NET, I’ve been a huge proponent of TDD to anyone who will listen. I’ve found my code to be easier to use, easier to debug, and hella solid, as the kids say, since starting TDD. So I didn’t think Pragmatic Unit Testing would provide anything new for me. In large part, I was right: nothing new. Whatever wasn’t covered by the above two books, I had already learned through experience. However, the book articulates the power of Unit Testing and TDD very well; better than I ever could at any rate. It reinforced what I already knew.

At around 150 pages, it’s a very quick read. The book is written in a conversational tone; written as though you had the brilliant idea to hire the Pragmatic Programmers for an afternoon to explain the power of Unit Testing and this was what they presented to you. I’d recommend this book be mandatory for all new hires at your company if you practice unit testing. Consequently, it should be mandatory reading for you if you don’t. I have a suspicion that I’ll be refering to this book every year or so to confirm I haven’t strayed to far from pragmatic unit testing.

Recommended.