Stop reading this blog and learn something

I recall having a similar epiphany about the value of books when you need to learn something new.

There’s a tendency to believe that all information is equally valuable. Therefore, an hour spent reading about, say CoffeeScript in blogs is equivalent to an hour spent reading a CoffeeScript book, only the blogs are free, immediate, and more entertaining.

The last bit is the key. They reason that blog posts are more entertaining is the reason to read the book. They are all sizzle, with optional steak. A book has structure, as Avdi notes, and part of that structure is balance between crazy-fascinating things and fundamentals that are not that fascinating at first but necessary for deep learning.

In cliche terms, books contain information that is important but not urgent. Thanks to the social mechanics of blogs and social news sites and retweeting, the blog posts the filter through the firehose are all urgency. Some also contain important topics, but none contain the important but not urgent stuff that is necessary for a complete education. Any blog post or essay with important but not urgent information falls into people’s “read this later” bucket and never gets the upvotes to make the front page of Hacker News or anything else.

So, you will learn things in an hour on the web, and in an hour reading a book, but if your primary goal is a thorough education in something that is new to you, an hour in a good book will serve you better than an hour reading blog posts.

p.s. Alas, my own books at http://leanpub.com/u/raganwald are simply collections of blog posts massaged into book format, and as such they are entertaining but do not provide the kind of structure and “important but not urgent” information Avdi and I are extolling here. For example, my essays about Combinators and Ruby might make you interested in Combinators enough to read a real book about them, but the book won’t actually teach you introductory combinatory logic.

I don't know why he pushed you should learn "the popular one" so hard, unless he meant that ironically. There's no way to choose the most popular language from PHP, Ruby, and Python.

I do agree on books vs. blogs though. When I started learning Python as my first real language this summer the best source I ended up learning from was LPTHW[1] (I used the free online edition). I think a book like that is a good tool for learning a language, because it makes sure you hit on every important feature/concept in that language. However, I later bought a physical book for $30 about Django that didn't do anything except hold my hand and walk me through what could be a 20 minute Django tutorial on YouTube. Maybe it was just a bad book, but when it comes to learning a framework/stack, I think the documentation provided if you choose one of these so-called popular options will be plenty, and from there it's tinkering and screwing up that gets you there.

[1] http://learnpythonthehardway.org/

Author accurately describes the cycle I go through in trying to keep up with technology changes. If I want to make an iPhone app well first let me pick up a book on design so I can make it visually pleasing. ohh wow this psychology stuff is interesting I think Ill read some of that. man wasnt I supposed to be programming? better pick up a book on how to get stuff done." I think the author is on to something when he suggests immediately applying what you are learning to a real world project. I can read a book on HTML and think I know what is going on until I close the book and try it out. Same with Chemistry or this or that. The best way to learn a new skill is to apply it immediately.

Simple:

Phase I: Print this out, have it framed (with non-gloss glass) and hang it on the wall where you can easily see while you code.

Phase II: A day will come when, while reading this, you will chuckle to yourself and mutter, "I, too, was like that". Then remove it from the wall and pass it on to another noob.

I'm still in Phase I, but have become conscious of this, which is an indication that I may be moving, albeit very slowly, to the second phase.

This was me a year ago: I’ve read all of their design rationales, and despite the fact that I’ve never written an app in Ruts, I totally agree with their critiques.

When it comes to programming books, I tend to prefer paper-based books versus e-books.

With paper-based book it's easier for me to flip back and forth through the book to quickly reference something. Also, reading code snippets is a whole lot easier since you don't have to worry about screen size messing up the code readability and formatting.

>Now use what you’ve learned in a project. For the love of pete do not use it on a project you get paid for, unless you have an explicit understanding with your employer that you are using something you’ve never used before, and will probably get it totally wrong and have to rip it up and start again in six months. Otherwise, use it on a personal project. A small personal project.

Whoops.

To be fair, with my current project there was an expectation that this was a going to be a month long "use and dump it" project.

Well, I just got hired for the rest of the year to expand my horrible, horrible mistakes. It was my first django project and I didn't realize you have to explicitly define relationships in the model on related fields in order to do joins. Now there's too much data and legacy code to go back, and I'm stuck pulling up related fields in other tables one by one... kill me now.

Here's my manifesto for learning:

    1)Be inspired to build something.
    2)Pick a tool you think might work.
    3)Build it.
    4a) Success? Go to 1.
    4b) Failure? Go to 1.

Any time I want to learn something new, I always try to start with a book... SEO, JavaScript, Ruby, Version Control, etc. Being forced to follow a linear learning path works well for me. Even thought many of these concepts are evolving rapidly, books get me the core understanding I need to then venture out online for more current, even cutting edge material.

For me, there's nothing better than cracking open the pages of a book on a new topic.

Edit: Crappy grammar.

i feel offended, Were you spying on me?

I just had to go through this and was forced to learn these tips myself recently. Before I discovered HN I was a PHP guy. I knew it. Used it. Was comfortable with it. Then I came lurking around here and found out that I wasn't cool because I didn't know Ruby and therefore Rails. Then I found out that I wasn't cool because I was using Apache instead of Nginx or nodejs. So I read about all that stuff for most of this year, played with getting Ruby to spit out arrays in reverse and organize them in different ways, got a VPS and installed Nginx and then at the end realized that all I got from it was an Nginx server serving up a static unfinished website in HTML and the knowledge of how to play with arrays in Ruby (and just in irb, not even in a web page!).

The moral of the story is that reading is useless without action. It's easy to fall into analysis paralysis even if you're decently experienced.

I've come to almost despise the hipsters (and that word is so apt for describing them) who are too cool to do things the standard, time tested way. It's one thing to go bleeding edge for the sake of experimentation and furthering your knowledge and skill but when you're off using some esoteric language or framework or whatever just to be different or cool then that's really... Well... Lame for lack of a better word. Like wearing some ridiculous outfit "to be different" and claiming its just fashion that the rest of us are too uncool to get.

I eventually did get out of that unproductive cycle by the way. I am learning Rails but I've put more of my energies into actually producing things that work using uncool but very useful languages, practices, and frameworks. Sometimes the cool kids are wrong. It's more important to get something produced and working well than it is to use some hip technology because the cool kids claim its better. Ive found that a lot of these claims of some tech stack being better either all boil down to some very narrow use case or give you some benefit that's really negligible in the grand scheme of things. Take it with a grain of salt. Read a bit but don't get hung up on the hype. Make something.