Live data from Hacker News

Teach Yourself Programming in Ten Years (1998)

norvig.com

41–50 of 117 posts

Re: Teach Yourself Programming in Ten Years (1998)

#41
post #20

The title is a bit misleading to me. 10 years is not to "teach yourself programming," it's to "become an expert in programming." Most people do not want to learn programming to become experts, most people want to learn programming to get a job. After getting a job, some will plateau right away, others will plateau after some time, and others still will keep learning even after years and years. The problem is "how lon…

> the number of jobs that require the mastery of the craft is not large The number of jobs that benefit from mastery of the craft is essentially equal to the number of jobs. I do not enjoy finding the work of a bunch of people that studied enough to get hired and no more.

> The number of jobs that benefit from mastery of the craft is essentially equal to the number of jobs.

I think this is true. Nobody disputes that.

Imagine you'd hire Torvalds to debug and fix why your Wordpress does not work. I truly think he'd do an excellent job figuring out that AWS has a firewall that's blocking the connection from your WP node to your MySQL node...

Somehow, the example above feels bizarre and yet these are the types of issues a lot of architects, consultants, and other highly-paid job positions deal with on a daily basis.

> I do not enjoy finding the work of a bunch of people that studied enough to get hired and no more.

This sentence makes no sense to me. I'd say you "find the work of people that studied enough to get hired and no more" possibly just slightly more often as you "find work of people who never wrote anything public until they mastered everything they could, from building computers from NAND gates up to AI/ML".

Re: Teach Yourself Programming in Ten Years (1998)

#42

>> Learn at least a half dozen programming languages I'm always surprised by how many people disagree with this; they're on the search for that one language they can use for every task. Or even worse, they think they've found it and their search is over, that's a tragic situation given how spoiled we are for great languages today. Clojure (STM / refs, vars, atoms & agents), kdb/q (non-loopy array code), Rust (ownersh…

Even more important than different languages is to learn about different execution models. For instance, the difference between Java and C++ is relatively minor from that perspective, compared to (e.g.) understanding how Prolog works. That will open entirely new horizons if your previous experience was based on C(++)/Java(Script)/Python (just to mention a few of the usual suspects). Just look at how the addition of FP features to “OOP” languages considerably widened the field of possibilities.

Re: Teach Yourself Programming in Ten Years (1998)

#43

>> Learn at least a half dozen programming languages I'm always surprised by how many people disagree with this; they're on the search for that one language they can use for every task. Or even worse, they think they've found it and their search is over, that's a tragic situation given how spoiled we are for great languages today. Clojure (STM / refs, vars, atoms & agents), kdb/q (non-loopy array code), Rust (ownersh…

I’m surprised you don’t mention Perl in this list. It’s the de facto Unix scripting language and frankly more suitable to the task than others.

Perl on the command line is beautifully concise; it’s easily embedded into CI/CD pipelines because the q, qq, etc escaped quotes; it has best-in-class regex support; calling external utilities equally concise with qx or back-ticks; etc etc.

Personally I tend to favor C/C++ for the main event and Perl for everything else on the systems side.

JavaScript is obviously ubiquitous on the front-end but it feels very clumsy. Not a huge fan of that on the back-end system it’s just too weird to do simple stuff like “parse a file” or “rip through a directory tree” or call a shell command.

Re: Teach Yourself Programming in Ten Years (1998)

#44
post #39

Earlier quoted context omitted.

> And, I would say that the number of jobs that require the mastery of the craft is not large. This mindset is how we end up with layers upon layers of badly designed and buggy software that underpins almost every aspect of modern life. Just apply the same reasoning to other areas: Would you want to drive in a bus with a bus driver who just barely got his driver's license? Would you want to use a bridge designed by a…

not all code is life threatening in worst case scenario. Better comparison would be "would you like to be served by first time waiter or rather expert one?". In most cases it doesn't matter, and when it does, the price point of the service is significantly higher.

This is mostly just a rant not directed at you but on the state of software...

The Colonial Pipeline ransomware wasn't life threatening. These things happen because of bad* developers and zero accountability from developers over publishers to software owners. As it is now pretty much all commercial software is "first time waiter" quality. Granted it isn't all on the actual developers but on the whole pipeline(!). Most software is on the "let's use an anchor to stop our newly developed car because we have used anchors for decades and understand them better than drum brakes" level of quality.

* Bad code because of a lack of understanding and/or time constraints. But developers don't mind coding bad code (not enough to refuse at least). Developers need to be more like doctors and engineers. Accountability and proven skill matters and would force managements hand like at hospitals and building projects.

Re: Teach Yourself Programming in Ten Years (1998)

#45

The title is a bit misleading to me. 10 years is not to "teach yourself programming," it's to "become an expert in programming." Most people do not want to learn programming to become experts, most people want to learn programming to get a job. After getting a job, some will plateau right away, others will plateau after some time, and others still will keep learning even after years and years. The problem is "how lon…

I don't think the title is misleading, it's deliberately placing itself in contrast to the glut of content that is already out there geared towards people who want to become programmers as fast as possible to get a job. Programming may be a job, but it's also a craft, and I'm happy to see content in that direction.

Also as someone who has had to hire a team of programmers in the last 18 months, it's clear there's an industry of snake-oil salesmen willing to promise to teach you to be employable in 3 months or less, and they're not benefitting the industry in need of good programmers, or the people paying them thousands of dollars in hopes of improving their employment prospects.

A 4 year degree is not necessary to become an employable programmer, but imho what we need more of are 2-year programs which properly teach the fundamentals of computer science alongside practical skills, not 6 week or 3 month bootcamps which only teach the bare minimum.

Re: Teach Yourself Programming in Ten Years (1998)

#46
post #40

The title is a bit misleading to me. 10 years is not to "teach yourself programming," it's to "become an expert in programming." Most people do not want to learn programming to become experts, most people want to learn programming to get a job. After getting a job, some will plateau right away, others will plateau after some time, and others still will keep learning even after years and years. The problem is "how lon…

> Most people do not want to learn programming to become experts, most people want to learn programming to get a job. No, I think it is little bit different. "Most people think they will get a job and then will become experts after some time of performing the job" And they are right. But they are mistaken what kind of expert they become -- they are becoming experts at what they are doing which means, if they are mind…

>they are becoming experts at what they are doing which means, if they are mindlessly repeating same things they are becoming experts at mindlessly repeating same things.

That's a great way to explain it. Totally stealing that!

Re: Teach Yourself Programming in Ten Years (1998)

#47

The title is a bit misleading to me. 10 years is not to "teach yourself programming," it's to "become an expert in programming." Most people do not want to learn programming to become experts, most people want to learn programming to get a job. After getting a job, some will plateau right away, others will plateau after some time, and others still will keep learning even after years and years. The problem is "how lon…

> And, I would say that the number of jobs that require the mastery of the craft is not large. This mindset is how we end up with layers upon layers of badly designed and buggy software that underpins almost every aspect of modern life. Just apply the same reasoning to other areas: Would you want to drive in a bus with a bus driver who just barely got his driver's license? Would you want to use a bridge designed by a…

> Just apply the same reasoning to other areas: Would you want to drive in a bus with a bus driver who just barely got his driver's license? Would you want to use a bridge designed by an architect who knows just enough to complete the job and does not care a bit for more?

I don't think this part is useful. If you're writing directly code for an application you don't usually need to be the best, and your errors can be handled by layers of supervision/QA. If you're writing internal libraries and tools, you need to be a better programmer. If you're in one of the let's say Rust compiler groups, you will need to really know your stuff. But even the Rust compiler has issues for newcommers that aren't too hard.

I don't think comparing software engineering to bus drivers and bridge architects leads to useful insight. I do agree with the rest of your post though. A part of my day job is to develop and maintain applications made by people that didn't/couldn't program "properly" (shadow IT). Everything more or less work and the end users are satisfied, but I often fear that one day something will depend on one of those applications. On the other hand taking the time to do everything "properly" would lead to a lot less experimentations and/or use a lot more resources. It's hard to find a good balance.

Re: Teach Yourself Programming in Ten Years (1998)

#48

>> Learn at least a half dozen programming languages I'm always surprised by how many people disagree with this; they're on the search for that one language they can use for every task. Or even worse, they think they've found it and their search is over, that's a tragic situation given how spoiled we are for great languages today. Clojure (STM / refs, vars, atoms & agents), kdb/q (non-loopy array code), Rust (ownersh…

I was one of those who disagreed with that, but then I was forced to learn several new languages for work. Now I agree with it wholeheartedly.

my favs:

-clojure for processing deeply nested data

-rust for general stuff

-java for concurrency support and general stuff

-c for easy pointer manipulation and "tricks"

-sql

-bash for scripting (I'm that weirdo who would rather make a huge shell script rather than using python)

I still need to find something good for arrays/ matrices. MATLAB was kinda fun I can't see it being used in production in anger too easily

Re: Teach Yourself Programming in Ten Years (1998)

#49
post #48

>> Learn at least a half dozen programming languages I'm always surprised by how many people disagree with this; they're on the search for that one language they can use for every task. Or even worse, they think they've found it and their search is over, that's a tragic situation given how spoiled we are for great languages today. Clojure (STM / refs, vars, atoms & agents), kdb/q (non-loopy array code), Rust (ownersh…

I was one of those who disagreed with that, but then I was forced to learn several new languages for work. Now I agree with it wholeheartedly. my favs: -clojure for processing deeply nested data -rust for general stuff -java for concurrency support and general stuff -c for easy pointer manipulation and "tricks" -sql -bash for scripting (I'm that weirdo who would rather make a huge shell script rather than using pytho…

Careful with Bash... https://mywiki.wooledge.org/BashPitfalls
Post reply on HN