I'm wondering, how do you read programming books? I always don't do the exercises, I just read the book.. Do you read while sleeping or you really take the book and study like you do in high school and highlight words ?
|
It's up to what I expect from that book. If I read it because I want to know how to do something I never know it before, I will read and try to code all along (and also do some exercise). That give me some taste of that thing. If I read it because I want to know some concepts behind something, often when I try to learn something new, I will focus on why they do these and those. So I think it up to you. You should set your goal before read those books (in fact, you should do this before do everything). Then try to reach that goal, instead of just read it without direction. |
|||||
|
|
Disclaimer - I'm writing this from the point of view of someone who can already program, if you were learning your first programming language the answer would be very different. I avoid doing the exercises because I believe that the structure of programming books hasn't really updated to reflect the rise of the internet (oh they put their source code online and such but...) So the books are trying to give you the history, the philsophy, and the syntax and the semantics all at the same time. When I read a programming book I make sure that I've first learned to do at least "hello world" and hopefully a few of the Project Euler problems in it. Then I go though the book to get a sense of the history and philisophy of the language - because that's really the great value of the textbooks - so that you know not only that, to give a silly example, Java doens't have explicit pointer arithmatic, but also why it doesn't, and the approach that the language would like you to take. I think that the textbook is a vital tool for getting one from a basic familiarity with the lanugage to a deeper understanding. But for exercises and help and understanding at the low level - they have nothing on resources like Rosetta Code, Stack Overflow, Project Euler, and even Wikipedia. So yeah, my short answer is: read it like a novel. Admitedly a boring one. PS - to avoid controversy, if I read something in the textbook that I don't understand, or that I want to check - I certainly run and play with the code samples... |
||||
|
|
|
There is a great book that describes that problem (and many others) - it's called "Pragmatic Thinking and Learning: Refactor your wetware" by Andy Hunt, author of Pragmatic Programmer (another great book!). He writes in a general manner but his book is addressed to software developers. Basically Andy proposes a process of deliberate reading as a way of making reading more effective. In particular he describes a process called SQ3R that is an acronym for the steps you need to take:
It's all about making reading a conscious process instead of reading random books and forgetting them quickly. For example let's say you are Java developer and want to read a book about C#. You could:
I also agree with other comments that you have to read book with certain goal in mind. If your goal is to use certain language / framework / tool at hand in your next project or to get a job than technique I've described above is great. On the other hand if you just want to familiarize yourself with some concepts without going to deeply into details I believe quick reading through it and taking some general notes is good enough. When need arises at least you know what you do not know and can easily catch up with your knowledge. For example I've done so with "REST in practice" as at the moment I didn't need to create any REST services but now I'm well aware of concepts, practices and how to put pieces together if opportunity arises (and I can understand what are all this flame wars on twitter all about ;-). |
||||
|
|
|
I am always trying to extend examples from the book; imagine you just got a huge box with a construction set; will you read the manual until you are asleep or will you try to build something right away? I consider this to be the one of the best things about programming - even after 25+ years of development I am still enjoying doing it ;) |
|||
|
|
|
Learning a programming language is similar to learning any language - you can't learn well from reading a dictionary or textbook on grammar. You learn by doing it. The brain is a pattern recognition machine, not simple data storage like a computer. It's difficult to learn it without applying it somewhere. |
|||
|
|
|
I don't read programming books at all i prefer it either verbally or a video tutorial and practicing it side by side |
|||
|
|
|
You don't. But, if you are reading a programming book, you should ONLY do the exercises and read the material afterwards. You should use Google & documentation to build what you want to build in tools of your own choosing. Books won't teach you much: building real applications will. When you build real applications - you learn how to FIND information - instead of fill yourself with mostly irrelevant information that you'll probably forget (unless we're talking about fundamental programming constructs - in that case - it's ok). Programming itself is very simple: what's hard is building real-world applications in various languages and platforms. |
||||
|
|
Personally, I hate the way most programming books are written. But regardless, as much as I'd like to be able to just read them like other books, I generally don't get much out of one unless I'm using it next to the computer and poking around the software actually trying stuff. |
|||
|
|