Live data from Hacker News

Teach Yourself Programming in Ten Years (1998)

norvig.com

201–210 of 323 posts

Re: Teach Yourself Programming in Ten Years (1998)

#201

I bought a copy of "Sams Teach Yourself C++ in 24 Hours" at a CompUSA in 1999. The guy at the checkout looked at it, laughed, and told me about this article. When I was 16 I was looking at programming books at Borders and a guy handed me a copy of "The C Programming Language"; changed my life. So much of my career has been shaped by running into developers or just people interested in programming out in the world. Th…

Sheet. Thank YOU for that comment!

It connected me back to some of that magic.

The same magic at "computer fairs (faires)". That same magic when you happened across that other nerd in the college/school lab doing something cool and subversive.

Re: Teach Yourself Programming in Ten Years (1998)

#202

Just doing something for 10 years doesn't make you an expert, I started coding 11 years ago- as a kid. But my knowledge became so diffuse across topics I was interested in that I never really became an expert in any of it.

By "doing something for 10 years", I think the implication is you're actively working on that subject area, regularly, for 10 years. Not per se occasionally working on something every now and then. You can become a really good Chess player if you consistently play for 10 years--you figure out all the strategies and shortcuts, and it would be unusual if you weren't really good compared to someone playing for a year (a…

I agree writing a variety of software will have similar base ideas, but still, having a good foundation in a topic doesn't make you an expert. I've barely used Java, but if I had to I could learn enough to write it pretty quickly, that doesn't mean I understand at all how JVM and Java's GC works, or what a factory is.

Re: Teach Yourself Programming in Ten Years (1998)

#203
post #104

Great article. At 8 hours a day, 40 hours a week - 10,000 hours of practice will take 250 work weeks to achieve. That’s about 5 years of nearly non-stop programming. Realistically, it takes closer to 10 years to achieve that goal.

The 10,000 hour heuristic isn't particularly accurate, it's just popular. FWIW, 10 years professional experience seems to be about right, give or take, to make a solid developer. I don't think I've ever met anyone who really got there in 5. Some people shave a few years off by having done it obsessively as a teen also, but at some point that typically overlaps anyway. Of course there is also the old saw about 1 year,…

I have a little over ten years experience, and when I read code that I wrote at 1-2 YoE it's shamefully bad, but after that it starts to get pretty good. I don't think anyone would notice a huge change between my code 5 years ago and today. I've moreso improved on soft skills.

Though it probably helped that I had two mentors at a job 2 years in who were ruthless about reviewing my code.

Re: Teach Yourself Programming in Ten Years (1998)

#205
post #196

Earlier quoted context omitted.

I wonder who's going to write the "Teach yourself Rust from scratch in 21 days" book. If C and even C++ can be learnt effectively as a first programming language, there's little reason why Rust couldn't be. And if not Rust, maybe Golang could play that role.

The Rust book is basically that. An hour per day would probably get you through it in good time.

TRPL assumes familiarity with some existing programming language, such that much of its focus is how Rust differs from more common languages. A true "from scratch" book would probably first teach idiomatic Rust as something not too different from a pure functional language (in that the default approach in Rust is to pass objects by value and forbid all shared mutable state, just like FP languages do) and introduce interior mutability subsequently as a way of supporting more "imperative" patterns of coding.

Re: Teach Yourself Programming in Ten Years (1998)

#206
post #158

I am at times more of a book learner, but find that attitude is often more helpful for non-CS disciplines that change slower (eg, math/physics). A recent negative book example for me is the Quantum Programming book from O'Reilly. I found that it did not discuss quantum circuits in a detail that helped me really understand what I was doing -- though I suppose that is a conceit of quantum computing. Perhaps I will retu…

Fundamentals don't change. Sure there's a new frontend framework every week but they're all just generating html.

It's often hard to tell what information is truly fundamental, and what will age badly. I look at many books of software engineering that were popular in the early 2000s, like The Pragmatic Programmer, Agile Software Development or the Design Patterns book by the gang of 4. Those books aren't taking about technologies that we expected to be superceded in 5 years. And yet, a lot of the text regarding object orientation and design patterns is outdated at best, and outright harmful at worst.

One can also look at, say, concurrency. A topic often seen as unimportant in the 90s, but ultimately taught at the lowest level, with mutexes, threads, semaphores and such. Those aren't going away, but how often is concurrent programming all about manually setting mutexes? We use higher order abstractions, but those change too. Many languages are encapsulating this in monads, whether people know their promise implementation is a monad or not. But that's not the only way, and the most popular way can change: Maybe languages in 10 years will be all about continuations and direct styles. Maybe it'll be something else. The fact that in the end, the same basic features from the 80s and 90s will exist at the bottom somewhere isn't that useful for most programmers.

And html generation... I was writing UIs before web apps were there. A lot of things that seemed fundamental went away when the browser was embraced. But will the browser live forever, or be superceded? I suspect that it will all get replaced, or be utter legacy, eventually. Will that eventually be 10 years? 30? It's very hard to say what will remain fundamental, and what will not.

Re: Teach Yourself Programming in Ten Years (1998)

#207

I bought a copy of "Sams Teach Yourself C++ in 24 Hours" at a CompUSA in 1999. The guy at the checkout looked at it, laughed, and told me about this article. When I was 16 I was looking at programming books at Borders and a guy handed me a copy of "The C Programming Language"; changed my life. So much of my career has been shaped by running into developers or just people interested in programming out in the world. Th…

>> I bought a copy of "Sams Teach Yourself C++ in 24 Hours" at a CompUSA Some of those books were laughably bad. But thing I miss from back then, was the feeling that the book was going to be the key to getting you started writing whatever crazy idea you had for a program in your head. I think the last time I had that feeling was walking out of Microcenter with a new MacBook and an iPod Touch, ready to make the next…

> But thing I miss from back then, was the feeling that the book was going to be the key to getting you started writing whatever crazy idea you had for a program in your head.

Yes! I miss it too. For me, that book was Head First PHP & MySQL[0] - Late 2000's, I was living and working in Thailand for a family friends small logistics company in the capacity of a BA, trying to move them into this century. We were trying to find a vendor for any system that would allow us to keep track of the movements of shipping containers within a container yard, and something sparked and I thought "hey, I did a semester of programming at Uni, how hard can it be?!", over the span of the next 6 months or so, this book helped me put together a solution that scarily, they are still using to this day.

Fast-forward 15ish years and here I am, still cutting code, although in the capacity of a dev lead, but after all that, I have the book to thank.

[0]https://www.oreilly.com/library/view/head-first-php/97805961...

Re: Teach Yourself Programming in Ten Years (1998)

#208

I bought a copy of "Sams Teach Yourself C++ in 24 Hours" at a CompUSA in 1999. The guy at the checkout looked at it, laughed, and told me about this article. When I was 16 I was looking at programming books at Borders and a guy handed me a copy of "The C Programming Language"; changed my life. So much of my career has been shaped by running into developers or just people interested in programming out in the world. Th…

One of the hills on which I am prepared to die on is that "The C Programming Language" is the best programming language book I've ever read. Every developer should read it and learn C at least once, even if they promptly forgot it all.

You’re not going to die on that hill. There are so many people that share your opinion that you might have trouble finding space, but you’re not going to die on that hill.

Re: Teach Yourself Programming in Ten Years (1998)

#209

I bought a copy of "Sams Teach Yourself C++ in 24 Hours" at a CompUSA in 1999. The guy at the checkout looked at it, laughed, and told me about this article. When I was 16 I was looking at programming books at Borders and a guy handed me a copy of "The C Programming Language"; changed my life. So much of my career has been shaped by running into developers or just people interested in programming out in the world. Th…

Still, I kind of feel like I want to print a fake “Teach yourself open-heart quadruple bypass surgery in 24 hours” sleeve and leave it on the shelf to see what happens.

Re: Teach Yourself Programming in Ten Years (1998)

#210
post #180

Earlier quoted context omitted.

>> It'd be like being a carpenter or mechanic but spending the majority of your time debugging, fixing, and communication with manufacturer's of broken or poorly working tools. What do you think a mechanic does ALL DAY? Very few carpenters start with a raw blank of nice wood and craft something amazing. It's all interpreting plans (poor spec), framing (boiler plate), figuring out an addition (bolting on features to a…

> What do you think a mechanic does ALL DAY? Are you implying that they are fixing their tools rather than cars? I don't know any mechanic that would put up with that and would replace their tools with tools that actually work.

Except mechanics tools are fairly simple devices based on thousands of years of standardization. I think probably a better example would be someone working in a lab on experimental devices. Software tooling is often absurdly complex and relatively new with no clear standard. In 100 years I’ll wager things are not like this.
Post reply on HN