Live data from Hacker News

Teach yourself programming in ten years (1998)

norvig.com

81–90 of 142 posts

Re: Teach yourself programming in ten years (1998)

#81

One of may favorite things to do was to spend some time tinkering around to learn a new programming language. I collected quite a few and it was fun to learn new paradigms and how to organize programs. But now since AI… idk I just can’t do it, it seems just completely useless in the age of AI. Like getting better at the technical aspects of programming just doesn’t feel important anymore. I don’t think I’ll ever be a…

Same here. FWIW, you can still absolutely do it, just like you can weave your own fabric. You probably won't be able to monetize it though, as it won't give you as much edge in the workspace anymore. It's just a thing to do in your spare time.

Not sure if it helps with the feeling of futility or not. For me, it doesn't really help that much because ultimately I want the skills and knowledge I gathered to benefit me in some way. For example, previously I would be able to better understand computers and software, be an "overall better" programmer, better thinker (in terms of computation). If the results you get are not used in any way, it's on the same level as memorizing rule sets for some obscure game that no one knows or cares about.

Maybe pivoting to something else like philosophy could make sense as a hobby.

Of course, there's always going to be some demand for knowing computers, knowing programming languages first-hand, etc. Writing or auditing code for critical systems. Teaching the next generations of people that will do critical systems. Some people are optimistic in that they are going to fall into that demand. I'm not optimistic about myself.

Re: Teach yourself programming in ten years (1998)

#82
post #32
post #20

Earlier quoted context omitted.

Did AI take it away, or did you give it away? Now that you've made the Faustian bargain at this low low introductory price, how long until they start ratcheting up the price? How long will you be able to bear it? You're still allowed to do things the old fashioned way you know. Given the rapid skill degradation that results from LLM-driven coding usage, I'd recommend it if you want to retain any skill at all.

> You're still allowed to do things the old fashioned way you know. Not if your company decides to be "AI-first" and puts agent use on your job results.

Ditch that company maybe?

Have some agency in your life. Sometimes people here write stuff as if being in control of their lifes is unthinkable.

Re: Teach yourself programming in ten years (1998)

#83
post #56

Earlier quoted context omitted.

What most miss today is DX - Developer Experience, many (most?) devs don't want to become Prompt Engineers. Another thing is that not many can afford Fable or similar and I don't think prices will go down, since it is already heavily subsidized?

I've always spent 90% of my work time thinking and sketching what the architecture should be to solve a problem. I find that once I've worked that out, it's actually still faster for me to code it than to try to explain it and refine it in prompts. And the code ends up more succinct and covers the edge cases I've already considered. If I need a fast script to do one thing, or unit tests, sure an LLM is faster at writ…

Exactly. At my previous work we spent an awful amount of time planning and architecting the solutions and refining them. No matter the person who prompted or the model used, the solution was never close to satisfactory.

Layers of unnecessary abstraction, weird decisions (like wth it used triple pointers once) hard to debug issues and obvious race conditions. Segfaults are through the roof and people are burned out and gasping hard to solve the bugs. I called their attention to this at the time and I was ignored and a bit laughed about. I left and couple months later I know others are too.

Re: Teach yourself programming in ten years (1998)

#85
post #21

It'd be embarrassing if you have to spend $10 in AI tokens for it to fix one line that you could have fixed quicker yourself for free. Not sure if the savings add up enough to offset the investment in learning to program.

I worked with mid level devs that would write 5 lines of code (literally) and run it through an llm for validation, so yeah they were spending tokens like crazy. They end up being more expensive to the company with no added benefit

Re: Teach yourself programming in ten years (1998)

#89
post #55

Why is this marked as 1998 when it references Khan Academy and Go, among other things?

I see a reference to Khan Academy, but not Go?

> Learn at least a half dozen programming languages. Include one language that emphasizes class abstractions (like Java or C++), one that emphasizes functional abstraction (like Lisp or ML or Haskell), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), and one that emphasizes parallelism (like Clojure or Go).

Re: Teach yourself programming in ten years (1998)

#90
Hm since the discourse is mostly on how AI changes this, I still want to make a point that it's worth learning programming (and more), even if I'm a huge proponent of AI being economically valuable.

Humans at the moment are still better at building on our own knowledge and compounding our effort:output ratio, due to our superior plasticity. See https://joyemang33.github.io/blog/2026/humans-dont-just-samp... for a small experiment. That's why for programmers experienced with a particular language/codebase/domain, it feels like minimal effort to know where and what to change. "Why use LLMs when I can do it in 10 minutes"?

Of course, relying on our long term memory instead of re-ingesting the code, is also a problem for having assumptions that don't get updated, e.g. revisiting a codebase that's been updated by many others. With the rate of change/churn of codebases I'm wondering if this is naturally forcing us to use AI anyways, since it's really hard to keep track of a lot of code changes by AI as a human. Once you start down the path of not reading code yourself, the friction to start reading code gets higher in a feedback loop. I know people (incl. myself) who are still reading code in their own coding/agent sessions, but that's unsustainable in an organizational setting - you won't be able to ingest N'0,000s of LoC of changes every week if there is no incentive to do so.

Is that a good thing? It's unlikely LLMs in their current state will be "neuroplastic" for a single person's use case (mostly market reasons - cost of owning, running, tuning models will likely be unattainable for the foreseeable future). In a few generations, this would be a total surrender of all foundational coding to LLMs (unsure about knowledge work in other domains). Will text files with superintelligent models be enough to encode long term and broad understanding of a domain? Is it necessary if a model is superintelligent? What if a person/nation/species loses access to LLMs through supernatural / political reasons at that point? Will it be like losing the last remaining COBOL programmers to your mainframe? I'm sure we're resilient enough to re-learn all of that, but it will be a huge crutch like never before.

All that to say, it's still worth learning programming, and doing some things by hand, even if it's not "economically valuable" (at least on the surface). Even with web frameworks, it's still worth manually plumbing between frontend/backend/database. Even with interpreters and compilers, it is still worth understanding and doing a bit of assembly. Even with assemblers, it's still worth understanding machine code, CPU and architecture quirks. It's worth looking at the historical artifacts (both senses of the word) and understanding intents, constraints, and creativity (as another comment [1] has more beautifully said).

Two "further than programming" courses that also embody the spirit of the article (get interested, hands-on, play) have been impactful on my appreciation of computing systems are nand2tetris [2] and OS in 1000 lines [3]. Both are "easy" in the sense that they make certain design decisions so you don't have to dig through thousands of pages of manuals. If you wish, during or after the process, you can explore specific concepts further. It's broken down in the right pieces and checkpoints, so you get quick feedback on whether something is working or not. It's still very much a puzzle you have to solve, but the right difficulty/complexity ladder (great instructional design).

[1] https://news.ycombinator.com/item?id=49093468 [2] https://www.nand2tetris.org/ [3] https://operating-system-in-1000-lines.vercel.app/en/

Post reply on HN