Credo of the bookworm

I'm a hopeless case of a typical bookworm - I don't read books, I just devour them. Fiction, non-fiction, tech: everything. In general people in the industry acknowledge the fact that we're supposed to keep learning or we're out of business (and books can help a lot here), but I keep hearing such statements every now & then:

"Knowledge in books gets outdated before they reach the massprint. Internet is XXI century books' replacement."

"As reading tech books is digging through theory, what you can achieve at most is absorb this theory - wouldn't it make sense to read half as much & spend the saved time on applying theory in practice even more?"

"I've skimmed through your reviews -> you seem to read several books on the same topic (agile, lean, testing, Hadoop, R, Scala) sometimes. What's the point - don't you get through pretty much the same content?"

These questions DO make some sense. As long as you treat reading books as just assimilating "dry" knowledge. Fortunately, reading tech / agile books servers some other purposes & brings several other, significant benefits that shouldn't be ignored:

  • Validating own experience, thoughts & conclusions - don't underestimate this, really; when you're a practicioner, you work some solutions out - usually gradually, step by step, layer over layer - consequences of your "atomic" decisions stack up to build the paradigm of architecture you shape. In the meantime you draw some conclusions, state some opinions -> about what works & what doesn't, what's a PRO & what's a CON. Unfortunately, you may be so focused on your own sandbox that you may completely omit other paths, that could lead to better (or just - alterative) outcomes. Healthcheck by reading a book or two - just to check how other people solve similar problems - may be very refreshing & useful.

  • Looking for different perspective - sometimes you feel that you need another perpective, because you're stuck or close to; in this case you're not looking for confirmation, but for something completely else, something that will prove you wrong & will bring some new trails up.

  • Searching for applicable cases - that category partially belongs to the two above - theory is the theory, but you're looking for actual warstories: how did it work in real-life? are those great-sounding theories really applicable? what were the results / benefits? how were they measured? I love "cases" - handbook / manual style is usually just to dry for me (unless I'm reading about something that's totally new for me).

  • Inspiration & invigoration - yes, you've read it right: good tech literature can do that pretty much as well as conference speeches do. I'm not refering to typical motivational literature ("... for american housewives" ;P) - skillfully sketching technology capabilities, presenting its potential & synergy when mixed with other pieces of technology, proving the concept with a small, but illustrating demo -> all of these may make the cogs in your heads spinning.

  • Feeling responsible for recommendations for others - solutions that make a true business difference rarely can be built by one person - this is a team game after all. That's why if I see a new (& promising) book on a topic I find particularily interesting, I put it on my reading queue -> just to find out whether it's better than ones I've previously read. No-one pays me for that, I buy all the books with my own money (no reimbursements by my employer / clients), but that's the role I've accepted: other team members, people from the same company or anyone else can just come to me & ask for the recommendation - I'm more than glad to provide it.

  • There are authors whose every word deserves to be read - that works in the same way for tech / agile books as it does for fiction: there are authors you can't really afford to skip:

    • Scott Meyers, Herb Sutter - for C++
    • David Anderson - for Kanban
    • Poppendiecks - for Lean
    • Martin Fowler - for ... well everything (this pretty much applies to his signature series as well, even if he's not an author)
    • Gojko Adzic - for "everything testing"
    • Jez Humble - for continuous delivery
  • There are also some other authors, who have published just one book, but it was that good (or I value their blogs / articles / conference sessions that high), that I'm buying whatever they write next anyway:

    • Mark Seemann
    • Eric Evans
    • Simon Brown
    • Arnon Rotem-Gal-Oz
    • Greg Hohpe
    • Ari Lerner

The cover image was taken in Municipal Library of Prague -