Stop reading this blog and learn something

Software development is a wonderful field to be a noob in. Perhaps more than any other discipline, there is a wealth of information available for free online–everything from fundamental computer science courses, to the night-by-night learning notes of a master programmer. And, of course, there are millions upon millions of lines of Open Source code free for the reading.

Unfortunately, this embarassment of riches can be as much stumbling block as well as a stepping-stone. You can learn a lot from this information overload, but you can also waste a great deal of time and find yourself with very little to show for it. Personally, I’ve probably wasted thousands of hours in this way over the years. It’s only recently that I’ve come to identify the antipattern behind this waste. I hope that in writing this I can help you to avoid my mistakes.

The pattern usually looks something like this:

Oh man, this web programming stuff is HOT! I need to get in on this!

Let’s see… if I want to program for the web, I’ll need to learn a programming language better suited for the web. And I don’t want to get stuck with on that sucks, so I need to pick the very best one.  Research ALL the languages!

[insert 3 months of reading about Perl, Python, Ruby, and PHP and maybe writing one or two "hello world" examples]

OK, my “hello world” was totally better in Blub than in any of the other languages. But now I need to pick the right web stack for my awesome app ideas. Subscribe to ALL of the blogs!

[Insert three months of voraciously reading web programming blog articles.]

I’ve been reading some of these blogs, and while it seems like everyone is using “Ruts”, it has almost become passé now. Some of the more obscure competitor frameworks look a lot cooler. 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. Yeah, I don’t want to to be stuck in a 6-month- old outmoded framework like Ruts.

Also I need to remember to use the “Box Turtle Pattern” that everyone is talking about.

No wait, now they are realizing Box Turtle doesn’t scale, and the Elephant Plop pattern is the way to go. Man, why did we ever think Box Turtle was a good idea? Whew, glad I hadn’t started my app yet. Dodged a bullet!

Oops, no, looks like Classic Box Turtle coding is making a comeback with a vengeance. Man they are totally right, when you do it correctly it’s way more robust than Elephant Plop.

Gosh, what a vibrant community! These advances are hard to keep up with! When am I ever going to find time to write code?

Oh man, this smartphone programming stuff is really heating up…

Maybe you mastered web programming long ago, but if you’re still learning at all there’s probably some technology that you’re at this point in. Maybe you’re like me and right now it’s client-side JavaScript frameworks. You know it’s there, you know you’re interested, you know where to find out more information about it. And you know that there are a lot of alternatives, and that despite the overwhelming amount of information available it isn’t at all clear where to start.

Without further ado, here is Avdi’s autodidact guide to learning a new programming technology:

  1. Do not subscribe to all of the blogs. As yet you have no way of contextualizing the information you will receive from this firehose, and it will just be a paralyzing stream of often-contradictory information.
  2. Make a list of the alternative languages/libraries/frameworks/whatever.
  3. Pick the most popular one. Here are the criteria for “most popular”:
    • You can easily discover high-traffic fora–mailing lists, IRC rooms, forums–dedicated to it. When you ask newbie questions on these fora, they are quickly answered.
    • There is at least one reputable book about the topic. Books aren’t a perfect indicator of technology viability, but the fact that someone has taken the time to organize knowledge in a systematic fashion is a decent heuristic pointing to a certain level of stability.
    • There is a healthy users group dedicated to the technology, meeting regularly in your nearest big city.
    • At least a few people in the community are too hip for it, and have vocally moved on.
  4. Yes, I said the most popular. Not the “best”. You don’t have enough information to figure out the “best” one yet. We’ll get to that. Right now, you need to pick the one where any problem you run into as you learn can be easily googled.
  5. Join that local users group. Attend it diligently. You will need those people.
  6. Buy, and read, a book about it. Yes, an actual book that you can read on your actual iPad. Or even, (gasp) on paper. Books have some nice properties which most online learning resources lack:
    • They are (relatively) complete. Free online tutorials have a nasty tendency to have gaping “to be written” sections, or to simply stop right in the middle.
    • They usually focus on fundamentals, rather than the latest nifty techniques. Right now you need fundamentals.
    • They have structure. Right now you need structure.
    • Authors of capital-B Books typically spend more time making sure that you’ll be able to reproduce the examples shown in the book using a given version of the tools. Not always (sadly), but usually. For that matter, they usually have fully-worked examples rather than snippets.
    • Fewer hyperlinks, and thus fewer opportunities to be distracted by rabbit holes which lead everywhere except to you writing actual working software.
  7. 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.
  8. When you run into trouble, consult the people in the aforementioned fora and local users groups. You are attending those groups regularly, right?
  9. Congratulations! You now have the beginnings of context and perspective on this new realm of knowledge. The annoyances which caused those aforementioned hipsters to abandon technology X are no longer academic to you; they are real things which you have also dealt with.
  10. With your newfound perspective in hand, review that list you made in step 2. Toss out the projects which have become defunct since you made the list. Pick out one which specifically addresses the problems and irritations you encountered in step 6. Use online tutorials, blogs, whatever; you know the territory now and don’t need to be so pedantic.

This is the framework I’m going to try to stick to, going forward. If you decide to try it, please let me know how it works out for you.

This entry was posted in Rants and tagged . Bookmark the permalink.
  • http://profiles.google.com/jpersonna John Personna

    Interesting post. As an old time programmer (30 years) I have a slightly different perspective.  I mean, we overlap on much of the above, but I think it matters a bit less which things you choose to learn first.  If they are reasonably popular and reasonably cutting edge, they’ll be a good foundation.  Say the question is PHP, Python or Ruby.  I might suggest PHP as the simplest, but I wouldn’t fight the other two.

    FWIW, I typed up a road map here:

    Learn Computer Programming

    I guess it is for a certain kind of ground-up person.  I recommend getting a “scratch” computer and building up knowledge on the whole LAMP stack.  That’s Linux, Apache, MySQL and PHP.  It’s a good directed tour for a newbie, because the LAMP stack is very widely used.

    I list a lot of “alternate paths” in my blog section, though

  • http://www.markhneedham.com/blog Mark Needham

    Cool post. I often get stuck in between deciding whether to blog about stuff that I’m learning or go and learn new stuff.

    It always seems like the latter is a better way of improving more quickly but quite frequently once I start writing about something I realise that I don’t know it as well as I thought and then I get to go and fill in the gaps of what I don’t know.

    It’s the same with reading code/books – it’s useful but you need to find a balance between that and actually doing stuff. A lot of the stuff you’ll read only really makes sense if you have some context on the topic i.e. you spent some amount of time actually building stuff.

  • Anonymous

    This is really good advice, I’m gonna give this approach a shot too.  

    I find that all the options we have now as web developers is having a paralyzing affect on me.  This system is definitely going to work better than my previous method of finding the one with the “coolest” name. ;)

  • http://profiles.google.com/jpersonna John Personna

    BTW, I do prefer web tutorials and howtos to books, and I prefer Google to find them.  I wonder if the top hit for “PHP tutorial” or “Ruby tutorial” is ever going to be truly bad?  I’d think not.  I could go further and say that finding a good tutorial or reference is a meta-skill that benefits programmers for life.

    The important thing, especially in the beginning, is to fight impatience.  Be confident that you are building knowledge and that should take time.

  • Anonymous

    Not following this advice over an embarrassing number of years is how I went from aspiring game developer to a (crappy) web developer. Just now digging myself out of the hole and trying to figure out where I want to be and what I want to be doing.

    *whine* I’m too old to be in this position. */endwhine*

    • chiki

      I’m also on the same boat, with several years wasted in the “Research, compare a lot, not really learning and not coding at all” pattern and I’m also trying to stop this embarrassing situation and be really productive. My excuse is as Avdi said, “trying to choose the best”. But also I’d hate to be the opposite: “Quick and dirty fix, don’t care how or why as long as it works if only in this case, chewing gum and paper clip solution” type of character.

      This way of thinking may be some psychological condition, like an obsessive-compulsive kind of thing.

      Also trying to learn a lot of things at once and not moving forward in any of them is very frustrating and demotivating.

      So reading this article it’s been very helpful for doing some self introspection, and I will try to implement Avdi’s advice ASAP!

  • http://twitter.com/dennismajor1 Dennis Major

    I love Blog’s title – but I couldn’t do it :) – very thorough treatment of a subject I’ve been thinking a lot about myself.

    IMO there is *one big* item missing from this article that, once you pick a technology target, relates to progressing up its learning curve very efficiently.

    I was first, figuratively speaking, slapped across the head with the importance of this idea (something that should be very self evident) by Zed Shaw – his point was that highly focussed memorizing of key/core content produces large efficiency gains for learning the rest of the huge amount of “stuff” to be learned.

    My experience has been that his point is quite valid. In that vien, there is a utility that has turned out to be my best friend to get the memorization of the core facts down – ANKI. It’s a flash card utility whose prime objective is to make flash card memorization very efficient. 

    It does so by using a time sensitive algorithm along with an answer evaluation algorithm in which you self evaluate each answer you make to a question. These algorithms cause times between card repetitions and frequency of repetitions to increase and drop respectively with each session.

    The ANKI interface takes some learning curve time itself as well as time to find and implement features that work best for you – in my case typing my response in and having regexp scan it for completeness and accuracy is my cup of tea. Also, tuning or better said refactoring your questions is very important to realize ANKI’s delivery of highly efficient learning. Questions are as important, if not more so, than the answers.

    From experience, I have no doubt that memorization of core content, principles and syntax as a first step (say 25% or less of stuff to be learned) will make the other 75% or more come on line for you very very quickly.

  • Anonymous

    I like your criteria for picking the right technology. At least for me, I have found that the personal project is important because I learned a lot faster when I have concrete problems than when I am just reading about possible problems. Also, doing it fast beats doing it right. One is not going to get it right in any case, so getting something out fast helps.

  • http://psionides.eu/ Jakub Suder

    I’d add one thing: do NOT try to learn everything about a given technology before you start writing code, with the intention that your code must be perfect from the first line. It won’t be.

    Read a bit, write a bit of code, then read some more, then write some more. Read a chapter or two and try to apply the things you’ve just learned in your code, and so on. Don’t just rewrite examples, start writing something useful already.

    I’ve spent way too much time trying to read a whole ebook and all documentation on a topic before starting coding, only to give up shortly after that and switching to another technology and starting again…

  • http://rosenfeld.heroku.com/ Rodrigo Rosenfeld Rosas

    I wouldn’t advise doing so in lots of situations. You should be able to detect when your choice really matters. For example, I was exactly in you situation of looking for JavaScript frameworks a while ago. But I do lots of JavaScript templating related work, so I knew I should take a look in lots of them before choosing the most popular ones (maybe SproutCore – now Ember – or Backbone). I could finally decide for Knockout 1.3 beta (now 2.0) and it worths the researching effort. Now, Ember could be a good choice to me too, but definitely not Backbone or the other approaches. Of course, after starting working with Knockout it is much easier to identify what I like on it and what I don’t like on it (performance for lots of items). I’ve even started to develop a new framework targetting at performance a while ago but I had to stop due to time restrictions… I need some continuous free time for developing it, but I think my ideas are still valid. I would only need some time to complete it, but anyway this is out of the focus here.

    Deciding for a language and specially for the web framework if you’re going to do we programming is also a decision where I think it worths dedicating some time to read about the alternatives.

    But there are situations where you’re right. You don’t need to spend a lot of time choosing each jQuery plugin you’re going to use if that is not important for you. Or choosing some key-value database to start working with to get some experience. I mean, if you have decided that you need a NoSQL database, you should take your time to learn about MongoDB, CouchDB, Redis, etc until you could decide which one to use if the database is a key technology for your project. But if you’re just using it to store some log while you get used to it, choose whatever it comes to your mind. It doesn’t matter that much.

    Recently I was requested to implement some search among some HTML documents taken from EDGAR filings. This isn’t really a key part of the system I’m maintaining, so I just took Solr for that and built a wrapper over it just in case I want to replace it some day. I could evaluate using Lucene directly or Elastic Search, but that research wouldn’t pay off at this time. This decision is just not critical as I won’t be using lots of features from any of them. It is simpler much easier to me to write a wrapper with the small bits that are of real interest to my project.

    So, please don’t give general advices like this. People should be able to decide whether it is a key decision that it worths the time spent on researching  about it and when they should just take the most popular one and don’t waste their time.

    • http://avdi.org Avdi Grimm

      I guess I wasn’t clear. My point was never that you should choose the most popular products. It’s that if the field is new to you, choosing the *best* tool for your job requires context, and the quickest way to acquire that context is to learn the established product to which all the other products are compared. I have a better metaphor, but that will have to wait for another post.

  • http://twitter.com/darushimo Andrew Shimomura

    awesome. thanks. trying now. starting with LPTHW…again. keeping focus. having game plan: 2 wks. timely, thanks.

  • Anonymous

    Interesting blog. But I have a slightly different perspective and it is  more of a personal choice whether you want to learn first or you want to experiment side by side. As a student who hasnt yet the unraveled the mysteries of the corporate world, I would prefer experimenting with lot of 
    different solutions . It kind of triggers your understanding towards how things work and which framework is better than which one and more importantly why it is better. My understanding is that the post is related to people who are currently working in the industry, still I would say you wouldnt have enough time to go through the steps as you illustrated. Probably you will have to choose one before other and you wouldnt have time to actually understand why and where it is better and whether it will be future-proof or not. Would like to hear your reply :)

    • http://avdi.org Avdi Grimm

      The point is that even if you are experimenting with lots of solutions for the fun of it, you’re going to be a lot more effective at that experimentation if you’ve already learned the more established solution which the newer ones are a reaction to. Otherwise none of the subtle differences between them will make sense to you, or you’ll fixate on a minor design difference and miss the bigger picture.

  • Anonymous

    One of the first things I do is to find a good language reference. Documentation is extremely key to learning a new language.  Even in the documentation jungly that is rails, how does one find the best one? I’ve used api.rubyonrails.org a lot. guides.rubyonrails.org is  another rails examples for good documentation. Finding documentation like these for the new language is fundamental to learning and finding yourself around the new language.

  • http://twitter.com/derickprize/ Prize

    I have been programming for approximately 2 years now, but I recently got into web development a couple of months ago.

    I’m only a beginner, but this is something you should know if you’re starting out: Don’t switch technology stacks when you’re frustrated. 

    During my first year of programming, I was into flash game development. I tried many different routes like Flixel, Flashpunk, Pushbutton, and plenty of other libraries too. When I couldn’t solve a problem I would get frustrated and switch libraries thinking, “Hey, this framework is crap. I should probably switch.”

    If you’re having trouble thinking about how to solve a problem in PHP, switching over to Ruby will not make the problem easier. In fact, it will make it harder because now you have to deal with new syntax and other issues related to the language.

    You will be tempted and enticed by these new languages and libraries, but you must resist! They all claim to make one aspect of software development easier, but you have to learn the fundamentals.

    So pick a popular language that you like and stick with it. It’s like a marriage. You don’t leave your wife after your first argument do you? Work it out for a while, and eventually you will understand each other. :-)

    • http://profiles.google.com/jpersonna John Personna

      I think that’s a good point, that there could be a temptation to bail too soon.  I know that I’ve experienced periods of frustration, where it feels like it’s just not going, before the breakthrough.  I assume it’s something about the way brains work, and that sometimes time off (“re-filing time?”) really helps.  If we “flit” too much, we lose the benefit of that sub-conscious ordering.

    • http://website-in-a-weekend.net/ Dave Doolin

      What you are doing is probably inevitable: everyone does the “greener grass” jump back and forth across the fence once in a while.

  • rochak shrestha

    I find this article very useful as finding myself in the same situation. Thanks a Lot.