Tuesday, September 4, 2007

You Can't Learn To Program In A Hurry

A friend turned me on to this essay from Peter Norvig entitled Teach Yourself Programming in Ten Years.  In it the author attacks the idea of the "Teach Yourself C++ in 21 Days" kind of books.  They make it look easy to learn to program.  Unfortunately, it isn't.  You can't become a good programmer in a month.  In fact, you can't become a good programmer in a year.  You don't need to go to college to learn how to program but it helps.  Learning on your own is a lot of work.  Learning to program is like learning anything of value.  It takes a lot of practice.  The essay quotes research indicating it takes a decade to master any significant skill. 

Norvig gives some good advice on those who want to become programmers.  Most of it, like just get out there and program, is great advice but is also common.  A few though, are less commonly stated and deserve repeating.  Among these are:

  • Work on other people's programs.  Learn a program written by someone else.  This will teach you how other people have solved problems and will teach you how to write maintainable software.

  • Learn a half dozen languages.  Learn languages that have different approaches to programming.  Each new sort of language will open your horizons and help you see problems in different ways.  Solving a problem in C will lead you in different directions than solving the same problem in Smalltalk.  Unless you know both languages, you'll likely fail to see one of the solutions.

  • Understand what's going on below your language.  Modern programming languages are so high level that it's easy to forget that there is a real machine running the code.  However, as Joel Spolsky says, all abstractions leak.  That is, there will always come a time when you have to understand the layer below the abstraction to solve a bug.  If you understand how memory works, how drives work, what makes a processor stall, etc. you'll be better off.  I see this often in those we interview.  They understand a programming language but they don't understand the operating system.  If you don't know the difference between a thread and a process or if you cannot describe how virtual memory works, you'll be at a loss when things go wrong.

There is advice here for many people.  If you are learning to program, the application is obvious.  Not so obvious is that if it is going to take you a long time and a lot of practice, you're going to have to put in work on yoru own time.  You won't learn to be a good programmer without spending your evenings/weekends doing so.  However, there are other things we should take away from this.  If you are a manager and you are trying to grow young programmers or new programmers, you need to give them explicit time and opportunity to program.  No one can just take some classes or read some books and become a programmer.  For those who are experienced programmers, it is a good reminder to read the code of others.  If you work at a big company, you can look at the code of those around you.  Seek out those who are more skilled than yourself and examine how they solve problems.  If you are at a smaller company, seek out open source projects.  See how they do what they do.

Here's a piece of advice that the essay doesn't mention:  rewrite your programs.  Each time you'll have a better understanding of the problem domain and thus you should be able to solve the problem in a more efficient way.  You'll learn how much you've improved when you see your old code and you'll learn to approach the problem in a new way.

Read the whole essay.


  1. PingBack from http://msdnrss.thecoderblogs.com/2007/09/04/you-cant-learn-to-program-in-a-hurry/

  2. Ten years? I think you can learn programming for longer than that. At least I do ;o)

  3. Funny thing, I just finished "Teach Yourself Java in 21 Days". I love these sorts of books, they're great high-level introductions and provide me a simple base to build from. I completely agree with the underlying premise, it takes a long time to master any craft, and programming is no exception.
    What I've been noticing lately is how many programmers don't bother to learn their craft, they just punch clock and try to learn on the job. To them, a 21 days or 24 hours book will never be read completely and provides them just enough direction to complete the task at hand. For this group of people, these books are "good enough", just like their code.
    - A

  4. I agree with Adam, I think from these Book you will be able to get some idea about the language that you are going to learn.
    To start anything you have to have some guideline which can help you to move forward. And I think these kind of books can help you. Yes, its true these books are not so good but still they can introduce the language with you. Of course every body will not like it, then these books are not for them.

  5. Hello there
    It is great article it defiantly makes me to consider and see where I stand. Anyway I will just try to explain where I stand and I need your suggestions. Now I am doing and studying SharePoint .which I love to do, I have been studying it for 9 month and I am still busy with it .i was being a power user of SharePoint and I was lucky to work on SharePoint projects. Now I get a new job at HP which will be junior SharePoint consultant. Well the question is how can I master it? As you know SharePoint is a development platform .So let us see what I know already…
    ASP.Net (I have just simple understanding)
    XML, XSLT (Good Understanding I am busy with this one)
    VB (40% of understanding) or C# (No clue)
    HTML and CSS (Very Good Knowledge)
    JavaScript (Not really good)
    SQ L (Not really good)
    SharePoint out of the box functionality my knowledge is (80%)
    SharePoint Designer (60)
    InfoPath (70%)
    Well now I have a little knowledge of every thing (as they say which is dangerous).Would you please advise me in which way I can grow I love to do all of them but can I? And I am a quick learner and workaholic and I love what I do) .I did some advice specially people who master SharePoint from where I can continue? And how can I structure my knowledge. It seems I am doing a lot and nothing as the same time. I just follow the blogs but I do not post in any of them so please send me your advice by this email (Hilinamulatu@gmail.com)
    From Belguim

  6. Steve,
    Thanks.  Excellent resources...Norvig's site is really fun.  Additionally...as a student who only picked up computer science in college, what resources/advice do you have?  The overwhelming advice that I've gotten (from all) is to just...do it!

  7. I'm a lead developer and I learned mostly on my own.  The advice I would give is the same thing you have all heard: never stop learning.  Oddly enough, that advice applies to all aspects of life.
    The addendum to that is: don't just study, apply.  Put that knowledge to some use, even if for your own benefit.  For me, nothing sticks in my mind well until I've worked on even a small sample app.

  8. @Franco - Definitely.  10 years is the mimimum, not a maximum.  As Greg says, always keep learning.
    @Adam - I'm not indicting the "21 days" books.  Rather I'm commenting on their sufficiency.  They are a great starting place.  Just don't end there.  You make a good point about the willingness of some to learn.  Programming is something best done when you love it and are willing to put in effort on your own.
    @Jeff/Hilina - The best advice I have in learning to program is in my post linked to off the word "work" in the article above.  To sum it up, make sure you learn more than just the syntax.  Learn operating systems, processor architecture, etc.  Then go out and practice.  Join an open source project or start something of your own.  Success isn't important, the process is.

  9. Thanks Steve
    I am ready to do it but I do not know from where to start but I will figure it out
    Jeff I have the same thing I did Computer science and I find it a bit difficult because after school I did now what I would like to do. Until I get to know SharePoint
    Good Luck

  10. You guys are all crazy. There is no "craft" in programming. If the code is "good enough" then that means it works. The entire app will be re-written in 3 years anyway. Go home early and spend time with the family.

  11. Try maintaining code that is just good enough. I often become disappointed at old code that I have written. (Never mind the disapproval of the old code from others)
     I once spent longer to review a piece of code then the programmer to to make it. Yes it probably worked. But, if it ever had a bug or needed a change, it would take longer to run through the disjointed ramblings of code then it would to rewrite the whole thing.
     I would be dissappointed in a day that I did not learn something. And I have been doing this stuff for 25 years.
     On the other hand, this can not be a 24/7 job. Just be open to learning. Like the article says look at the code that you are working with. Recognize and learn from the good stuff. Recognize and avoid doing the crap.

  12. >>If the code is "good enough" then that means it works.
    Code is for programmers, not for computers.  There is a vast difference between code that works and code that is useable, readable, and maintainable.
    You can learn syntax in a short period but knowing how to create good code takes a long time to master.  Most don't and their code is embarrassingly bad, even if it works on the computer.

  13. @Jeff - We're still using and maintaining test code written a decade ago.  Win32 doesn't change very quickly and so neither do the tests.  In the world of Web development right now 3 years is probably the outset, but even there things will slow down.  Writing "good enough" code is dangerous.  As Mike and Greg point out, it's going to be very expensive in the long run.