Cykod Blog

Not on the little things - like failing in your current project, or having your home town team lose the world series. But in the big things that you have no control over - like whether your entire career and everything you've fought for over the past 10 years will be able to continue unhindered or whether you'll be ground underfoot by an IP troll or a member of the competition via some legal machinations.

I hate software patents. I hate them with a passion normally reserved for big screen villains. I hate them because they have absolutely nothing to do with what we do, but could nonetheless completely derail years of work and make it impossible to continue doing what we do.

Software patents keep me up at night.

The primary crime they commit is that they add no value whatsoever - I've never read a software patent and directly gained any value from a single one - yet they sit around like ticking time bombs waiting explode - but only against  most vulnerable small business, large business have a lock-box of their own patents cross-license each other into submission.

They subvert the primary reason for the existence of patents in the first place - to promote innovation through disclosure of an invention. As they are written in a legal speak that is a completely separate language designed only to be read by judges and lawyers, how could any engineer possibly gain value from them? As they are written to be as broad as humanly possible how could anyone gain any insight into building anything concrete?

But it gets worse, because at least he had an implementation. Many times patents either start or end up in the hands of companies that have no intention of ever implementing any of the ideas obtusely described in their IP portfolios.

The closest analogy I can think of is that filling a software patent without implementing it yourself is like betting on a horse race, except the horse doesn't know it's involved in the race. It's just moving forward at full speed trying to get the finish. As the winner arrives exhausted to the finish line, the IP Troll looks down at their stack of patents and says, "Hey look at that! I bet on the winner." They didn't actually do any of the work, they weren't riding a horse in the race, they just had a few generic ideas and bought themselves a couple of patents counting on one to come in. But the IP Troll doesn't walk over to the ticket window to cash their winnings. They walk up to the winner and extract their winnings from the horse itself (in whatever gruesome manner you want to imagine)

Anyway, enough of the hyperbole. Just wanted to put down some of the thoughts going through my head as the Supreme Court heard Oral Arguments in the Bilski case yesterday. Early returns look promising - like maybe the scope of what can be patented might be reduced, but who knows? It's now in the hands of 9 black-robed individuals to decide their fate.

I've seen a number of forum threads and had a couple of discussions with younger developers that seem to indicate an opinion along the lines of:

"Why would I ever buy a computer book, all that same information is on the internet for free?"

I think there is somewhat of a generational gap of programmers coming out of school these days regarding printed technical literature. Now, given the number of books that are still being written and published, I don't think it's at all a universal opinion that computer books are worthless, but I do think that there's a tendency among the Millennials to completely discount or at least undervalue printed technical literature.

Now, given that I was a member of a Computer Book Club ( think Columbia House music club but for computer books  - shoot I hope that's not a completely dated reference as well ) starting at age 13, I obviously have a strong built-up bias. Even today, I continue to find myself buying books at the same rate or even more often than I did previously. So I decided to take a step back to evaluate whether this was still a good idea or whether I was just burning through cash for a wall full of useless, processed dead trees.

What I did was pull up a list of all my book purchases over the past two years, and then give each book a Yay or Nay as to whether, in retrospect, it was worth the $25-$45 dollar investment, evaluating whether I read the book and whether the time spent reading the book was time better spent than gleaning a few more focused pieces of information off of the Web.

Here's what I came up with: 15 Yay's, 2 Nay's.

In the case of the two Nay's - one was for a project that fell through (and so I never made it past the third chapter of the book), and the second one was not the book that I needed - I needed a tutorial instead of an exhaustive reference - and I should have known better.

Total expenditure (estimated, too lazy to lookup the real math): $510.

In retrospect, given the number of technologies that I needed to get up to speed on quickly, that total seems minuscule. Depending on what your time at work costs you or your employeer, it can be a huge big net gain given how much time you can spend looking for and reading incomplete or misguided information on the web. Now I've seen the gripes all over the web and the reviews on amazon where people have been intensely disappointed with their book purchases, and clicking through on some of the reviewers, it seems like they are disappointed with pretty much every book they've ever purchased. As I think my batting average on book satisfaction ( 88% ) is pretty high, I'd like to share the guidelines on technical book buying that I've amassed over the last decade and a half (I know no one asked, but I want people to keep buying 'em so people keep writing 'em):

1. Buying based on brand is ok (and often a good idea).
As stupid as this sounds, one of the reasons that books are better than some of the crap on the web is that the amount of effort and expense that goes into a book is orders of magnitude more the amount that goes into a blog post or online tutorial. What this means is that the companies that have been in the business of producing good technical books know what they are doing. The authors change from book to book, but the overall quality of the books stay pretty consistent. The publishing houses know this and that's why all their books are branded so consistently. O'Reilly knows that for a large chunk of developers out there - Animal on the cover = good book. I've in fact yet to purchase  an O'Reilly book at any point that I didn't find worthwhile. Here's my personal list of graded publisher preferences:

O'Reilly (A) - Nuff said.
Pragmatic Programmers (A) - but be careful with the Beta books, by the time they actually publish you may have moved on (I'm still waiting on the RSpec book from Feb 2009)
Apress (A-) - Solid but be careful as there is some occasional inconsistency in quality
Developer's Library (B+) - I've had a couple of dud's but some real winners too
Charlies river media (B+)
Addison Wesley (B)
Wiley (C+) - Usually, Eh.., but I avoid their "Bible" books like the plague
Prentice Hall (DNF) - Wildly varying quality, can't really say anything based on publisher

2. Realize that there are different types of books out there.
If you aren't buying yourself the right one your are going to be disappointed. At minimum, I'd categorize books into 4 different types:

 Tutorial - these take you through, step by step, learning something
 from beginning to end

 Survey - these give you a higher level overview of a technology, but usually don't go too much in depth

 Reference - these aim to be exhaustive coverage of a technology

 Recipe - these are usually a collection of essays, insights and/or code  snippets. Doesn't have to have to word "Recipies" in the title, but I'd consider some books like "Building Scalable Web Sites" to be recipe books

If you are learning or evaluating a new technology, go with a Survey or a Tutorial style book depending on your need. If you want to gain some extra insight or experience in a technology that you already now go with a Recipe book that can show you the mindset associated with a certain technology. Reference books are falling out of favor as a lot of material is more up to date on the web, but sometimes they actually make a good read when you are trying to push your level of knowledge to the next level, although usually not a good place to start learning something.

While sometimes books while tell your what they are ( e.g. Python - Essential Reference, or Rails Recipies ), sometimes it's a little tougher to figure out. Read the reviews and first couple pages of the introduction or author's note and you should be able get an idea.

3.Understand, furthermore that there are different levels of books and getting a book for that appropriate level is important. Sometimes the negative reviews give you more insight into a books intended audience than the positive ones - e.g. "As an experienced programmer I found this book to be overly simplistic" or "I couldn't make heads or tails of what the author was saying, what the hell is tail-recursion?"

I'd categorize books into 5 basic levels:
 Noobie - written for someone with neither knowledge in the subject matter nor any support knowledge in similar technology fields.
 Beginnner - written for someone with no knowledge in the subject matter but an average amount of knowledge in the field
 Experienced Beginner - written for someone with no knowledge in the subject matter, but a large amount of experience in the field (look for subjects like "Ruby for C Programmers")
 Intermediate (self explanatory)
 Advanced (ditto)

Again, make sure you're buying the book that you intend to buy otherwise you will be disappointed. Usually the author will make pretty explicit the intended audience for a book in the first couple of lines of the introduction, but don't necessarily take them at their word, read the reviews and a couple of pages of the book to get a sense for whether the level of the book matches your need.

4. Make sure the writing style matches your needs. Sometimes it's important to get the best book on a subject, while sometimes you really are only partially interested in a book and need an author with a sense of humor (even a bad one keeps things interesting) to get through the book. This matter less for references than for the other types of books, and furthermore, for me at least, matters less for the more advanced books than it does for the introductory ones.

5. Lastly, make sure you actually need and/or want to read a book on the subject matter. Sometimes you really don't want to read 400 pages on something. If all you want is 1 specific tip, the Internet is  probably a better option. If all you want is a 5 minute overview, see if Wikipedia has some info or some decent external links.
Or run a google search for (i.e. for Ruby - ruby +"is awesome"  , +ruby +sucks , and +ruby +tutorial ) To get yourself a quick overview of some different opinions on a technology before you make the commitment to killing a tree (or for kindle users - killing everyone else' bandwidth)

And just to finish things off, here's my desert island top 10 books that are in my shelf, and yes I would want these with me were I stranded on a desert island laptop or no laptop - considering quality, re-readability and entertainment value:

	1. Programming Ruby 1.8 (Aka the PickAxe book - clear writing style, great mini tutorial combined with a nice reference, 1.9 -which is linked - will hopefully replace this as soon as I get around to it)
	2. Unix Power tools (ridiculously great recipe book, should have something for everyone, get your l/unix skills to make that leap)
	3. Head First Design Patterns (I got bored reading the classic "Gang of Four" Design Pattern book - this one is great and has a great, light writing style)
	4. Dive into Python (the perfect tutorial style book, gets you excited about the language also available to read online )
	5. Designing interfaces (a wonderful, full color survey of different interface techniques and concepts, should be required reading for anyone putting an interface in front of a user if just to create a vocabulary for interface techniques)
	6. The Pragmatic Programmer - (the book that launched a publishing company, I'd consider it required reading for the current generation)
	7. Joel on Software (A great collection of essays by one of the most justifiably popular and entertaining bloggers, solidly from a Windows-environment centric viewpoint, just as a warning)
	8. The C++ Programming Language (By C++ creator, Stroustrup. A perfect combination of reference and insight to get the most out of the language - this is a dated reference though as my copy is from '97, and apparently C++ sucks )
	9. High Performance MySql (little book that packs a big punch - turned mysql database performance from a voodoo black box to a defined, controllable resource - do you know what every column of 'EXPLAIN' is telling you?)
	10. Pragmatic Thinking and Learning: Refactor your Wetware - (a great book for the lifehacker types that gets you thinking about your mental processes as a programmer)

Happy Reading.