Take the 2-minute tour ×
Personal Productivity Stack Exchange is a question and answer site for people wanting to improve their personal productivity. It's 100% free, no registration required.

I honestly love programming but I find it tiresome to read programming books. Well, I find it tiresome to read most books actually, with the exception of short stories. Do you guys have any advice you could share?

share|improve this question
1  
I feel you... I kind of liked books from the "Head first" series, they are written in a quite entertaining way. But I have yet to make it through an entire book... –  olli Oct 26 '14 at 2:59
3  
Read programming tutorials (short stories) instead, and learn programming by programming, not by reading. Or, watch the movie version (ie, coursera.com or khanacademy.org or something) –  barrycarter Oct 26 '14 at 6:42
    
We all learn differently, I really can't read programming books as well, I've done it and they just don't click with me. Videos are better for me, but don't really get as in depth as I feel I would like. For me the best learning has come from a combination of getting my hands dirty and smaller reads that dig into very specific issues. (basically instead of a huge book on a large topic, I like to drill down to specific programming concerns) –  RualStorge Nov 21 '14 at 20:14
    
You don´t need to read programming books completly. Just look up the things you need to get the job done ! –  user13061 Jan 14 at 10:41
1  
@Harry, that may work for specific issues, but what if you want to understand 'the big picture'? –  l19 Jan 17 at 22:22

7 Answers 7

From experience, opening a new programming book is always exciting. I start reading (even the dedication, acknowledgements etc.), but gradually loose the vibe and get tired. Here are a few concepts that help me carry on:

  1. Divide and Conquer - in programming (and GTD), D&C is dividing a complex task into simpler ones that can be more easily tackled. Plan out the timeframe for reading your book, divide it into smaller blocks (weeks work best for me) and assign portions of the book to each week. Depending on how long the book is, you might do 1-2 chapters per week. You can go a level deeper and divide those weeks further into days.

  2. Keep to your schedule - be disciplined. Once you fall back, you won't ever catch up, let alone finish.

  3. Take notes - They don't have to be very detailed, but something that will help you remember key points, guidelines, acronyms etc. Freeplane mindmapping software works best for me.

  4. Do the exercises and test out the code from the book as you go along. Don't fall prey to illusions of competence, and Hindsight bias, thinking the problem is too easy that you don't have to do it. Type it out.

    This is especially important for more advanced code - I've come to realize that it's crucial to understand A before you plunge into B, else you start loosing focus when you don't fully understand the previous topic (it can be done, but it takes more mental effort, and more time).

  5. From previous point comes - don't skip, unless the book is specifically meant to be used that way (isolated solutions etc.)

  6. Go the extra mile - read articles on the topic; implement the ideas you read about into a personal project; ask questions on stack overflow; join discussion forums etc.

  7. Get excited about the particular topic (if not already), or about the author him/herself - read his blog, his open source projects etc. The more you know about him, the more you'll want to finish his book.

  8. Don't multitask - don't try to read 2 or more books at the same time. Never worked for me (unless they're complimentary, and even then).

    Make the other books inaccessible (or at least hard to access) - put other books aside (lock them away), remove other books from your tablet/ kindle, or store the other books on external HDD (or usb/ cloud storage) → keep only the copy you're reading.

In many cases the previous steps might be overkill. Most important are 1, 2, and 8


Appendix:

An example of notes I took for JavaScript URL manipulation. Mindmaps are best for quick & dirty jotting down of information, and fitting the small pieces into the big picture. When you're done, you can process it, correct inconsistencies, do more research based on your notes, etc. It depends on the type of notes - if it's more reference-like, I keep it in a mindmap. If it's a topic that needs more elaborate explanation, I convert it into some other format (an article, for example).

(nodes with red arrow represent outside resource).

Freeplane notes

share|improve this answer
    
I suffer from point 8. How do you resist the urge? –  Little Child Oct 26 '14 at 17:16
    
Make the other books inaccessible (or at least hard to access) - put other books aside (lock them away), remove other books from your tablet/ kindle, or store the other books on external HDD (or usb/ cloud storage) → keep only the copy you're reading. –  Dwelle Oct 26 '14 at 17:30
    
Regarding point 8, how exactly do your notes look like? I can't imagine writing programming notes on a graph like that! –  l19 Jan 15 at 1:40
1  
updated the answer –  Dwelle Jan 15 at 12:37

There are only a couple of programming books I've read cover to cover: Code Complete and The Pragmatic Programmer.

Any other programming book I've read has been with the purpose to extract enough information to get a job done.

It's a question of utility.

Reading a short story is usually a different matter. You're drawn into the world the author created. (The exception is reading a story for English class, which I found had the opposite effect. I was reading the story for the purpose of analysis, which is orthogonal to the goal of reading it for pleasure.)

If you're having issues reading through a programming book, that might raise a flag: Do you need to read the whole book now? Or do you need to read some, program some until you get stuck, read some more, program some more until you get stuck again, etc.?

Reading something just for the sake of fulfiling some agreement you made with yourself, and not for any immediate practical value, doesn't seem like time well spent.

share|improve this answer

I'll try to contribute by throwing some ideas around. I think reading (or better said, learning) is a way of life, which one I do not fully master all of the time, but at least seem to be quite comfortable with some of the time. I hope it helps you.

First, ask yourself why you are reading programming books in the first place. If you want to become a better programmer but you have problems reading programming books, maybe you can consider alternatives like online courses which are more interactive. I'm not sure if you will become a better programmer if you read books which you don't want to read.

Second, reading can be a powerful habit, so you should not forget the theory of habit creation. Think about the habit cycle described by Charles Duhigg in The Power of Habit (see some illustrations from it at http://www.simoleonsense.com/visual-guides-to-habit-formation/). If you manage to make reading a habit, you will be in the company of many powerful people. Ask Warren Buffet (http://theweek.com/article/index/248655/the-warren-buffett-formula-how-you-can-get-smarter) ;)

Reading happens to be a quite time consuming habit, so be sure to block out portions of time for it. I usually read most when I'm on holiday, when I dedicate entire days to reading, but I also read frequently in the evening.

Third, if you really want to read books on programming and are having a hard time forging the habit on your own, consider finding social support like reading the book in a book club. Maybe you can read the book together with your colleagues, or find an online club to join.

share|improve this answer

I partly switched to podcasts. I listen them in the train, while running, ... And when I hear an interesting thing I'm searching the internet. Normally the texts there are shorter and not that timeconsuming.

It's not like reading a good book, but it's better than nothing.

share|improve this answer
    
Could you name a couple good programming podcasts? –  eflat Jan 15 at 19:44
    
se-radio.net - my favorite –  Jordi Laforge Jan 23 at 5:27
    
en.wikipedia.org/wiki/Security_Now more about security. –  Jordi Laforge Jan 23 at 5:27

Just don't read them.

Or, imagine what's next if you just let it go. Is it really that bad? Well, since you've posted a question here, I guess it is. So get deeper into why is it important for you to read programming books, or what will you miss if you don't.

Two more helpful things to think about is to have some kind of a motivational kick before drifting away from reading, and also to train yourself to get better at this.

share|improve this answer

To be honest, I feel the same thing as well. Most of the time, when I need to learn a new programming language, I think of what I wanted to implement using that specific language.

  1. Then I start to implement it, most of the time I will face a lot of issue and problems and it frustrates me and it makes me want to give up (So make sure what you are planning to implement has something interesting and hopefully can make you want to move forward).

  2. If you didn't give up, those problem should start becoming a question that you want to know, and the question will lead you to start looking for solution.

  3. When you know the solution, you may start asking why, and you probably will start looking for more and hopefully it will end up reading the books you need to feed your desire to know more.

Anyway, the above is just some personal experience, it might not work for everyone.

share|improve this answer

I found this interesting. but only reading is not enough you also need to grab ideas from what you read. this may help you, and by clicking on these and reading these article means you are trying to read. So your journey begin from here with hopefully good starting points.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.