What do you find most helpful in technical books? Theory or Samples?

Question

When you are reading technical materials (books, blogs, wiki…) do you find detailed theory or direct code samples more helpful? Also do you perfer paper or electronic?

Answer 1

I may be conservative but I like the theory covered, followed by examples which illustrate and re-enforce the theory. I believe it's easier to understand well written, targeted prose with diagrams first without having to dig through code trying to understand.

And I prefer my books in the dead-tree variety with the code samples in electronic form in addition.

I cannot stomach reading books on a monitor since I like reading them in bed and having a 19" CRT fall on your face when you fall asleep is much more painful than even Knuth's hardcovers. But I do like the source in a form where I can cut and paste it.

(Yes, I do have an LCD monitor, but that joke's a lot funnier with a CRT, don't you think?)

Answer 2

Both! Samples first, though.

1. Here's how this works (sample)
2. Here's why / here's how this connects to other concepts (theory)

Also, I prefer paper for learning a new technology. I've recently picked up books on CodeIgniter and jQuery for a big project, and zipping through them for a structured overview proves invaluable when I get into the nitty-gritty of writing code and hunting through online documentation.

Once I have a little experience with something, I prefer electronic media for learning more, because I'm usually searching for something very specific.

Answer 3

My first five years I read books from start to finish, extra time on theory.
Last five years, I speed skip written text right to the examples. I am experienced enough (I hope so) to catch the meaning from the code itself. Words only clutter the real info :-)

Answer 4

That depends your work, If your work is engineer, and just completing something that need some things that you haven't meet. you should just get some good samples. That will help you much as my experience. But if you want get future study about that field, you should read some theory books and papers. These materials will help you understand why you should do like that, and you can deal with most of problems whenever you encountered by yourself, and now your are professor in that field. In a word, samples help you quickly get familiar with your work, and you should read some future books to get you professional.

Answer 5

Theory tells you why and how.

Code tells you what to do.

What to do is applicable only to that language/framework/API.

Why and how are applicable to any similar (isomorphic) thing.

Knowing what code to write to implement AOP in AspectJ is only useful if I'm using AspectJ (or Spring, which borrows much of the AspectJ Annotation syntax).

Knowing how Aspect Oriented Programming works, and why I'd use it, allows me to understand other AOP frameworks, how I might implement it myself (Chain of Responsibility, proxies), its costs (in code size, runtime, programmer effort) and benefits.

Or take the idea of predicates. Predicates show up lots of places: in SQL where clauses, in LINQ, in Apache Commons Collections Transformers, in Haskell maps, in AOP points, in Jmock Matchers etc.

The theory is the same: for each thing, apply the predicate to the thing, and keep only the things that the predicate returns true for.

Now the code in all those examples I gave above is different: some are declarative, some procedural, some functional. some use functors, some use lambda expressions, some use regexps.

But the concept is the same. And you can't get that abstract concept just by looking at one kind of code example in one language for one framework. You've got to somehow have the Platonic ideal of a Predicate, either by laboriously and over years of experience coming to recognize that all these things are Predicates, or by having some theory that says "here's how we can do it in language X's framework Y, but notice that this code is just an implementation, one implementation among many of this overarching idea".

Code examples work, and you can monkey-copy them, and that's what we all do when we meet a new language or framework or API, but they don't explain why. I can write some code in Haskell, but I can't tell you why I have to write it just the way it is in the book, because I don't yet have the theory of thinking in Haskell.

On the other hand, I've never written a line of C#, never looked at a line of it before I joined StackOverflow a month ago, but I can look at a LINQ expression and have a decent idea of what it does, because I understand what Predicates are and what SQL is.

I remember one time I was porting some algorithm, not a Huffman coder, but something similar, and the example (by Knuth, I think) used an array to represent the tree, with any element's left node the next node, and any element's the right node halfway down the (sub) array from it.

So I had to screw with that tree-as-array implementation. And I find that really opaque compared to a struct node tree. I can read the code, but laboriously. But that's OK, because up above that implementation, that code, Knuth had gone into the theory of how the algorithm works, so that how the tree is set up becomes an implementation detail, and I can "use" a "normal" struct node tree in my head.

The code was useful, but only so much, because it described what to for some statically allocated array only as long as the maximum number of nodes that would be needed, but more fundamentally because code does something, but it only informs you of the transformations being done. Code doesn't tell you why these particular transformations in this order, or why they are better than the infinite other possible recombinations and transformation the code could do. It's the theory that tells you why and how.

Same thing when I ported an AVL Tree from C to Basic (I needed to use it in an MS Outlook macro): without the theory of what an AVL Tree does, and how it does it, and why that's useful, I'd never have gotten that code ported. With just the code, I'd have been reduced to comparing my Basic code to the C code, line by line, asking, "is each line equivalent, given my somewhat different data structures". But by knowing how and why, I could confirm that my code worked just by looking at my code.

Code examples are great, don't get me wrong: a working example puts you right in the comfort zone, you can play with it, alter a bit here and there, confirm that it still works after you've substituted "LOL cats!" for "Hello world!"

But that monkey-copy is still magic until you understand just what printf is doing to your const char* const string to make "Hello world!" or "LOL cats!" appear on the screen. Until you understand the theory behind it, the code is just marks on paper or dots on your screen.

It's theory that lets you own the code, and every other isomorphic implementation of that code, own it in your head, and it's theory you can apply to any other analogous problem, because you own it.

Answer 6

I like reading technical materials with theory covered and feel it helpful because theory covered material let me know not only how but why as well. I also prefer reading papers instead of screen. You might save your vision by reading paper (with large font) and you can make notes on paper more easily.

Answer 7

For long term goals - More Theory + Less Samples

For short term goals - Less Theory + More Samples

Always prefer paper..

Answer 8

I tend to gloss over most of the samples and focus on the overview of the system. I find that books tend to give a broader view of things than do online resources. Online stuff is either a very simple introduction or the gory details. I like that in-between space where you learn more than a simple introduction but not so much that the big picture is lost. I like my books to help me understand the system so that I can then use the reference material to implement actual code.

Answer 9

I think it depends on the situation

Theory books/blog entries are better when you are trying to understand why things are designed/done in a certain way.

Samples books/blog entries are better when you are trying to understand syntax.

Paper books are easier to read. Quite hard to read electronic books since you have to scroll to see one entire page.

Electronic books are good if you are mobile though

Answer 10

If the code is good it's all you need. The rest you get from modifying it.