Do developers still buy technical books? - ResultsTue, Dec 23, 2014
Yesterday, I sent out a survey to developers asking if they still own and purchase technical books, along with a number of questions related to lending and borrowing books.
Huge THANKYOU to all who responded, and to the various tech groups that allowed me to post my request.
I’m considering resurrecting an old side-project of mine that would provide a local community book lending/exchange/selling platform - not a business, just a side-project, but I thought it important to find out if developers still used physical books, or if we had all switched to e-readers, or simply abandoned books for the quick fix from StackExchange (I hope not).
The survey was rough, biased, and not scientific, but I found the results interesting and wanted to share.
The nuances of human decisions can never really be summed up in a simple yes/no question so the open ended comments at the end are particularly interesting.
Here are the survey results from the first 100 respondents:
At the pace technical documentation gets updated, it is silly to kill trees to handle it.
I've been reading more technical books recently and have also been a technical reviewer for a couple, since when I've come to notice that there is a very broad range in quality of writing of these things. Some of them are terrible! Then you get the rare one or two that are truly great and can teach you things that genuinely revolutionise your coding life.
Based on the email that brought me here: - the local tech bookstore (powell's) is untenable for multiple reasons: tech books are tested like school textbooks: overpriced and quickly outdated/un buybackable. - oreilly is a great source and all available in ebook - yes, have gone ebook and digital amd online I would gladly share my set of ebooks up to the limit off their share ability legally.
I rely heavily on my institutional/alumni libraries to access technical books. I find most books to be prohibitively expensive, and they soon become out of date.
I prefer paper books in general, but ebooks (pdf for most devices) for the searching capabilities, as well as the cut and paste. So, biased for paper, but buy electronic.
although I prefer real books I end up reading lots as ebooks either via Safari books online or PDF. I love real books but they are expensive and hard to get.
Build it, but don't expect to make a profit.
I would also be interested in just plain giving away tech books I no longer have use for.
I regularly pass on the technical books I've read, either to specific people, or to meetups or company reading rooms. I enjoy reading books, but there's no reason to hold onto text which I've already read & digested.
There used to be a PDX Technical Library a while back. I think [REDACTED] was responsible.
I prefer reading fiction in electronic formats. For technical books, electronic formats still suck most of the time. They're also inconvenient in that they compete for screen space with whatever technical thing you're doing.
I've been known to give away books (esp. POODR).
A lot of the answers to previous questions is really more of a maybe, but I put yes/no based on which way I leaned more.
I prefer PDF books for everything except the most fundamental subject (i.e. Gang of Four, Algorithms, data structures) -- for those I prefer paper
I live in a paperless world now. It's on Kindle or it doesn't exist.
Powells tech books are super out-of-date. I usually don't even bother looking there. Also, you can run into issues w blank slate Ruby program vs Rails--frequently ideas and concepts are only partially viable for both areas. I have many books by many publishers and there tends to be quite a bit of filler vs self-published books. Lastly, many/most technical authors struggle at illuminating nuanced topics or highlighting trade offs; so the result is often incomplete for those senior devs and unhelpful for junior devs. I like books period. I own many books, not just technical ones. As an autodidact, I found the technical ones more helpful earlier in my career--I doubt I will be more than a book or two a year going forward and those probably will be self-published "working w unix processes" Jesse Storimer type self-published ebooks.
I find that the specific topic makes a huge difference as to how interesting I will find a technical book. Books about specific technologies (frameworks, libraries, to some extent languages) are not very interesting to me at all. I'd rather read the API documentation and dink around on my own, and anyway they tend to be obsolete after a year or three. Books about more fundamental CS topics (algorithms, data structures, design patterns, to some extent languages) are *extremely* interesting and useful to me, and have a much longer shelf life. So to speak.
I use both hard-copy and e-books.
Most of my books are digital now. When I want to loan someone a book I usually buy a digital copy for them.
This survey should include an age range question ... curious what that demographic stat would look like in relation to these answers - [REDACTED]
The "loaner" questions are complicated; I would loan out second tier books to strangers, but might not lend out first tier books to even close friends.
I now buy mostly PDF ebooks, only if I can get 'em without DRM, & keep them on iPad and all my dev machines. I would never loan a PDF, though.
Technical books code & diagrams is lost a lot of times on e-readers so I don't prefer those. I also buy PDF versions but find that I tend not to read them since they sit right there as a commodity on my filesystem with numerous other files to read in the future.
Hey Jake, going to make a technical book exchange? Let me know, [REDACTED]
The problem I have is finding the time to read the books. There are a few I've bought with great intentions but never got round to reading :(
My reason for not buying technical books is: "Why buy a book when I can just read a tutorial online?"
I like ebooks. Problems are mostly formatting sometimes. I don't know why I prefer paper, maybe formatting. Ironic that software causes software book problems.