Hacker News new | comments | show | ask | jobs | submit login
Teach Yourself Programming in Ten Years (1998) (norvig.com)
183 points by tinderliker 10 days ago | hide | past | web | favorite | 51 comments

I can relate to it through the lens of Karate. I've been studying just about 10 years and I'm just beginning to see the depth of the art. Its almost like you spend those 10 years building the foundation before you can start building the house.

One of the points in the article really jumps out and again, I use martial arts as a lens for comparison. Talking to other programmers extensively accelerates your growth. If I had tried to piece together the knowledge my Sensei taught me through "Youtube, books, & self-study", I would have not gotten as far as I have. There's something about having a mentor that can warp-speed your progress. Anyone who has mentored under a master in their field would attest to that.

The programming culture is one where you're encouraged to go out and figure it out. Yes, there are teams and pair programming but I don't see most companies emphasizing mentorship as much because its not directly tangible on the books. Its more of a long-term investment and they see employees jumping around every couple of years, so why bother?

It would be interesting to see master programmers (30+ years of exp) offer year-long intensives for serious students who wanted to accelerate their growth. I bet you would get some excellent programmers.

Sal Khan has a good talk [0] about applying the methods of learning martial arts to education. That is it doesn't matter how many times you do a retake it matters that you get it correct. As opposed to setting the pass rate at 50% which means you never get a full foundation to build on learning the next level.

[0]: https://www.khanacademy.org/talks-and-interviews/conversatio...

Reminds me of story of a local Taekwondo Great Grandmaster named Moo Young Yun. After well over 50 years of training and extremely high accomplishments, he walks into the gym one day and exclaims how he finally is starting to learn how to throw a good punch.

Similar here. It's been 10 years since I started going on on my own. I've gotta say that about half a year before my life broke down back then that I got introduced to Linux. I joined IRC channels I was interested in; #python, ##C, #Bash, and of course the distro specific channels.

I basically built up my career around my code foo and the way I was taught on IRC. Even if it may seem like a harsh environment in the beginning, they proved to have a point with the semantic perfectionism, only through which one can convey all nuances of what one is trying to say - and do.

One advice upfront, look your stuff in the original technical documentation. The C Standard, the infamous Intel Developer's manual. Learn some assembly, be it on an old 1980ies personal computer.

It's one of the big lessons how you start organizing your code flow, function and data so that you can effectively get things done and make something more from something less with what compares to hammer and chisels. I find myself fixing python code under comparable viewpoints today; being thrifty of what types an object may take, being explicit with comparisons, etc.

The thing that lets this compare to training Karate I once heard in the context of chess; "It's you who is manufacturing your own checkmate". To have a comfortable, easy to modify codebase is infinite work, but the more intention you put into the detail, the less you need to care about the bigger picture. Good code is equivalent to but the intention behind it.

I agree. Christopher Wellons AKA skeeto from nullprogram.com (whose articles end up on the HN frontpage somewhat regularly) has mentored a high school student for two years:


More importantly: the more perspective you have, the faster you can adapt it. You've learned a lot about body mechanics and the interactions of humans in those 10 years. But by learning different movement arts, you'd learn it even faster. Similarly, you have to study more than just "computer science" to gain an expansive perspective and be able to apply it faster than just studying the one thing.

That's an interesting comparison. As it was put to me by my sensei, black belt is when you have the basics down so that you can begin to learn.

So many "learn to code" sites, books, and programs lead people to believe that the journey essentially ends there when it's actually the beginning. Sure, people understand that further experience is needed, but without some kind of guidance it's very haphazard.

Google does have a strong mentoring culture that gets appropriately rewarded in perf cycle. It worked out well for them. People would generally jump to a different team within Google and thus the long term investment isn't really lost.

I believe Kent Beck does a mentorship program like this at Facebook.

The F# foundation also has a mentorship program for people that is free iirc.

Thank You a zillion!. I followed along, got a free membership and am chatting with their helpful community on slack. Their Feb Mentoring program is closed but they have another one coming up for September cohort. All in all looks promising.

More information can be found here http://fsharp.org/mentorship/index.html

Old but good. I have been seeing an interesting discussion around project based learning vs. more formal CS type program lately. As a self taught programmer who got started and became passionate about technology because of MUDs I can confirm project based learning worked well for me. It kept me engaged and pushed me to solve hard problems I might not have ever tried to otherwise solve.

So, to me, making programming interesting is one of the keys. I know I have a common learning and work style that heavily favors the experiential and interactive. Other promgrammers I have worked with can Zen focus and design for days before touching code. I can't. I like to interact, prototype, outline with code, think in smaller bursts, and then iterate. I have learned to be more patient over the years, but that is still my default paradigm.

I think I generally agree with Norvig here. Most of the criticism of his article is misplaced. He isn't saying you should only learn to program in 10 years, but that it is a hard discipline with immense depth.

According to the owner of this company, it takes at least 3 days for somebody with absolutely no computer skills to learn programming. Apparently its the career path of choice for telephone operators in a call center.

What is funny, after programming professionally for about 30 years, Is I want that job in the call center answering telephones. Even more ironic, it takes 1 month of intensive training to do that job.

Having worked in a call center for 3 years I can assure you it doesn't take 1 month of intensive training. It takes a variable amount of time to get up to speed depending on how much you are asked to think.

In some call centers, you will be following a script about 90% of the time and that takes very little training. In others you actually have to think and troubleshoot issues, those take a bit more time to get up to speed on.

All that being said, I can assure you that you do not want to work at a call center. I'd take whatever programming job you currently have over the call center I last worked at. For whatever reason, call centers attract the worst kinds of managers in this day and age.

What I see more and more is an expectation that, since computers themselves have consistently gotten easier to use with the introduction of things like mice and touch-interfaces, plug-and-play and graphical interfaces, programming them can be assumed to have gotten proportionally easier. Unfortunately for everybody involved, it's actually the other way around - as computers have gotten to be easier to use, they've become _harder_ to effectively program, since user's expectations keep growing exponentially. So you have bosses who expect everything to take a few hours at most because, "it's not like I'm asking you to put together one of those incomprehensible command-line thingies that you have to type into, I'm just looking for a normal drag-and-drop reactive cross-platform cloud-based application!"

> I want that job in the call center answering telephones

Having worked in a call center, I can say with roughly 99% certainty that you do not want that job. It's got to be one of the most mind-numbing, soul-crushing occupations on this planet.

If I could retire today, I'd probably go back to selling video games in Best Buy.

Why do you want to work in a call center? Are you also willing to take the pay cut? Why have you not made the move to a call center?

I entered the work force in 2009. This year is the first time I feel like I know wtf I am doing.

Don't worry, that feeling will pass and you'll feel like an imposter again in no time.

I second this. It took me about 7-8 years to feel like there's no webdev issue that I couldn't solve: be that developing a new feature, improving the performance of busy services, or identifying and fixing hard-to-reproduce bugs.

I usually take that as a cue that it's time to hop ship!

Already in the first few lines of the article, there's a reference to a post-1998 date, so I started wondering about the veracity of the (1998). There's no clear reference to the original publication date, buy plenty of references to dates much later - the copyright notice says 2001-2014.

But, lo and behold: https://web.archive.org/web/19980206223800/http://norvig.com...

It's a very different article, but at the core, it's the very same idea. Pretty fascinating that it apparently has been "ghost-edited" to stay current.

It was about 10 years ago that I read Norvig's "10 years" post: https://michaelwhatcott.com/10-years/

Last year was the first time I managed to write some code that didn't obviously suck. It was great! (And about 9 years after I started.)

Though still, 95% of the time, I walk away from my check-ins feeling like my code could be a lot better, but not seeing how until much later.

How can this be from '98 when it mentions Malcolm Gladwell and someone's death year as 2004?

And it mentions Go which I believe was invented in 2009. It was on the site previously as 2001 which also seems wrong https://news.ycombinator.com/item?id=3439772 . Maybe it is just being updated.

I must be blind, I'm not seeing where this was written in 1998? I see some couple-year-old comments. I only ask because I was going to express surprise that the Amazon links still work.

Does the (1998) in the title maybe not mean it was written in 1998?

use "view source" and see the fourth line: "Changed by: Peter Norvig, 13-Jul-1998"

Clojure was built in 2007, so it's clear there have been some changes.

>> branch misprediction: 5 nanosec

Turns out it was a lot more than just "5 nanosec".

Old post but a classic one. Reminds me of the 10,000 hour rule of gladwell’s book outliers

Great article. I think programming is a discipline that's especially susceptible to ineffective learning approaches because it's intimately bound up with utility. Part of this stems from the fact that we're not yet at the point where it's learned ubiquitously at a young age.

For example, compare programming pedagogy to the typical way in which children are taught to read. We begin learning to read at such a young age that the actually utility of reading is more or less completely factored out of the equation--we go to school, reading is a part of what we do there, and so we sort of just accept that and spend a great deal of time engaging in the activity intimately--exploring its nooks and crannies, playing with it, joking, discussing it with classmates. In the case of programming on the other hand, a lot of autodidacts have selected the discipline not for any love of the game (of course there are several who do have a genuine love for it) but rather for some perceived use-value it provides. For example, if I learn to program I can get a better job, or I can offload some menial task, or I can ultimately do some other thing that happens to require programming (e.g. making a video game is what I really want to do, and if I have to learn to program to do so, so be it). This sort of utilitarian frame makes it very easy to engage in behavior that frustrates learning--reading for information only, rushing through material, copying and pasting examples, seeking out solutions to exercises when stuck rather than exploring and working through them. In general it's much harder to be a good learner if you've attached some ulterior motive to your learning activity.

There's a lovely German word Mitgefuhl, which is often translated as compassion but literally means "feeling with". I think it's a fundamental concept underlying a great deal of successful human endeavors--just as you need to exercise compassion in order to really understand someone's emotions or perspective, I think there's a lot of merit to dwelling with, or, as ancient monks practiced, ruminating (chewing the words) intellectual material. Taking one's time is important, as is checking in periodically to ensure you're still consuming things consciously. When I read a book, no matter its subject, I like to imagine I've signed a lease to rent out an apartment with its author--to really get to know the consciousness behind the words--not in any psychological sense, but in a purely epistemic one, to achieve a better understanding--to learn how myself and this consciousness might live in harmony, to imagine conversations--to 'feel with.'

As someone who is self-taught when it comes to programming myself (and still has an incredible amount to learn) I can say my own experience of learning and the rate at which concepts solidified definitely increased once I broke my interest in the practice free from any concern over utility and decided it was simply something I found interesting--something I valued irrespective of its practical application.

good link - thanks

10 years is a bit too much don't you think. I mean comparing 24 hours or 21 days with 10 years is highly demotivating. I think 1 year or 6 months would still be an inviting title and it's not that farfetched. I've seen people become good with a programming language in lesser times than a year.

I first read this way back when it was first published. I was still studying full time back then. I recall it being one of the things that really motivated me to learn more. It meant that there would always be something new and interesting for me to learn that would make me a better programmer.

~17 years later that has definitely been my experience.

It’s possible to be very productive in a language after 6-12 months. The code might be decent, or with some talent and hard work, even good. It really doesn’t take all that long to learn enough to produce some cool things. However, I’m almost certain that if you look back at the code you write today in 12 months, 5, or 10 years, you’ll see many things you’d do differently. This is partly because In 10 years you will see many more problems, and solved them in many different ways. Personally, that’s one of the things I really love about this field.

I view programming similar to carpentry or metalwork. You can't really sit down and learn metalwork in 24 hours.

24 hours is not even how long I had to file a metal block until I was deemed ready to use heavy machinery during secondary school. I filed it for 3 weeks, 5 days a week, 9 to 5.

21 days is not enough to master metalwork, even though I was allowed to use heavy machinery, I borked up more than one piece until I eventually got it right at the end of the school year (which was about 6 months of metalwork).

And I think I am still way of from mastering it, not that I want to.

Programming is, IMO very similar. Sure, you can get a hammer and start hammering on a metal sheet and that'll probably produce something in the right shape. But learning to program, mastering it, takes time, 10 years is IMO a good estimate. I've been at it for 8 years now and I still got very much to learn.

Of course people can become good with a programming language, just like you can get good at filing a metal block in 3 weeks. But it doesn't mean you've mastered all the tools yet.

Perhaps we should stop trying to claim we do science or engineering and call it a craft

[0]: https://en.wikipedia.org/wiki/Software_craftsmanship

[1]: http://manifesto.softwarecraftsmanship.org

Well, there are definitely distinctions to be made, as in electrical and electronics work — I'm drawing crude lines here —

An Electrician may be a master of his craft, but yet not an Electrical Engineer, who may be a masterful engineer but yet not possessing as deep an understanding as a Physicist, and so on.

That said, the scale tips both ways. A physicist may know why and how an electron behaves a certain way within a material making up a resistor, but not have the practical know-how to use that in an effective way as an engineer might. An engineer might be able to hack together a prototype, but lack the refined master skill and discipline of an electrician to employ the designs and put it into a real world context on a regular basis. It goes without saying that you'll much more rarely see a physicist out in the field laying cable for power distribution in a new train station, etc. There's an old aphorism that leans into this a bit: "the wise things confound the simple, and the simple things confound the wise". I'm abusing that a bit, but still kind of works.

I'm making a gross guess here, but maybe it's that science and engineering, in modern times, hold more of a lofty position and boast greater intellectual capacity traditionally, that so many would not want to be 'reduced' to a craftsman. We might do better to consider them just different aspects of the same whole.

It's probably not too wrong.

Software development unites a lot of things from science, engineering and craftsmanship. I guess we should stop trying to cram it into preexisting categories and take the best parts of each subcategory.

If more programmers would apply scientific method to their craft they’d engineer much better software.

I don't think Norvig is too worried about giving pep rallies.

At any rate: lately I've been having to interact at work with some folks from another company whose entire outlook of what "programming" is revolves around web CRUD stuff and some interactive-looking front-end... web stuff. So "I learned some new programming skills" to them is closer to "I learned how to make an HTML5 caroussel using jquery and Laravel" than "I learned how to calculate road distances using GIS LineStrings and Djikstra's algorithm". Their whole world looks like a CMS. There's a threshold of "meta" they cannot cross.

I think this is both why PHP is so popular and so despised: it attracts people who wouldn't be able to grok concepts at a higher level of abstraction (say, Python @decorators) so they don't need it. PHP -- and really, Laravel, whatever that is -- is all they need.

As a system administrator, I’m regularly amazed by the number of web developers who have little or no understanding of HTTP, the protocol that underlies the bulk of their work. Many don’t know even know what a transport protocol is in the first place. They know that most form submissions (or AJAX requests) should be POST and that some can be GET but they don’t know that these are HTTP methods.

I’ve had to teach quite a few people the basics of HTTP: a user-agent makes a request and a server replies with a response, that both requests and responses are composed of a header and an (optional) body, and some of the important information that might be included in the headers (cookies, character encoding, caching information, etc.).

... also process context / managment / residency / systems level architecture

everything is running synchronously in the current thread on the same machine (or can be roughly abstracted as a single machine where all backend is simply 'invisible')

like a tv.

Learning to program is not mastering a new language. A good programmer can wrap their head around any language in short time but becoming this good programmer in first place will take years.

I totally agree with this assessment.

This is the reason lots of people learning programming try few months of Javascript/Ruby , then they got stuck to solve any real life programming problem. The reason is that they have not mastered the "basic core concepts" of programming such as traversing an Array backwards, nested loops, two indices one activates after another ete..

"but becoming this good programmer in first place will take years."

> Learning to program is not mastering a new language. A good programmer can wrap their head around any language in short time but becoming this good programmer in first place will take years.

Compare to an instrument. When have you "learned" it? When are you okay at it? When are you good. When are you great? When are you a master? How much effort does each step take to achieve? I think a more apt title, and more inline with his content, would be "Master Programming in 10 Years".

This. Saying "It took Mozart ten years to become Mozart" isn't evidence it takes ten years to become a programmer, it's evidence it takes ten years to become Linus.

Becoming "good" with a language is not equivalent to becoming a productive, efficient, or employable developer.

I don't think it's demotivating. If it only took 6 months, I could put off starting for a few months and still be done by the end of the year.

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact