Live data from Hacker News

Teach Yourself Programming in Ten Years (1998)

norvig.com

81–90 of 323 posts

Re: Teach Yourself Programming in Ten Years (1998)

#82

Earlier quoted context omitted.

It depends. I've been coding for a living for 41 years and have a feeling I'll get the hang of it real soon now.

[flagged]

It is possible you are not cut out for sarcasm?

(Giving you the benefit of the doubt you may have taken the comment literally, if so I'd maybe apologize for insulting someone with 41 years of experience in a field that is still young whilst having no knowledge of exactly who you are talking to)

Re: Teach Yourself Programming in Ten Years (1998)

#83
16 years' worth of threads:

(edit: Reposts are fine after a year or so; links to past threads are just to satisfy extra-curious readers)

Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=33287618 - Oct 2022 (112 comments)

Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=27411276 - June 2021 (115 comments)

Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=20543495 - July 2019 (87 comments)

Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=16574248 - March 2018 (51 comments)

Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=9395284 - April 2015 (61 comments)

Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=5519158 - April 2013 (86 comments)

Teach Yourself Programming in Ten Years by Peter Norvig (2001) - https://news.ycombinator.com/item?id=3439772 - Jan 2012 (29 comments)

Teach Yourself Programming in 10 Years. - https://news.ycombinator.com/item?id=1060176 - Jan 2010 (32 comments)

Teach Yourself Programming in Ten Years - https://news.ycombinator.com/item?id=191235 - May 2008 (19 comments)

Norvig: Teach Yourself Programming in Ten Years - https://news.ycombinator.com/item?id=43243 - Aug 2007 (7 comments)

Re: Teach Yourself Programming in Ten Years (1998)

#84
post #28

> The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again. I think this is the really important part, you have to challenge yourself and go outside of your comfort zones to keep learning.

This is true, but I think it's better put this way: The key is making it a hobby. Expertise comes with experience and experience will only come if you keep coming back . Some people can force themselves to toil endlessly, but here's some wisdom for mere mortals: start by searching for a part of software that you can truly love, then cultivate it.

It is also a good idea to place the hobby part of programming in a related but not same field/tech stack than you day job.

If you simply do more work in your free time you might burn out. You want something that provides relaxation but still synergy effects with your day job.

Re: Teach Yourself Programming in Ten Years (1998)

#85
post #28

> The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again. I think this is the really important part, you have to challenge yourself and go outside of your comfort zones to keep learning.

Absolutely, but I need a teacher for that

Do you need a person teaching you directly? Then you need a mentor (to guide you) or to go back to school.

If you just need someone to have done the legwork and established the exercises and presentation of material for you, there are a myriad of options: books, blogs, videos, open courses, paid courses, etc.

The trick I've found to mastering a field without having a teacher standing over me and guiding me (and even when I have a teacher) is to learn to construct my own courses and exercises. These are "synthetic". I look at multiple university courses on a topic and grab one or more books, and then work through them in an order that fits my way of learning. If they have a lot of exercises, I do them. If they don't or their exercises are poor (happens), I have learned (over the years) to construct my own exercises.

A major lesson from years of doing this is that there are no perfect teachers, courses, books, or other resources that will, on their own, teach me a topic to mastery. I have to assemble it myself to fit my way of learning and needs as a learner. That part requires introspection along with trial and error. I attempted courses and books that taught me nothing (or barely anything). After a bit of floundering with that, I took a step back and figured out what resources were effective and ineffective for me, what they had in common or were missing, and started assembling my own "courses".

That's a very useful skill to develop, and it transcends disciplines. Even if you do have an actual teacher with you this is still helpful (perhaps even essential) to be able to go beyond what they're teaching you and to cover over their weaknesses as a teacher (either general weaknesses or weaknesses with respect to you).

Re: Teach Yourself Programming in Ten Years (1998)

#86
post #28

> The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again. I think this is the really important part, you have to challenge yourself and go outside of your comfort zones to keep learning.

[deleted]

Re: Teach Yourself Programming in Ten Years (1998)

#88
Peter is a gem who really seems to understand the structure of reality slightly better than just about anybody, and is a nice person to boot.

I guess I spontaneously picked up on the 'challenge yourself a little, improve, repeat' strategy a long time ago. I often implement things over decade or more, through a series of small increments. I also decompose many problems recursively and use a sort of A* approach to make progress, sometimes revelling in some detail for months or more at a time before solving it, then backing up the stack to the larger problem I was working on.

For example, I'm building an automated microscope. I work with folks who buy $1M scopes just to speed up their science. I don't want a $1M scope- I want a $1K scope that does 30% of what the $1M scope does. To do this, i've learned how to design and 3d print components, integrate motors, controller boards, etc. Eventually I reached a point where improving the illuminator (the LED light that provides the light to the sample, which is then picked up by the camera) was the most important step and so I took a deep dive into LEDs, and the electronics required to support them.

This has meant putting the scope down and instead creating a series of designs for PCBs that incorporate increasingly sophisticated electronics and higher power LEDs. I set a challenge for myself that is beyond my ability: design and have manufactured, a working constant current driver and assemble the PCB myself using surface mount components. When I started, I knew nothing about constant current, or SMD, or designing PCBs. I started with the simplest possible designs- copying a reference design for ac ontroller, cloning a board I already have, incorporating low-power LEDs onto a board. Each step along the way, adding something slightly more challenging.

When I do this I fail a lot. Some days I get a PCB made to my design after a week of waiting (JLCPCB is AMAZING) and within 5 minutes realize I made a fundamental mistake. Other times, a board works perfectly and I "level up": I can now take everything I learned in the process, and use it to pick up the next challenge. Sometimes I get frustrated and depressed- not being able to figure out something that should be straightforward, and then I either rubber duck it, or ask a simple/stupid question on reddit, which typically unblocks me.

Today, I expect to receive my next constant current board design. If I assemble that and it works, I can then proceed to building a board to host a high power LED. That will introduce all sorts of new problems (heat management) that involve going into Kicad, thinking about stuff, making some experiments, sending a design to JLCPCB, waiting a week, and then assembling a bunch of boards, most of which will burn out (high power LEDs are tricky, if they got hot they fail faster). There's an opportuntity to buy some thermistors (little temperature measuring devices) and put them on the board to see how well my design for heat spreading it.

At the end of all this, I'll have a world-class transmission light microscope that can track tardigrades for hours at a time (itself an enjoyable delve into modern computer vision techniques), and I've talked to the world's leading tardigrade researcher, who wants to incorporate my ideas into his research to make tardigrades a model organism.

By the way, if I had stayed in academia, I would NEVER had the time, money, or energy to pursue this; I'd be stuck working on my funded research. NOBODY wants to give me money to design scopes that are roughly where state of the art was in the 1970s. But if I keep this up, in a few years I'll be ready to go play with the big boys and girls in the robot biotechnology labs with their $1M toys.

Bringing this back to Peter, I had the chance to work with him on a project (attempting to disprove the Beal conjecture by finding a counterexample). He did all the brilliant math and we wasted a bunch of CPU (and I mean A BUNCH) trying to find counterexamples. I like how when he wrote https://norvig.com/beal.html he wrote in the nicest possible way that I was wasting time and energy.

Re: Teach Yourself Programming in Ten Years (1998)

#89
post #83

16 years' worth of threads: (edit: Reposts are fine after a year or so; links to past threads are just to satisfy extra-curious readers) Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=33287618 - Oct 2022 (112 comments) Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=27411276 - June 2021 (115 comments) Teach Yourself Programming in Ten Years…

If only there was a way to let poster know about past threads before posting...

Re: Teach Yourself Programming in Ten Years (1998)

#90
post #83

16 years' worth of threads: (edit: Reposts are fine after a year or so; links to past threads are just to satisfy extra-curious readers) Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=33287618 - Oct 2022 (112 comments) Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=27411276 - June 2021 (115 comments) Teach Yourself Programming in Ten Years…

I am not sure if this is criticism for too many reposts or if once a year is considered a healthy dose of dupes.
Post reply on HN