Teach Yourself Programming in Ten Years (1998)
norvig.com
norvig.com
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 (ownership), Go (async done better, although i also really like core.async in clojure too), Python (trio nursery), C++ (asan, msan, tsan).
There's some blogs continually give me good food for thought in this space, all signal no noise:
Eli Bendersky, (every language under the sun) e.g. https://eli.thegreenplace.net/2016/the-expression-problem-an...
Fasterthanli.me (Go, Rust, others) e.g. https://fasterthanli.me/articles/so-you-want-to-live-reload-...
Mechanical Sympathy (Java), defunct but still worth visiting https://mechanical-sympathy.blogspot.com/
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
There is also Octave, an open-source Matlab alternative, but when I last used it (admittedly quite a while ago) it had limited support for toolboxes (e.g. signal processing). I imagine it has only improved since.
R?
I actually had one hectic weekend porting our whole departments MATLAB code over to Octave due to a hardware failure of our licensing server and some stonewalling from Mathworks, Octave is pretty close to fully MATLAB compatible.
It was transformational in a way my maths teacher was not...
I see a lot of conversation on here dedicated to whether you’d like your data with your functions (objects) or your functions with your data (closures). Rarely see array, logic or constraint programming paradigms mentioned.
FP has been rediscovered again and it’s the hotness right now but it’ll die out again like it did before OO stole its lunch, i can almost write the blog post headlines just now “arity considered harmful”, “OO and side-effect management not mutually exclusive after all!”
I’ve got a fiver on the next big one being a re-visit of structured programming.
God I hope so, probably the worst time I have teaching junior developers is helping those who have only used for-each write a loop with a useful invariant and not a garbage fire of breaks/continues.
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.
I’m sure the Linux kernel community is still using it, but FreeBSD even managed to remove it from the base system.
It’s still ubiquitous… “standard”?
If you're really going to learn a language - as in, build idiomatic programs - its a constantly moving target and requires a lot of effort to maintain.
I think it's better to learn 2-3 languages, and have passing familiarity with others. People like to pretend that language choice solves all your problems, but usually you're talking in percentages: one language is a 80% fit for your problem, another is an 85% fit... there is never a 100% fit - are these differences worth working in a language you barely have any experience in?
Same in reverse btw. Going from C++ to Python is probably easier than Python to C++, but it's still not going to be as easy as, let's say, java -> C# imo.
I guess in the context of your comment this sounds like bragging, but that's not my intent; I'm trying to rebut your comment, using myself as an example, because I think this level of polyglot programming is pretty close to normal, at least after you've been at this stuff for a few decades. Maybe if you're getting into a rut of only knowing 2–3 languages well, you'd benefit from putting more effort into exploration. Unless you're about to stop programming, in which case you won't have time to take advantage of your newfound powers.
I don't think percentages are a good way to think about language fit. I think it's more like an effort multiplier. In theory I can solve any programming problem in C, but when the problem isn't huge and performance isn't much of a challenge, I can usually solve it about with about a tenth of the effort in Python. There are problems where solving them in SQL is about three times easier than in Python, and problems which can barely be solved in SQL, so solving them in Python is about a hundred times easier.
As an example, in my experience it's pretty common for Python to be about half as much effort as Scheme, but there are much better Scheme implementations out there, so when performance is a challenge, solving them in Scheme can be a hundred times easier than solving them in Python. But if you know Scheme and not Python, you can often get twice as much done by learning Python, even for problems where you might say Scheme is a pretty good fit. But it's true that at the beginning, when you have barely any experience in Python, you won't be faster; you'll be slower. And you won't know if that will ever change.
Most commonly, though, people use the language that is best integrated with their chosen platform, because that saves them the effort of writing a bunch of integration code in addition to the actual application code. If you're writing DHTML, for example, use JS, not C. If you need to invoke JVM libraries, reasonable options include Python, JS, Kotlin, Clojure, and Java, but not Perl, C, or C#. If you're writing a Minetest mod, do it in Lua.
So, if you only have more than passing familiarity with 2–3 languages, I think you're going to frequently run into cases where that ignorance costs you a factor of 2 or 3 in effort.
I certainly agree, though, that choosing the right language won't solve all your problems, and it's easy to have exaggerated hopes for it.
You don’t necessarily need a separate language for each domain.
Related: MSAN is made so much better by -fsanitize-memory-track-origins. I can't count how many times MSAN caught an error, and with that flag enabled, it directly pointed to the exact line of code at fault.
Since I enjoy high level programming and the natural experience chicken/egg I never do the low level stuff. Not since Acorn Electron assembler! But I know of it.
EDIT: Do you mean that it lacks certain features without a runtime like Node or the browser? For instance, it doesn't have a language construct for opening files like Python or Ruby. If so, I don't think that's a good argument.
I can't find a domain where JS wouldn't fit the description. While it may be a bad fit for certain problems, it can still be done.
I’m sure I could come up with more. JavaScript is a tool, just like c, go, rust, python, lisps, etc. I’m going to give you the benefit of the doubt and hope you just didn’t consider all of these other domains when you made this comment.
Cheers!
For example: Espruino is a platform for embedded JavaScript.
I just think about it this way: Just because you wouldn't doesn't mean you couldn't
I wonder how much of the horizontal scaling trend is driven by JavaScript's horrible threading story.
The former is a general purpose programing language that favors prototypical object oriented programing paradigm but supports multiple other paradigms such as imperative and functional.
The latter uses the JavaScript language and adds on a bunch of specific APIs (such as the DOM) for specific purposes. This includes APIs for DOM manipulation, playing audio, validating inputs, parsing forms, handling key presses, etc.
In 1998 languages did not have that many features and were in my opinion easier to grasp. Just have a look at modern C++ or Java's cadence of new features.
In 1998 Java and JavaScript were new. Now they evolved into widely adopted general purpose languages.
Your comment reminds me how much i miss dr dobbs journal. I learned so much on those pages.
I started using C/C++ more than 20 years ago and even if I feel really comfortable with the language (except the latest revisions) I am still learning and improving.
I don't think I could achieve the same level of mastery on half a dozen languages.
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 long until I become employable," not "how long until I become an expert".
The answer to the former is months of deliberate practice. The answer to the latter is [tens of] years of deliberate practice.
Books with titles like "learn C++ in 24 hours" target the former. 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 an architect who knows just enough to complete the job and does not care a bit for more?
It does not take mastery to write one-off scripts that "get the job done". However, they will probably not be a general purpose solution of the problem at hand, ignore corner cases, contain bugs… and the real test comes when requirements inevitably change.
If you want to write dependable, high-quality, maintainable, reusable software you better know more than the bare minimum.
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.
1)
Everyone needs to pump out all of their bad code before they get to their decent code. Imagine your lifetime array of code, it will look like this [bad, bad, ...(lots of bad), bad, good, bad, good, good, ...(lots of good), good]. As you can see, you’ll have to pop (poop) all the bad out before you get to good. Some people have a smaller length array due to other factors (talent), but even so, there is bad in front of the array.
What are the implications of this? That should be obvious. This industry hires people straight out of college or people in their mid 20s to be project leads. You do the math.
2)
Lack of suffering. Many people haven’t had to toil in someone else’s codebase. Many people are given green-field projects that are scrapped quickly, at which point the business (or another business) gives a brand new project. Constantly building shit from scratch by yourself means you don’t understand pain. Go work in someone else’s garbage app to feel pain. Then you will rethink what good code is. Good code is not painful, and the definition of ‘not painful’ will be obvious to the survivors of pain.
Solution:
Continue to crap out your bad code in non impactful areas of the codebase and avoid crapping in critical parts. You have to crap somewhere, and that is understandable. Lastly, don’t turn down the experience of working in someone else’s labyrinth. The experience is valuable.
We aim for fast MVPs, fast iterations, "failing fast", "moving fast", "delivering value quickly", generally preferring speed over quality, agility over "waterfall" planning, continuous delivery over batched releases and, well, often accruing tech debt over shipping features later.
One can argue that "fail fast" should not be about code & feature quality but rather about determining proper scope, splitting features sensibly etc. But then we still have deadlines to meet and code quality suffers.
What I'm saying that this kind of fast-moving environment actively discourages traditional (like doctors & civil engineers) engineering practices.
You might have lots of (unit|integration|E2E) tests but the company may miss practices like proper security reviews and code won't be reviewed, tested and approved by multiple people like, say, bridge building plans are.
This problem mostly comes up not with your usual web app but when critical systems are affected (like in the aerospace industry or industrial systems). But through supply chain attacks, nearly any system can be vulnerable these days.
We should definitely have better regulation on how software is made.
But iterative development and fail-fast are independent of quality. If a company skips security reviews and is fine with technical debt because "it works, just ship it", what makes you think they would do security reviews or care about better-than-minimum code quality when following a waterfall system
Stop equating programming and bus drivers or waiters. They aren't equal. Programming is difficult in its depth and breadth in a way that waiting tables is not.
Stop treating all programming tasks as equal. They are not. Most of the easy ones are only easy because they run on top of all the difficult programs. That is the goal of the difficult programs, to make it possible for laymen to do work that would require an expert for certain repetitive tasks if the underlying program did not exist.
Most people would not be capable of getting Hello World to run without the OS and high-level abstractions that take expertise to develop. And making that possible requires many many experts in many different kinds of programming.
Stepping off of the single thread and single machine model into concurrent and distributed computing to enable even more laymen to make stuff takes even more experts.
There is a meme in the industry that people shouldn't strive for expertise. We still need more experts, and you become an expert through practice while still a layman. Nothing would be worse off if we had more experts capable of deciding when to use something extensible off of the shelf to enable laymen to do simple tasks, and when to build a platform to eventually enable that task to be done by a layman.
A lot of things would be worse off if we encouraged all people to stop at the layman level. We should encourage everyone to at least become a layman for their own enrichment. But we should also encourage laymen to strive for expertise to lower the barriers to entry to produce more laymen capable of doing simple tasks.
Also there are some great thoughts in this thread on why there is such a shocking amount of spaghetti code out there and I like the ransomware note also. Thought provoking. Too bad I'm such a terrible programmer.
No, it’s not. Changing requirements by adding features is by far the biggest cause of badly designed and buggy software. I’ve worked on multiple teams where everyone was fully committed and highly skilled, and it didn’t magically fix the problems of software. It wasn’t any better than working on teams of people who were less interested. Our inability to stop adding features is what kills us, and this inability is actually stronger with people who think they’ve ‘mastered’ the art of programming than with people who can finish a one-off task.
> they will probably not be a general purpose solution of the problem at hand
Ironically, perhaps, in my decades of professional programming, the number one biggest waste of money I’ve seen is people over-engineering something under the banner of making something “general purpose” that didn’t need to be. I’ve watched a couple of different teams of very smart people waste literally tens of millions of dollars by deciding to rewrite something that didn’t need rewriting, and dramatically overestimate their ability to finish it in a reasonable amount of time and avoid the same mistakes they made the first time.
> If you want to write dependable, high-quality, maintainable, reusable software you better know more than the bare minimum.
This sounds good in theory, but is specious. The real way to get high quality software is to define what that means and stick to it ruthlessly. You don’t need to know a lot about programming. You need a management that is okay lengthening schedules to make room for testing. You need a CEO who is okay with saying no to customer demands for features that the competition has. You need programmers who know when to stop programming and when to avoid rationalizing their ‘general purpose’ solution that solves problems that don’t actually exist.
Good luck in your search for high quality software, it’s very very difficult to find a team who can commit to it, and there are good reasons why: it’s extremely expensive.
You nailed it exactly. High quality engineering requires costly business practices that most companies don’t need, so the tradeoff is easy to decide. This is why organizations that do high quality engineering are well funded and are very restrictive about what kinds of programming features are allowed. NASA published a famous essay about how to write safety critical code that disallows use of dynamic memory allocation. https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...
Or any of those things you mention? I normally just trust that the bus company has hired a guy with a license.
How often are you driven around by bus drivers who just finished their learner's permit?
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.
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 mindlessly repeating same things they are becoming experts at mindlessly repeating same things.
That's a great way to explain it. Totally stealing that!
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.
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".
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.
Not sure about this though:
> I would say that the number of jobs that require the mastery of the craft is not large.
Perhaps the number of jobs that require mastery is less well known? i.e. Not advertised as often / not vacant as often.
I suppose I'm splitting hairs here in one's definition of "not large", by in my circles (~25 years of dev working experience) there are quite a lot of "jobs" requiring mastery, but they certainly do become available less often (or rather, they're usually quietly filled without much public notice).
The job market has to roughly follow this demographic trend, otherwise companies would fall behind competitors.
[1] https://insights.stackoverflow.com/survey/2020#developer-pro...
The rub is that this all depends on what you find personally rewarding. If what leads to a rewarding life to you is having a good job, then absolutely, you probably don't need more than a certain amount of depth and knowledge on the subject.
But if depth and knowledge on the subject is what you find personally rewarding, then suddenly putting in all this work makes sense. For many, lifelong learning is what is most rewarding and brings most joy, which one might argue is the most important thing as long as you have a sufficient income.
If you do want to frame it in terms of achievement, it's also obvious that many prolific people in their fields were driven by a passion for what they do — the playful nature of Feynman, Shannon and others comes to mind.
I've been programming for a lot more than 10 years, and would barely call myself an expert on anything. 10 years is a decent amount of time to learn to be a decent programmer. As a rule of thumb at least.
When asked by others how much it would take, I try to avoid giving a number like that because it might discourage them. Who knows, had I heard or read that number early in my involvement, it might have discouraged me. However, my innate curiosity and fascination for the field made the time fly by without me noticing it. If you're in doubt, you might take that as encouragement. Programming is a field where the learning never stops, and if that's your thing, the time required will become secondary at most.
You can have a well paying job as a programmer in only a few years.
Yep, that's why I put the “~” in front of it and called it a start, not the end of the journey.
> You can have a well paying job as a programmer in only a few years.
Absolutely, if that's the extent of what you want out of it, you could achieve that and call it a day. But programming is also a field that's ever evolving. If you catch yourself thinking, “I've learned everything I ever need to learn”, then chances are that you'll find yourself left behind at some point in the future.
At the same time, I often find it dispiriting to hear "it takes x amount of time", be that 10 years, 10,000 hours or a lifetime.
While I understand that it is important to have these metrics precisely to dispel the idea that anyone can learn c++ in any meaningful way in 24h, at the same time I find it harder to start something when I am constantly reminded of the fact that nothing I produce will be worth anything compared to those with a giant head start (yes, yes, never compare yourself to others, just to yourself from x time ago).
The 10 year thing means I can meaningfully learn, what, 70 thing in life if I am not spending the vast majority of my time at a full time job? So, that makes it 3-4 things?
How depressing.
Admittedly, I feel I have almost never studied deliberately. I happen to have learned about 3 things to reasonable expertise in my 30 ish years. All three just happened. It was effortless to learn, as it was interesting to learn.
I simply cannot imagine what it would mean to have to dedicate 10 years or 10,000 hours of practice to something I am not interested in. In my own experience I would go so far as to say that I either love something enough to want to do it 8h a day, or not at all.
I wonder if I'll ever find a 4th thing, later in life. I really want to learn more things, but the rule of x hours is discouraging to think about when I have 30 something years less left on this planet than when I started.
Your own struggle with learning new things does have some openings to look at it a bit lighter. Most things are already useful, fun, interesting with less than 10k hours. Way less. You don't need to be an expert to enrich your life and that of others with a new skill!
In addition, learning related things goes much quicker (ie I enjoy doing CAD recently using Fusion 360 and I find that many aspects of it fit my programmer mind very well, same for expanding foreigbln languages, different instruments, etc).
It would take me 10,000 hours to become a proficient Programmer.
Now---stuff I am truly interested in took me less time to learn. I was going to say "master", but I didn't master anything in my life. I'm a good mechanic, and Watchmaker only because learning it was easy because I was interested.
It took me less than 4 years to become good at Watchmaking. Why--because for some reason I became facinated with watches, and clocks.
I can strum exactly 12 guitar chords. I memorized the charts, and then memorized the finger positions on the fret. I can play a few songs. I sometimes wonder why I don't practice more. The reason is I don't love it. When playing a mental picture of Blutto pops up from Animal House.
Pick something you love. You never know where it will take you. Then again--maybe I should have learned things that society valued, and paid highly for?
Programming is like life, constant learning, constant mistakes, constant improvements. And that's why it's so beautiful.
A life long partner ^^
The other guy didn't write a line of code until he was 21, after switching majors from econ to engineering - three years later, he was getting offers from FAANG companies and quant/hedge funds.
But, I do think that if people consistently work and study programming for 10 years, then most will have a solid grasp afterwards. That means doing actual constructive work almost every day, for 10 years - doing work that either challenges you, or teaches you how to use the tools.
Being an expert (or highly competent) programmer is not only about knowing CS-theory at heart, and being able to translate that into working code - it's also being fluid with the tools. And, luckily, becoming good with tools doesn't take much more than time and effort.
You could be the worst programmer in the world, but given enough time, you could learn every nook and cranny of some language and its ecosystem.
You could learn the basics of football in an afternoon or spend a solid few years getting good. If you started playing futsal, you'd do ok. Maybe you could hold your own as a sprinter. You'd probably have a terrible time with a javelin.
In the same way, programming experience in one area transfers to others but not completely.
Writing code for 40+ years I still make mistakes, don't know a lot of things, make the wrong decisions sometimes and learn every day - currently fighting Rust lifetimes.
(note: is comic)
I used the Learn C++ in 24 Hours book as an undergraduate. It was excellent. It was the book the university recommended, and it was probably the only book I bought as an undergraduate engineer that was actually indispensable. I actually used it, page by page, and during that course I produced a really cool 'moon lander' game in 3D. Was I an accomplished programmer? Absolutely not. Had I learned the basics? Yeh. Good enough for an undergrad electrical engineer.
It feels like you are railing against one premise (a programming language can be learned in 24 Hours) only to propose another similarly bonkers premise (a programming language can't be learned in less than 10 years). What's the point?
That's what stupid people do.
When smart people need to solve a problem, they find a system, they make time to work long and hard, and they keep on going, each and every day, failing often failing fast, and then, little by little, they incorporate the new knowledge, understanding and experience into their life.
2-3 years often gives good skills borderline mastery, 3-10 true mastery.
It's a system, not a goal.
So while it is 24 hours or 7 days or whatever, they are not meant to be a sequential 24 hours, but 24 hours spread over a period of time.
I could never interest a publisher in creating a series called "Learn in 23 Hours", I'm sure it would have a clear advantage over its slower 24 hour competition. Perhaps 23.99 hours?
Made the switch to software and am now a senior software engineer. Didn’t know then that I would somewhat follow the trajectory outlined here.
How did Norvig interview JWZ?
Did he use the whiteboarding rituals promoted by Norvig's company?
I don't remember a lot about my interview around then, but one bit that stuck: when he outlined some problem he had at the time, and I was like "maybe bayesian networks would be good for this", I felt rather silly saying so since it'd been his book where I learned about bayesian networks.