Rendered at 21:52:24 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
primitivesuave 17 hours ago [-]
FWIW, Peter Norvig also gave an updated take on what programming will look like with LLMs around 2 years ago. It did give me some hope back then, but with the development of Fables and Kimis and Sols I think it's truly anyone's guess where the art of programming will go.
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?
noduerme 15 hours ago [-]
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 writing those. But for clean code, nothing beats knowing what you're going to write and just writing it yourself.
witx 13 hours ago [-]
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.
11 hours ago [-]
kakacik 14 hours ago [-]
... and 10x that for long term maintenance and evolution of the code. When you read your code later, understanding of it comes more naturally/faster than somebody else's code (at least for me). I break down bigger problems into small chunks in one way, other folks may view things differently.
zyz 13 hours ago [-]
> 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?
Not sure if API usage is heavily subsidized, especially for Fable. Chat interface for free users is subsidized for sure. I think we'll see how costly it is to deploy a big model now that Kimi K3 weights have become available.
whateverboat 14 hours ago [-]
What is the difference between a prompt engineer but a manager who talks with his charges to get some stuff designed?
There's a difference between charges and AI, in that the charges can be promoted to become managers and eventual decision makers which AI cannot be.
teiferer 14 hours ago [-]
Another thing is that not many can afford a power loom or similar and I don't think prices will go down, since it is already heavily subsidized?
whateverboat 14 hours ago [-]
It's just energy and chips, and both can be made cheaper.
StrauXX 14 hours ago [-]
I think GP was referring to the industrial revolution and shares your sentiment.
alt227 9 hours ago [-]
Yet for some reason the price of both currently are going up and up.
DavidPiper 9 hours ago [-]
When I was 11, I pulled a book off the shelf at the nearby library called "Teach Yourself C++ in 21 Days". I remember thinking the title was clearly nonsense, but if I could even learn a fraction of it, that would be pretty cool. We didn't have a computer at home yet, so I wrote out the exercises by hand.
I think I got about a third of the way through. I knew (debatably) what inheritance was, that a Dog is an Animal, etc.
School, university, and 10 years of career later across multiple stacks and companies, there's still a heap I don't know, but you can drop me in a lot of codebases and I'll figure it out.
> So go ahead and buy that Java/Ruby/Javascript/PHP book; you'll probably get some use out of it. But you won't change your life, or your real overall expertise as a programmer in 24 hours or 21 days.
True, but it DID change my life.
ecshafer 9 hours ago [-]
There was a webcomic abtruse goose that made fun of that book by humorously showing what you would have to do to get it done in 21 days.
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.
ramon156 14 hours ago [-]
On the other hand, sometimes the hardest bugs are only a few lines of code and days of debugging. If an LLM can do it in a day, you've saved time.
wolfi1 13 hours ago [-]
but not necessarily costs
moffkalast 13 hours ago [-]
Time's expensive too.
wolfi1 13 hours ago [-]
on the other hand you spend time and tokens using the AI approach
moffkalast 12 hours ago [-]
It's like hiring someone to do part of your job for you, which is a rather proven approach to getting more done in less time. A proud tradition going back hundreds of thousands of years.
bigfishrunning 9 hours ago [-]
Except when you buy tokens instead of hiring someone, you buy Sam Altman a yacht instead of buying somebody dinner.
moffkalast 5 hours ago [-]
Yeah, though unfortunately paying anyone I know to fix my code sure isn't going to go nearly as well as asking Claude. Or at all.
A word of advice from an European: Tax the rich. Then you no longer have these problems. Even running a local model just shifts the yacht to Jensen Huang instead.
witx 13 hours ago [-]
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
teiferer 14 hours ago [-]
I wonder if people writing these comments actually do this hands on.
That's because I do and a one line fix rarely costs anything but cents. Unless you first need to let it figure out which line it is, but that's not a fair comparison because you'd also first need to find out. And if it takes you an hour then instead paying $10 could be a reasonable price to pay.
superb_dev 14 hours ago [-]
Does their comment not read as hyperbole from someone frustrated at the state of the industry?
imdsm 14 hours ago [-]
Only way it's costing $10 is if you're putting your whole code base in without without any work or guidance, which is what people who don't use AI day to day think is what happens.
14 hours ago [-]
littlecranky67 13 hours ago [-]
But it took you probably years of knowledge and learning to be able to fix the line. If you start learning that from 0 today, the AI will be cheaper in the long run - because while it cost 10$ today, we know from history that everything computers & electronics gets faster and more efficient, so it will be 1$ or less in a couple of years.
dzonga 10 hours ago [-]
good thing - these articles keep getting shared so often.
yeah people's attention might be shot. but it's still a blessing to those who read it the first time, and the ones that re-read it.
the unfortunate thing in the 'llm' era - we seem hell bent on destroying the foundations of knowledge.
alt227 9 hours ago [-]
> the unfortunate thing in the 'llm' era - we seem hell bent on destroying the foundations of knowledge.
I disagreee with this. I personally have filled large gaps in my underlying concept knowledge through deep conversations with LLMs. Its so easy to learn huge amounts when you can pull on whatever thread that sparks your imagination. Just being able to keep drilling down into the core of a complex subject without having to stop and manually find the next piece of information is incredibly addictive to me. It gives me hope that LLMs can actually aid humanity instead of detracting from it.
raptdev 9 hours ago [-]
Agreed. Use of LLM with a true focus on learning, not allowing it to give you the answers but having it guide you through structured reasoning about new concepts, is very useful.
FinnLobsien 8 hours ago [-]
I totally agree with this when it comes to skill acquisition and deep expertise, which I care about more with skills than whatever rewards I might get for that expertise.
It's just important not to conflate this deep expertise with the milestone you need to get a job or something. Especially when combined with expertise in other fields, even very little effort can let you advance a lot.
yoyohello13 19 hours ago [-]
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 able to forgive LLMs for that. It really took away something I enjoyed.
afry1 19 hours ago [-]
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.
oneneptune 18 hours ago [-]
One thing AI did take away; I love reading source code written by other people. Node modules, plugins, LUA, python scripts... whatever. I loved seeing how people organized their logic, named their variables, the flavor of their comments... all of it. I learned so much diving through the source code of all the major tools.
Now it's all AI generated. You don't know if you're reading a novel human's take on a pattern or an LLM's attempt to reproduce. Worse; even if the AI presented something novel it produces at such a rate it's a needle in a haystack.
I feel cautious of any claim people make about their use of AI. I'm not even anti-AI; I use it. But at minimum wish there were a mechanism to know where the lines were.
ozgrakkurt 17 hours ago [-]
You can open linux source tree from 5 years ago and read that for a couple years.
The feeling of helplessness doesn’t come from the fact that you can’t get out of the AI hype but the fact that advertisers have captured the attention of large portions of the population.
teiferer 14 hours ago [-]
> Now it's all AI generated.
I can assure you, it's not. You just need to avoid the areas where this is prevalent.
> You don't know if you're reading a novel human's take on a pattern or an LLM's attempt to reproduce.
In the end of the day, if it's an elegant solution why does it matter! If anything then it sharpens your senses to check whether it's great or trash. A sense that one should have had with human code already, now it just feels more important (but it really isn't because it was important before too).
DarkTree 9 hours ago [-]
It matters because some people view code as a human art. Sure, AI can also probably produce a good sounding song, but that doesn't mean I will view it in the same way as a song created by a human.
beremaki 18 hours ago [-]
They are talking about the enjoyement. AI did disolve a lot of the meaning and magic behind pure code exercises.
What felt like a creative endeavor now feels and is even more treated by society and other software engineers as grossly mechanical.
And to me too that hurts. I think a lot of people whose identity or passion was tied to this feel like that.
It is very much a "what is painting purpose now that photography exists ?" or "what is craft in an era of industrial mass production" moment for some of us. There are answers but finding them require exploration and being willing to change what we are
I think that's their deeper point
sheepolog 18 hours ago [-]
So much life enjoyment is tied to feeling competent and respected. Seeing a new, more talented challenger on the horizon is bound to be discouraging to some extent. It's like going from high school to college all over again: you used to be the top of your class, now you're surrounded by people just as competent as you.
lanstin 7 hours ago [-]
To be happy as you age, you have to embrace being a clueless newbie. Some people seem very pessimistic that there is a method of creating networked software systems in a high quality way with LLMs, but it seems no different from many other changes - there are salient technical details that matter, and there is boilerplate, and as all the tools and problems shift, we find ways to highlight the stuff that matters and reduce the problems of boilerplate. I like GCC and haven’t run into a compiler bug in decades, nor looked at disassembly much in this millennium (except some go allocation stuff that puzzled me). I feel myself gaining skills to do that with LLMs in just the same way that higher power editors changed my behavior.
I am pretty old, and it does take conscious effort to give up my cherished skills and plunge into new things professionally, but it’s the only way for me. And I am not exaggerating “clueless” here - I continue my practice of expertise via making all the mistakes. When I am new to something and there are others not new, I lean on them and have my lacks very clearly seen. When I am more isolated, I take pains to have very conservative release plans.
But it is worth it: I get that pleasure of understanding a lot more often with new stuff than with the same old.
memjay 17 hours ago [-]
> 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.
lstodd 13 hours ago [-]
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.
frankie_t 13 hours ago [-]
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.
brokegrammer 16 hours ago [-]
It's not true at all. I recently vibe coded a REST API in Golang even though I never wrote any production Go code. However, I had to make copious use of my previous experience as an engineer to achieve quality.
You can see this in the real world. The people who are getting the most out of AI are the ones who already have experience coding without AI.
CEOs don't want to admit it but AI can't code anything non-trivial on its own.
lanstin 7 hours ago [-]
I rewrote a very slow backup lambda from Python, which I know well, to Scala, which I have done like three sections of the intro to scala exercises, in about 4 hours, totally vibe coding, but I know enough to skim it and see it is doing things a sensible way, and to get error handling and retries in the robust way. (New job they use Python for slow stuff and Scala for higher performance things).
pelasaco 14 hours ago [-]
I agree with you, but now we have managers pushing code to production, people that never coded but are "IT versed"..so you get PR/MR not just with code, but with PR/MR comment written by Claude, Commit Message written by Claude.. all super verbose, and you know the people operating Claude, have no clue. Super dangerous combination. But part of the reality.
lanstin 7 hours ago [-]
My son works in a place where this happens pretty regularly, and it actually increases his job security to clean it up.
brokegrammer 11 hours ago [-]
Managers are pushing non-trivial code that experienced engineers shouldn't be writing anyway.
If you're worried about not being able to write git commit messages anymore, then you might have been in the wrong career in the first place.
The whole point of AI is to reproduce things that used to be mass produced. AI isn't generating high quality compilers or OS kernels, for example, because we haven't found a way to mass produce those yet.
I suggest you stop listening to clowns like Elon Musk and Super Mario.
pelasaco 10 hours ago [-]
Your comment makes 0 sense..
> Managers are pushing non-trivial code that experienced engineers shouldn't be writing anyway.
non-trivial code shouldn't be written by experienced engineers? Please explain
> If you're worried about not being able to write git commit messages anymore, then you might have been in the wrong career in the first place.
How did you come to this conclusion? I am concerned about verbose AI documentation, 10 lines of commit message, MR comments with 50+ lines, the typical AI workflow that we all love: One huge commit with 10000+ changes.
> The whole point of AI is to reproduce things that used to be mass produced.
In your opinion, you mean? Because AI is doing everything which involves thinking. Art, Code, Music.. not "mass producted" things..
> I suggest you stop listening to clowns like Elon Musk and Super Mario.
Sounds like you are not really reading, thinking, writing.. only writing i guess?
brokegrammer 8 hours ago [-]
AI is creating Art, Code, and Music, but only boring stuff that nobody cares about anyway.
Sure, AI can generate your logo, or mix some music that you can play at a party, but at some point, people will call you out for feeding them garbage.
That's when you'll have to hire an experienced graphic designer to design a proper logo, and an experience DJ to create a proper mix based on your audience's mood.
To me AI is just like an IDE. It does stuff that I don't want to do so that I get to work on the fun stuff. Huge win.
peter_retief 16 hours ago [-]
I have mixed feelings about this, I hate the loss of slow "discovery" and the warm fuzzy feeling when you understand something that used to be Greek to you (unless of course you are Greek)
The piles of programming books, sadly many unread but admired on the shelf from afar.
Now I create programs in languages I only vaguely understand and run remote servers without even logging in, it feels slightly shameful but then we are all complicit
MASNeo 15 hours ago [-]
I really do differentiate between fast & vast changes of commodity code and critical sections. For the latter I’d explore with AI and then rewrite, line by line, with deliberate concern for all aspects relevant.
This does retain the joy of coding for me and takes away the pain of what is commodity and hard to do without tiresome meetings (mostly UI/UX and API/MCP as my products don’t differentiate on these).
teiferer 14 hours ago [-]
> learn a new programming language. I collected quite a few and it was fun to learn new paradigms
Let's be honest here: how many actually distinct paradigms are we really talking about here? I challenge you to name more than 5 which are not just flavors of the same core approach. Bonus if they are actually all relevant for production software.
spc476 1 hours ago [-]
The two major distinctions in computer languages (in my opinion) are declarative and imperative.
For declarative, where you describe what you want, not how to get it, you have Prolog, Make and SQL (maybe others but I haven't heard of them). Yes, they technically aren't purely declarative as they usually have an escape hatch to imperative for performance reasons, but you can get quite far with them just in a declarative style.
The imperative, where you tell the computer how to do something, you have procedural (Pascal, Ada, C, BASIC, Cobol, Fortran) that's your classical programming style of actions working on data. There's object oriented (Smalltalk, Java, Erlang) which structures things a bit differently than procedural, where data is told what to do (via methods or message passing). Functional languages are more about avoiding globals and controlling side effects (and typically are lazily evaluated, but I don't think that's foundational to functional). You have concatenative (Forth, Postscript, Joy) which centers around a point-free style of programming (implicit data on the stack instead of explicit in variables) and data-flow (or array-centric) languages (APL, J, K) which work natively on array data.
Each of these paradigms have their pros and cons. Procedural if you have a lot of actions on a small set of types. Object oriented if you have a lot of types and a small set of actions. Functional if you want easy-to-reason about code. Data-flow to help with parallelism. Concatenative if you don't want to name piece of data. Declarative to have the computer figure things out for you. All of these I can see a reason to use in production.
lanstin 7 hours ago [-]
The old ones are so ingrained it seems hard to imagine they were new at one point. But generally, assembly, top down programming (structured functions, modular hierarchies, no goto), bottom up programming (easiest to feel in Lisp or Python, doable in C after your first few programs, and arguably the basis for agile, the real version), object oriented (keep you verbs in your nouns), functional as pure compute (useful even in C) and functional as a bunch of chained standard meta functions (Haskell and ML and those ilk), closures/let over lambda (super powerful Lisp and what I think let JavaScript become excellent; let your verbs have the nouns they want), repl oriented programming (Python and lisp, and as a very fast way to explore a new interface from the bottom up), stack languages (Python, forth), interpreted VMs (Python again and JVM at first, many small weird examples at work), wrapping IO around poll/Linux type mechanisms (Node, gevent, high performance C), threads (so many thread per request frameworks), green threads(go, modern Java), declarative languages (prolog and Terraform), embedded languages for easy customization (TCL/Lua).
superb_dev 14 hours ago [-]
Python, Go, Rust, Lua, Racket, and of course Pony.
Python and Lua being probably the most similar of the bunch. The point is not that you would use any of these production (although you could), the point is to get your feet wet in a new setting. You see what's different and what's the same. I think it's a very important part of maturing as a programmer.
teiferer 11 hours ago [-]
> Python, Go, Rust, Lua, Racket, and of course Pony.
I was asking about paradigms. These are 6 languages and the distinct paradigms they cover are hardly 6. Unless we have different notions of what a paradigm is.
I see imperative and functional paradigms covered in your list. Am I missing anything else? Object orientation could be counted as a separate paradigm but how much different that is from basic imperative programming is already somewhat debatable.
superb_dev 1 hours ago [-]
That’s a fair point, they don’t really span the whole range of paradigms. I do think just looking at the paradigm is a reductive view.
All of those languages are very different in how they handle concurrency, safety, objects, meta programming, etc, in ways that force you to adapt how you approach and deconstruct problems. Certainly not as much as a whole different paradigm would, but still in ways that are valuable to explore.
skydhash 11 hours ago [-]
> Object orientation could be counted as a separate paradigm but how much different that is from basic imperative programming is already somewhat debatable.
There’s OOP with message passing (Smalltalk, Objective C) and there’s OOP with functional flavor (CLOS in Common Lisp).
I do agree that collecting paradigms is more interesting than collecting languages. Like logic programming (prolog), array and stack programming (uuia).
pelasaco 14 hours ago [-]
> Bonus if they are actually all relevant for production software.
Why it should be relevant for production software?
teiferer 11 hours ago [-]
Because I find that an interesting question. There are lots of experimental and somewhat esoteric things out there. And sure, it can be fun learning about them. But the proof is in the pudding, and if something is rarely useful for anything in production then it's more of an artisan entertainment factor and less of an actually useful programming language.
> But the proof is in the pudding, and if something is rarely useful for anything in production then it's more of an artisan entertainment factor and less of an actually useful programming language.
That's not true at all. In first place, what you can think is good for production, i can think otherwise.. Beside it there is a lot of things/paradigms/languages that we learn, to help us to either understand better the basics or because it is easier for beginners. There are a lot of Science and Research that you can just throw away, but that was super important for further development. Pascal, Smalltalk, Minix are example of technologies, that we learn(ed) and not necessary are widely used in production. Haskell helped me to understand is pure immutability is actually practical or not, and so on..
teiferer 7 hours ago [-]
[dead]
overgard 16 hours ago [-]
I just spent the past three hours debugging a long latent bug from vibe coding a thing. The only way I found it was running a debugger through the C++ code and tracing everything -- Claude was utterly useless until I basically pointed out the problem to it. I don't think understanding technical aspects of programming is a waste of time at all, it's still very necessary. The annoying thing too is that, whatever time I saved having the LLM write it, I pretty much just lost having to debug it. (For what it's worth: the bug it introduced is one I never would have introduced on my own, because it fundamentally misunderstood a key component of the design)
sublinear 16 hours ago [-]
I'm curious how many years you were into your career before LLMs took off. Reading and writing code is just another form of literacy, so I don't get this perspective at all.
I've been a developer for just over a decade and my usage of LLMs is minimal. It takes a similar amount of time to review as it does to just write it myself. How much time do you have for your tasks? I rarely have deadlines quicker than a few days. It wouldn't even matter if I got it done faster since the bottleneck is decisions in the next meeting or waiting to hear back from another team. Dev time was always trivial and irrelevant. Even back in the 2010s, my need for stackoverflow and google had become minimal.
What else are you doing with your time? How much discussion does your team even have if the nuances of the code aren't important to you?
kazinator 16 hours ago [-]
If you ship something, by some means, you get blame if it goes wrong.
But when it goes right, you can only get credit if you wrote it yourself.
If you're risking being blamed, that should be balanced with credit.
skydhash 10 hours ago [-]
> Even back in the 2010s, my need for stackoverflow and google had become minimal.
Web search engines are mostly for quick navigation this day as a lot of sites don’t bother with a good navigation menu. It’s faster to search the title of the page than to deal with the offered navigation widget.
> Reading and writing code is just another form of literacy, so I don't get this perspective at all.
Same here. I read and write code just like I read and write English (which is not even my second language). Coding is trivial. Most of the time is spent on communication (with the team and the stakeholder) and on reading documentation (so that you know the implications of using a function or what’s inside an object at a point of time). And even the latter is shortened as you got more familiar with the libraries.
peheje 12 hours ago [-]
I did this too. But honestly, I was getting a little tired of it.
Now I use AI to build things I genuinely like and actually use. Nothing particularly fancy.
I built a weather website that I use all the time when planning hikes. I also built a generative hiking-route tool: give it a starting point and a distance, and it tries to find interesting paths for you. I’ve made plenty of small helper tools for work and health, and now I’m wrestling with Open WebUI, trying to make it work exactly the way I want while repurposing an old Android device as the server.
Do I miss nerding out over implementing a B-tree, or learning async programming in F#, Go, Crystal, Nim, C++, C#, JavaScript workers, or Java green threads?
I don’t know, man. Maybe a little.
But it has also never been easier to say: “Hey AI, teach me this concept using five examples. Give me one task, then evaluate my solution. And teach it in this particular style.”
We lost something. I genuinely think we did.
But I also think we gained much more.
It’s okay to mourn what was lost, as long as you can still look forward.
fancyswimtime 19 hours ago [-]
same camp
drudolph914 17 hours ago [-]
I used to have this feeling, and I just got over this hurdle. I now continue coding by hand with zero AI usage. It's amazing how much better you feel when you get to use your brain. What really helped me was many perspective shifts
perspective shift 1: the people that never cared about programming/engineering finally left the room. the people chasing the trends, trying to grift, or just after money are finally gone. we can finally be in a room and just talk about good engineering. the people we as engineers never wanted to hear from are off attempting to force the world to use a tool that everyone 40 and under passionately rejects (this is spicy for HN terms, but the avg joe hates AI. people aren't stupid - they know they only stand to lose from it in the longer term).
perspective shift 2: I just read Zen, and the Art of Motorcycle Maintenance. It taught me a lot. I came away from that book understanding what "quality" means at a very philosophical level, and it gave me a lot of confidence for some fuzzy thoughts I already felt. it's too abstract to explain here, but it does a good job of explaining that there is perceived and strong difference between caring something into existence, verses just generating something into existence. this book breaks down how quality is not some artifact that lives in what you're making, and or is some feeling you get when you look at something that is aesthetically pleasing - quality is an event that occurs before you mind has differentiated yourself from the thing subject/object you're admiring - and in that moment, quality arises from the care you give it. there must exists energy and care towards what you're doing for quality to arise. generating anything with AI will never bring that fruition.
many people try to counter this stance by saying that they iterate with AI forever, and assume that iteration is a the same as the caring event described in ZATAOMM - but the difference is that grading output is not the same as creating/authorship. it's must a read and deep study I think if you're into programming and this mental state
perspective shift 3: This talk from Brandon Sanderson called We are the Art [1]. I personally do a lot of creative coding - like games and such. this talk does a great job of breaking down how art and creation ultimately lives in the person. I won't summarize here, just a must a watch
perspective shift 4: I got off all the mainstream social media site bc the PR machine for AI is relentless. of course you're going to feel like crap when every site says, future generations will be homeless, K shaped economy, permanent underclass, etc. you gotta log off these sites to create some distance with the beast - it's not you, the world really is just messed up rn. Also I barely browse HN anymore. this place is the public square for VCs and people who lost hte plot with technology - I just happened to be here, and wanted to help my fellow programmer grinding through the same mental trenches I was in
perspective shift 5: go find some programming communities on discord. I'm in a discord with like 5000 active members that really care about coding, and doing so without AI. this is a very active discord. once you realize there is a strong community still building like this, it really showed me we're not low in numbers, and there still a large group of people that will celebrate engineering efforts done by hand. and there are still people that need to understand these machines at a very deep level - you're efforts aren't wasted
perspective shift 6: look at AI on the job as a way to get your work done faster to get home to do real programming. work code can be trash, home is where the real work is done. The analogy I’ve been telling myself is that it’s like going into a gold mine - no one wants to be in the mine, but i do like leaving with gold. i gotta pay the bills, but i don’t need to love it.
perspective shift 7: The overall environment we live is just depressing and is reminiscent to Fahrenheit 451. I came away feeling closer to the author and protagonist than my first read. specifically the kind of hubris/ignorance found in all the side characters of F451 mimics what it feels like to talk with ai optimists. also, the way F451 is a world filled with people that are actively disengaged and comfortable being passively entertained feels almost too real. this book draws a lot of parallels with modern times, and it's a nice book to remind you that other people have felt this way in times of large technological change - and you're not crazy to feel depressed.
Go start working on that side project you use to be really passionate about. me and all the other serious engineers are excited to see it
> quality is an event that occurs before you mind has differentiated yourself from the thing subject/object you're admiring - and in that moment, quality arises from the care you give it. there must exists energy and care towards what you're doing for quality to arise. generating anything with AI will never bring that fruition.
This sounds very closely related to "ownership", something we've been trying to get rid of through agile/scrum and "bus factor" talk for over a decade.
anon7725 16 hours ago [-]
Thanks for this. Another perspective shift: do real things in the real world. Read physical books, make art with your own two hands, garden, go for a walk. I’m going to re-learn cursive handwriting. No real reason other than my handwriting is bad and I want to incorporate more writing into my life. The recent post here about Neal Stephenson was an inspiration.
Hey I just wanted to say thanks for writing this. I’m going to check out the things you mentioned, and it just feels nice to know there are like minded people out there. You writing this has helped me feel better about the state of things, and I appreciate that.
kaffekaka 16 hours ago [-]
No 4: getting off social media and HN is a good thing in general and in particular. There really is a distortion field around these sites that can make you feel sick.
overgard 16 hours ago [-]
> perspective shift 1: the people that never cared about programming/engineer finally left of the room.
God I wish, they've all become annoying loud "thought leaders"
jurjenh 15 hours ago [-]
You are obviously with them in the wrong room....
Once you know them for who/what they are, and you learn to be comfortable enough with not following them closely, or not knowing what the hip thing is right now, then you can learn to let go of that (almost) insatiable need to keep up. Let them have the room - and the mental energy it requires.
mnsc 13 hours ago [-]
A recent thing that caused a perspective shift for me was identifying where my drive was coming from. Triggered by the difference between the etymologies of amateur (one who loves) vs connoisseur (one who knows).
Amateur - learns construction on free time ad hoc/by doing, builds a cabin, enjoys living in it
Connoisseur - reads lots of books on construction, might build a cabin to verify competence, enjoys thinking about it
Professional - went to school and works in construction, enjoys the paycheck, doesn't have a cabin
I haven't read the motorcycle zen book yet, but I imagine that is the loving amateur angle, whereas for me I just thrive in knowledge. Translating that to the current AI hellscape, I kinda like that the code crafting bit is a bit less pronounced where I can instead focus on getting to know the system/model/domain of my work. It helps with the dystopian feelings I sometimes get from being in the mine. But if you are a passionate coder, I would imagine that letting someone else build your cabin would be extremely provoking.
Thank you for this post.
dzonga 10 hours ago [-]
thank you for this - needed it.
rrvsh 9 hours ago [-]
I went down a five hour rabbit hole learning about jwz as a result of this post. What an interesting guy - if I knew about the DNA lounge a week earlier, I would have visited when I was in the city
markus_zhang 20 hours ago [-]
From my experience, just to say the thing that many such articles never mentioned, because the author has the innate ability anyway:
Seek mental stability, or whatever mental state that can push you to programming for 10 years without completely burning you out. If you can’t even do some programming after a relatively easy work day, you are burnt out.
BTW ^ is my state nowadays.
taneq 19 hours ago [-]
It’s okay to recognise when you’ve had enough. If your workday involves programming, ours pretty normal (for me at least) to not want to do more programming at home. You gotta let yourself miss it a bit if you want to want it.
incanus77 16 hours ago [-]
Why is this marked as 1998 when it references Khan Academy and Go, among other things?
flohofwoe 15 hours ago [-]
On Wayback machine references to this post (a much shorter version though) go back to 1998, this is the oldest reference:
So he changed the text as time went on, since the 1998 version doesn't reference Khan Academy. Though the "(1998)" might still be justified if the changes are minor.
dirkc 15 hours ago [-]
I see a reference to Khan Academy, but not Go?
el_io 13 hours ago [-]
> 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).
dirkc 11 hours ago [-]
Thanks, clearly my caffeine intake is at issue
throwaway17_17 19 hours ago [-]
When I decided to really learn how to program, after dabbling in very basic C++ from books and using BASIC this article and Eric S. Raymond’s ‘How to Become a Hacker’ [1] (CATB is struggling to load at all these days it seems) were two of the first articles I found. While HtBaH was probably more influential on me immediately, Teach Yourself was a great appetizer for the concept of pacing myself in my learning and in the choices I made.
With all the “AI” has made coding/learning to code a dead end and unnecessary crud being peddled currently I don’t know if people who want to actually learn to program are going to find resources that can be as motivating as this and other articles from `the before times`. It leaves me slightly bummed out, but in my less pessimistic moments I think motivated learners are going to see through the hype and find these types of resource anyway.
On a side note, the Norvig’s articles about implementing a Scheme in Python were my first foray into designing and implementing programming languages, compilers, and interpreters which really shaped my interest all the way through to today.
A section on how AI tools can complement deliberate practice, rather than replace it, would make this even more relevant today.
jdw64 20 hours ago [-]
These days, I'm not sure anymore. I learned through self-study, reading documents. I don't have a degree, and I don't have the exceptional talent to be involved in language standardization.
Everyone around me codes with AI, and most of them produce better results than I do. That's natural. I'm good at some things, but I'm bad at many others. I still hand-code occasionally, but now the main is AI coding, and hand-coding is the sub.
This document probably held true until about 3 or 4 years ago. But since last year, I'm not sure. I have nothing to say other than 'Just do it.'
People say vibe coding has security issues, but honestly, I have security issues in my own code too, from TTL and all that. In the end, with vibe coding, knowing the right security keywords and understanding the problems seems to come from experience anyway.
Reading 'So You Want to be a Programmer,' I feel like conversations with other programmers and the whole process of being a programmer feel distant to me now. Since AI came out, I barely talk about programming with other programmers.
It's not just me—most Korean programmers around me are the same. The reason is simple: those kinds of programming discussions make us realize how limited our knowledge is, since our understanding is often filtered through English sources and then translated into Korean. So we just end up not talking to each other about it.
When I saw this document about 4 or 5 years ago, it felt like it was absolutely true. The environment has changed drastically, and reading this again now. Back then I treated it like a Bible, but not anymore. I realize that if you don't have a degree or aren't a native English speaker, there was always a limit to how much you could participate. These days, everything is changing so fast. As AI breaks down the English barrier, the quality of materials I can read has gone up, and I'm starting to think that even programming mindsets might change depending on language background.
But if I were to advise someone starting programming from scratch today, I'd probably just tell them to learn through vibe coding and get familiar with programming keywords and black-box coding.
Vibe coding has become the baseline these days. The domains individuals need to handle have become so broad that it's gotten more complex.
In the past, being good at just one domain was enough to make a living. But these days, everyone wants to become a full-stack developer—something that used to be rare. Even then, full-stack developers had a clear front-end or back-end bias, with some areas being shallow and others deep. Now, people are expected to be good at everything.
If you want to become a true expert, I'd say keep hand-coding and focus on a single domain. But if not, I'd say just go all in on vibe coding. Use it a lot, and build your own worldview through it
The feeling of hand-coding and vibe coding is so different that I can't help but tell people to practice both. They complement each other, but they don't really feel like they're connected or intertwined. They rely on different kinds of intuition.
Still, I think I'll keep hand-coding. Not because it's more productive, but purely because I enjoy it as a hobby. AI writes better code than I do, but hand-coding is still enjoyable enough as a hobby
metalspot 16 hours ago [-]
I have used AI almost exclusively for a year, but I was programming by hand for almost 30 years before that. I don't think there is any difference between going from assembly -> C -> Java, TypeScript, C#, Go, etc, and taking the next step to AI. It is just another intermediate abstraction layer that allows you to work at larger scale.
Programming with AI enforces some good disciplines, which were always true, but could be avoided doing it by hand. Most importantly: you are shipping your tests. If you don't have reproducible automated tests then it probably doesn't work.
jdw64 15 hours ago [-]
First, I upvoted your comment. I consider it the cost of hearing insights from someone with 30 years of experience. But I don't agree.
The reason is that the compiler's mechanical contract is 'deterministic.' AI, on the other hand, is 'probabilistic.' No matter how much you specify the same situation and details, it doesn't produce 100% identical results.
Abstraction should fundamentally share the same axis of change, but AI doesn't do that. And human code typically starts small, adjusts bit by bit, and refactors as requirements change or scale grows to realign the axis of change. AI's abstraction is fundamentally different from what humans create.
Of course, it can depend on the 'workflow.' If you work in small function units, it can act similarly to a deterministic system. But fundamentally, the market's expectation for natural language AI coding is based on 'large codebases.' Since it's not a codebase understood by a human, it effectively creates an abstraction that's different from my cognitive abilities.
The problem is that AI's abstraction varies from project to project. This is undeniably black-box coding. Sure, you can review it if you know how to read code, but my view differs from yours.
I don't think this is a new abstraction layer. I see it as a technique for controlling blast radius. Of course, you could review the entire codebase while working, but considering the recent vibe coding trend, where people only check core P0 and P1 parts and let AI generate the rest freely, it's even more clear that the focus is on scaling to sizes that humans couldn't handle before.
Of course, my perspective differs from yours, and I think you're a far better programmer than I am.
That's why I think hand-coding and vibe-coding share only the surface-level axis of producing an output, but the cognitive instincts they demand are completely different.
The core of vibe-coding is essentially predicting which part of the black box, if it breaks, would be most critical to the system, and isolating the blast radius. Hand-coding, on the other hand, is fundamentally about surveying the entire system, and definitively controlling and designing every control flow and state change.
In other words, one is an area of 'auditing,' giving up direct control in favor of managing risk, while the other is an area of 'creation,' shaping logical consistency from 0 to 1.
I imagine you also have experience as a PM.
A project manegaris a different profession from a programmer. It requires programming experience, but it's fundamentally a different role. In my view, vibe-coding is essentially a career transition toward being a PM.
But separate from that, I don't think this is simply a new abstraction layer. I've seen enough cases where the same prompt and same environment produce different results
bigstrat2003 7 hours ago [-]
There is a massive difference between an LLM and a compiler. Compilers work deterministically, an LLM does not. You cannot ever trust an LLM to actually produce working code and must review it all yourself, as all models (yes, even $latest_model) will happy insert hallucinations into random places in the code. But once you take the time to do that, you have not saved any time and could've just written it yourself. That is why LLMs are not actually useful for programming, contrary to the hype, unless you want to just YOLO stuff out there without caring if it works.
hdivider 10 hours ago [-]
I think what doesn't get surfaced enough is that the cost of AI tokens is likely to decrease as new computing hardware gets scaled, such as neuromorphic (or later, photonic) computing.
To assume the current cost of Claude Code and the like is largely fixed is not likely to be accurate. The economic incentive to lower the cost of ML compute at both training and inference is very strong -- and likely even stronger once the bubble bursts.
Once the compute cost is much lower, and the systems more advanced as well, then the future of programming changes. The role of the human in this may be more like: we need one senior experienced full-stack, and like 1-3 others, to build and maintain large complex apps reliably.
rushil_b_patel 9 hours ago [-]
Great read
MichaelMoser123 20 hours ago [-]
Wasn't Claude supposed to do all the coding by now? Did we have a change of mind or did we run out of tokens?
crystal_revenge 20 hours ago [-]
I don't personally know anyone who writes code any more (for work). Is this not the case for you?
The distinction I see now is between teams that read PRs and teams that don't. I still think the former is a good approach... for now, but I don't expect this will necessarily be the case in a year (or less).
This article was such an inspiration to me when I was younger, and the advice, for that time, was very correct. However seeing it today really drives home how big the gap is going to be in really understanding code in just a few more years.
zero-sharp 20 hours ago [-]
>I don't personally know anyone who writes code any more (for work). Is this not the case for you?
I hear this from time to time. But I still write code at my job. I'm not a software engineer and I don't work for a software engineering firm.
wannabe44 12 hours ago [-]
Reading the code will not give you the same mental model as writing it. Sure you can catch some high level issues, but the brain is incentivized to skip over the lines which look like boilerplate. any issue in between boilerplate is going to be unnoticed.
The original sin of the programming industry is not valuing expressive notation and expressive programming languages. (I am not talking about map/filter/reduce level party tricks but better metaprogramming and coherent abstractions). No amount of sacrificing tokens for Anthropicus is going to give you the same amount of understanding as writing the program.
my-next-account 18 hours ago [-]
I do! A lot of the work I do is not simple CRUD, and I have to think about what's going on. Reading code doesn't do that to the same degree.
soulofmischief 15 hours ago [-]
Cutting-edge models are capable of much more than generating CRUD apps and understanding the details is orthogonal to whether you wrote the lines yourself or not.
Jtarii 11 hours ago [-]
>understanding the details is orthogonal to whether you wrote the lines yourself or not
Reading the code does not give you the knowledge of the 10 different approaches you would have tried and failed before coming up with that code. Why exactly a piece of code is the way that it is cannot be determined by just reading the code.
Reading a mathematical proof does not give you any meaningful understanding of it.
soulofmischief 7 hours ago [-]
You haven't considered that I probably already discussed 10 different approaches with my agent before authorizing a particular implementation. Or that I didn't ask about alternatives during review. You're confusing physically coding with thinking. You can still think just fine without writing code yourself.
If you are experienced, attentive, curious, willing to explore, etc., that doesn't change after an LLM allows you to deeply discuss any concept at will, quickly try different prototypes and zone in on the correct implementation. You will use these tools to their full extent.
> Why exactly a piece of code is the way that it is cannot be determined by just reading the code.
If you maintained a good commit history and your code is self-documenting and you're not capable of understanding and navigating code you read, you can still literally just ask the LLM to explain the code within the context of the codebase. They are extremely good at that exact task. They will give you as much as you give them. If you want to know, and can understand, the nitty gritty, you can do that and no one is stopping you.
> Reading a mathematical proof does not give you any meaningful understanding of it.
Again: these things can function as personal tutors. Run the proof through an LLM and ask it what you care about. Furthermore, there are plenty of elegant proofs you can read which confer "meaningful" understanding.
Before just assuming that everyone telling you these tools are useful is less capable or experienced than you, it's worth considering if it's actually you who needs to maintain an open mind and attempt to learn from others.
my-next-account 14 hours ago [-]
Yeah, I disagree on the latter point by a lot :-). Really, is it truly "orthogonal"? Not really, you will understand the details better by writing them yourself. On your first point, they are pretty good at a lot of stuff, given that they have seen it before. A lot of the time, I'm writing code that no LLM has seen before. That sounds super smug, but it's "da tru tru".
soulofmischief 7 hours ago [-]
I welcome you to prove this conjecture, otherwise it's just vibes.
> A lot of the time, I'm writing code that no LLM has seen before
I hear this tired point over and over from people who cannot fathom that others who use LLMs successfully could possibly also be working in a specialized domain. Frontier models are excelling at difficult, long-horizon tasks now. I write all sorts of esoteric stuff, and I can confidently hand a frontier model specification for a language it's never even seen before, working in a domain it's never encountered, and likely get good results, provided I have the knowledge and experience to guide the model.
The reality is that this "they are only good at things they have 'seen before'" talking point that often gets parroted is vaguely defined and largely based in opinion. Obviously, models perform worse when the input or expected output are out of distribution.
But this was much more true a couple years ago than it is today; the gap has closed considerably, and those who are learning to think deeply with these tools will be better positioned than those who arrogantly think that their process cannot be augmented by the most intelligent systems ever created.
my-next-account 4 hours ago [-]
This is HN, most of it is vibes. Lol, conjecture, touch grass man. I do PL research, it's not that good at that stuff, do you think I'm not trying using it?
eventualcomp 20 hours ago [-]
Programming without writing, to me, feels like doing mathematics by reading proofs but not doing proofs. Which quite frankly works very poorly for me. I write code if, for nothing else, so that I can spot bad code/proofs with an easier time, rather than dealing with an equation that blew up in prod.
bigstrat2003 7 hours ago [-]
I do not know anyone competent who stopped writing code. You have to write the code yourself if you want good results, or spend so much time reviewing the clanker that you may as well have written it yourself.
AnonC 19 hours ago [-]
Claude isn’t even good enough for Anthropic to release native desktop applications for each OS. As someone said in a comment in a different post here, it seems like these tools are good at web and web related (like Electron) development.
Anthropic intentionally missed the opportunity to show that its models can develop really good native applications.
OpenAI’s latest desktop applications seem to be worse than before too.
taneq 19 hours ago [-]
Two things:
1) By the time I’ve determined, and expressed to my satisfaction, exactly what I want, I’ve already done the hard work of coding that thing. The rest is fairly mechanical by comparison.
2) It’s a universal truth (which I know someone’s gonna argue with :D ) that reading and working with other peoples’ code is much less fun than reading and working with your own. This applies even if the other people are robots.
3) When checking and troubleshooting code, the bulk of the time is spent understanding it in the first place. If you wrote the code yourself this already implicitly happened and is ‘free’.
Put those four[1] things together and at least for me personally, AI-assisted coding isn’t a better experience than just doing it myself. It’s still great for bootstrapping yourself into a new unfamiliar language/environment though.
[1] Yeah it’s an off-by-one joke. ;)
QuercusMax 19 hours ago [-]
"I love building software, I just don't like the data entry parts", to paraphrase a guy I worked with once who explained how he loved writing design docs for junior engineers to implement.
threethirtytwo 20 hours ago [-]
The utility of this stuff is largely going away. It’s more just hobbyists now or old timers like me who actually “learned” programming.
There are HS interns at my company who admire me because I lived through a time without AI and I actually had to learn that stuff. I’m not kidding.
MichaelMoser123 16 hours ago [-]
At some point there will be no one left to review Claude generated code. I think that will be an interesting time, given our reliance on software based systems...
A linked-in post on CS enrollment at universities:
"In the past two years, the drop was ~20% at UC Berkeley and ~30% at UC Davis, while UC San Diego is the only one still rising."
On the other hand: LeetCode traffic rankings are up, so some people still solve programming problems by hand - or they hope to get a job, by being able to solve them.
I think this is a confusing time. It will probably take a while, until things become clearer.
LoganDark 20 hours ago [-]
Was this known in 1998?
zombot 16 hours ago [-]
In ten years. The kids may not believe that, but you could give realistic timeframes without getting hanged for it. In the age of LLMs, if you weren't done yesterday, it takes too long.
weiliddat 12 hours ago [-]
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).
It’s been almost long enough to teach yourself programming three times!
zkmon 20 hours ago [-]
Maybe an yearly ritual?
sunsetSamurai 20 hours ago [-]
if you had started the guide on the first time it was posted, you'd be done by now!
ebiederm 19 hours ago [-]
I started before the guide was published. I am 40 years in on challenging myself and learning and improving and there remains so much more I have the opportunity to master.
sunsetSamurai 18 hours ago [-]
I myself am spending a lot of time leveling up, I recently realized there are so many things about programming and CS that I don't know about or only have a superficial knowledge. There's so much to learn but it's very rewarding.
justaman123 19 hours ago [-]
Lyf short
13 hours ago [-]
15 hours ago [-]
KaseyKim 16 hours ago [-]
[dead]
lumos_huang 13 hours ago [-]
[dead]
lumos_huang 13 hours ago [-]
[dead]
coolThingsFirst 18 hours ago [-]
dont waste your time, it's a dead field.
bigfishrunning 9 hours ago [-]
Programming is only dead for people who had contempt for it in the first place. Turns out that's most programmers and almost all managers.
https://www.youtube.com/watch?v=ia6aJIplmtc
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?
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.
Not sure if API usage is heavily subsidized, especially for Fable. Chat interface for free users is subsidized for sure. I think we'll see how costly it is to deploy a big model now that Kimi K3 weights have become available.
There's a difference between charges and AI, in that the charges can be promoted to become managers and eventual decision makers which AI cannot be.
I think I got about a third of the way through. I knew (debatably) what inheritance was, that a Dog is an Animal, etc.
School, university, and 10 years of career later across multiple stacks and companies, there's still a heap I don't know, but you can drop me in a lot of codebases and I'll figure it out.
> So go ahead and buy that Java/Ruby/Javascript/PHP book; you'll probably get some use out of it. But you won't change your life, or your real overall expertise as a programmer in 24 hours or 21 days.
True, but it DID change my life.
https://gabrielcoarna.com/2010/11/05/how-to-teach-yourself-c...
Ended up in Accounting, dabbled with Python and now back to programming with Cursor/Claude.
It did get me just far enough so I could see that computers were complicated but not actually magic and like you did change my life.
Not sure if the savings add up enough to offset the investment in learning to program.
A word of advice from an European: Tax the rich. Then you no longer have these problems. Even running a local model just shifts the yacht to Jensen Huang instead.
That's because I do and a one line fix rarely costs anything but cents. Unless you first need to let it figure out which line it is, but that's not a fair comparison because you'd also first need to find out. And if it takes you an hour then instead paying $10 could be a reasonable price to pay.
yeah people's attention might be shot. but it's still a blessing to those who read it the first time, and the ones that re-read it.
the unfortunate thing in the 'llm' era - we seem hell bent on destroying the foundations of knowledge.
I disagreee with this. I personally have filled large gaps in my underlying concept knowledge through deep conversations with LLMs. Its so easy to learn huge amounts when you can pull on whatever thread that sparks your imagination. Just being able to keep drilling down into the core of a complex subject without having to stop and manually find the next piece of information is incredibly addictive to me. It gives me hope that LLMs can actually aid humanity instead of detracting from it.
It's just important not to conflate this deep expertise with the milestone you need to get a job or something. Especially when combined with expertise in other fields, even very little effort can let you advance a lot.
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.
Now it's all AI generated. You don't know if you're reading a novel human's take on a pattern or an LLM's attempt to reproduce. Worse; even if the AI presented something novel it produces at such a rate it's a needle in a haystack.
I feel cautious of any claim people make about their use of AI. I'm not even anti-AI; I use it. But at minimum wish there were a mechanism to know where the lines were.
The feeling of helplessness doesn’t come from the fact that you can’t get out of the AI hype but the fact that advertisers have captured the attention of large portions of the population.
I can assure you, it's not. You just need to avoid the areas where this is prevalent.
> You don't know if you're reading a novel human's take on a pattern or an LLM's attempt to reproduce.
In the end of the day, if it's an elegant solution why does it matter! If anything then it sharpens your senses to check whether it's great or trash. A sense that one should have had with human code already, now it just feels more important (but it really isn't because it was important before too).
What felt like a creative endeavor now feels and is even more treated by society and other software engineers as grossly mechanical.
And to me too that hurts. I think a lot of people whose identity or passion was tied to this feel like that.
It is very much a "what is painting purpose now that photography exists ?" or "what is craft in an era of industrial mass production" moment for some of us. There are answers but finding them require exploration and being willing to change what we are
I think that's their deeper point
I am pretty old, and it does take conscious effort to give up my cherished skills and plunge into new things professionally, but it’s the only way for me. And I am not exaggerating “clueless” here - I continue my practice of expertise via making all the mistakes. When I am new to something and there are others not new, I lean on them and have my lacks very clearly seen. When I am more isolated, I take pains to have very conservative release plans.
But it is worth it: I get that pleasure of understanding a lot more often with new stuff than with the same old.
Not if your company decides to be "AI-first" and puts agent use on your job results.
Have some agency in your life. Sometimes people here write stuff as if being in control of their lifes is unthinkable.
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.
You can see this in the real world. The people who are getting the most out of AI are the ones who already have experience coding without AI.
CEOs don't want to admit it but AI can't code anything non-trivial on its own.
If you're worried about not being able to write git commit messages anymore, then you might have been in the wrong career in the first place.
The whole point of AI is to reproduce things that used to be mass produced. AI isn't generating high quality compilers or OS kernels, for example, because we haven't found a way to mass produce those yet.
I suggest you stop listening to clowns like Elon Musk and Super Mario.
> Managers are pushing non-trivial code that experienced engineers shouldn't be writing anyway.
non-trivial code shouldn't be written by experienced engineers? Please explain
> If you're worried about not being able to write git commit messages anymore, then you might have been in the wrong career in the first place.
How did you come to this conclusion? I am concerned about verbose AI documentation, 10 lines of commit message, MR comments with 50+ lines, the typical AI workflow that we all love: One huge commit with 10000+ changes.
> The whole point of AI is to reproduce things that used to be mass produced.
In your opinion, you mean? Because AI is doing everything which involves thinking. Art, Code, Music.. not "mass producted" things..
> I suggest you stop listening to clowns like Elon Musk and Super Mario.
Sounds like you are not really reading, thinking, writing.. only writing i guess?
Sure, AI can generate your logo, or mix some music that you can play at a party, but at some point, people will call you out for feeding them garbage.
That's when you'll have to hire an experienced graphic designer to design a proper logo, and an experience DJ to create a proper mix based on your audience's mood.
To me AI is just like an IDE. It does stuff that I don't want to do so that I get to work on the fun stuff. Huge win.
This does retain the joy of coding for me and takes away the pain of what is commodity and hard to do without tiresome meetings (mostly UI/UX and API/MCP as my products don’t differentiate on these).
Let's be honest here: how many actually distinct paradigms are we really talking about here? I challenge you to name more than 5 which are not just flavors of the same core approach. Bonus if they are actually all relevant for production software.
For declarative, where you describe what you want, not how to get it, you have Prolog, Make and SQL (maybe others but I haven't heard of them). Yes, they technically aren't purely declarative as they usually have an escape hatch to imperative for performance reasons, but you can get quite far with them just in a declarative style.
The imperative, where you tell the computer how to do something, you have procedural (Pascal, Ada, C, BASIC, Cobol, Fortran) that's your classical programming style of actions working on data. There's object oriented (Smalltalk, Java, Erlang) which structures things a bit differently than procedural, where data is told what to do (via methods or message passing). Functional languages are more about avoiding globals and controlling side effects (and typically are lazily evaluated, but I don't think that's foundational to functional). You have concatenative (Forth, Postscript, Joy) which centers around a point-free style of programming (implicit data on the stack instead of explicit in variables) and data-flow (or array-centric) languages (APL, J, K) which work natively on array data.
Each of these paradigms have their pros and cons. Procedural if you have a lot of actions on a small set of types. Object oriented if you have a lot of types and a small set of actions. Functional if you want easy-to-reason about code. Data-flow to help with parallelism. Concatenative if you don't want to name piece of data. Declarative to have the computer figure things out for you. All of these I can see a reason to use in production.
Python and Lua being probably the most similar of the bunch. The point is not that you would use any of these production (although you could), the point is to get your feet wet in a new setting. You see what's different and what's the same. I think it's a very important part of maturing as a programmer.
I was asking about paradigms. These are 6 languages and the distinct paradigms they cover are hardly 6. Unless we have different notions of what a paradigm is.
I see imperative and functional paradigms covered in your list. Am I missing anything else? Object orientation could be counted as a separate paradigm but how much different that is from basic imperative programming is already somewhat debatable.
All of those languages are very different in how they handle concurrency, safety, objects, meta programming, etc, in ways that force you to adapt how you approach and deconstruct problems. Certainly not as much as a whole different paradigm would, but still in ways that are valuable to explore.
There’s OOP with message passing (Smalltalk, Objective C) and there’s OOP with functional flavor (CLOS in Common Lisp).
I do agree that collecting paradigms is more interesting than collecting languages. Like logic programming (prolog), array and stack programming (uuia).
Why it should be relevant for production software?
That's not true at all. In first place, what you can think is good for production, i can think otherwise.. Beside it there is a lot of things/paradigms/languages that we learn, to help us to either understand better the basics or because it is easier for beginners. There are a lot of Science and Research that you can just throw away, but that was super important for further development. Pascal, Smalltalk, Minix are example of technologies, that we learn(ed) and not necessary are widely used in production. Haskell helped me to understand is pure immutability is actually practical or not, and so on..
I've been a developer for just over a decade and my usage of LLMs is minimal. It takes a similar amount of time to review as it does to just write it myself. How much time do you have for your tasks? I rarely have deadlines quicker than a few days. It wouldn't even matter if I got it done faster since the bottleneck is decisions in the next meeting or waiting to hear back from another team. Dev time was always trivial and irrelevant. Even back in the 2010s, my need for stackoverflow and google had become minimal.
What else are you doing with your time? How much discussion does your team even have if the nuances of the code aren't important to you?
But when it goes right, you can only get credit if you wrote it yourself.
If you're risking being blamed, that should be balanced with credit.
Web search engines are mostly for quick navigation this day as a lot of sites don’t bother with a good navigation menu. It’s faster to search the title of the page than to deal with the offered navigation widget.
> Reading and writing code is just another form of literacy, so I don't get this perspective at all.
Same here. I read and write code just like I read and write English (which is not even my second language). Coding is trivial. Most of the time is spent on communication (with the team and the stakeholder) and on reading documentation (so that you know the implications of using a function or what’s inside an object at a point of time). And even the latter is shortened as you got more familiar with the libraries.
Now I use AI to build things I genuinely like and actually use. Nothing particularly fancy.
I built a weather website that I use all the time when planning hikes. I also built a generative hiking-route tool: give it a starting point and a distance, and it tries to find interesting paths for you. I’ve made plenty of small helper tools for work and health, and now I’m wrestling with Open WebUI, trying to make it work exactly the way I want while repurposing an old Android device as the server.
Do I miss nerding out over implementing a B-tree, or learning async programming in F#, Go, Crystal, Nim, C++, C#, JavaScript workers, or Java green threads?
I don’t know, man. Maybe a little.
But it has also never been easier to say: “Hey AI, teach me this concept using five examples. Give me one task, then evaluate my solution. And teach it in this particular style.”
We lost something. I genuinely think we did.
But I also think we gained much more.
It’s okay to mourn what was lost, as long as you can still look forward.
perspective shift 1: the people that never cared about programming/engineering finally left the room. the people chasing the trends, trying to grift, or just after money are finally gone. we can finally be in a room and just talk about good engineering. the people we as engineers never wanted to hear from are off attempting to force the world to use a tool that everyone 40 and under passionately rejects (this is spicy for HN terms, but the avg joe hates AI. people aren't stupid - they know they only stand to lose from it in the longer term).
perspective shift 2: I just read Zen, and the Art of Motorcycle Maintenance. It taught me a lot. I came away from that book understanding what "quality" means at a very philosophical level, and it gave me a lot of confidence for some fuzzy thoughts I already felt. it's too abstract to explain here, but it does a good job of explaining that there is perceived and strong difference between caring something into existence, verses just generating something into existence. this book breaks down how quality is not some artifact that lives in what you're making, and or is some feeling you get when you look at something that is aesthetically pleasing - quality is an event that occurs before you mind has differentiated yourself from the thing subject/object you're admiring - and in that moment, quality arises from the care you give it. there must exists energy and care towards what you're doing for quality to arise. generating anything with AI will never bring that fruition.
many people try to counter this stance by saying that they iterate with AI forever, and assume that iteration is a the same as the caring event described in ZATAOMM - but the difference is that grading output is not the same as creating/authorship. it's must a read and deep study I think if you're into programming and this mental state
perspective shift 3: This talk from Brandon Sanderson called We are the Art [1]. I personally do a lot of creative coding - like games and such. this talk does a great job of breaking down how art and creation ultimately lives in the person. I won't summarize here, just a must a watch
perspective shift 4: I got off all the mainstream social media site bc the PR machine for AI is relentless. of course you're going to feel like crap when every site says, future generations will be homeless, K shaped economy, permanent underclass, etc. you gotta log off these sites to create some distance with the beast - it's not you, the world really is just messed up rn. Also I barely browse HN anymore. this place is the public square for VCs and people who lost hte plot with technology - I just happened to be here, and wanted to help my fellow programmer grinding through the same mental trenches I was in
perspective shift 5: go find some programming communities on discord. I'm in a discord with like 5000 active members that really care about coding, and doing so without AI. this is a very active discord. once you realize there is a strong community still building like this, it really showed me we're not low in numbers, and there still a large group of people that will celebrate engineering efforts done by hand. and there are still people that need to understand these machines at a very deep level - you're efforts aren't wasted
perspective shift 6: look at AI on the job as a way to get your work done faster to get home to do real programming. work code can be trash, home is where the real work is done. The analogy I’ve been telling myself is that it’s like going into a gold mine - no one wants to be in the mine, but i do like leaving with gold. i gotta pay the bills, but i don’t need to love it.
perspective shift 7: The overall environment we live is just depressing and is reminiscent to Fahrenheit 451. I came away feeling closer to the author and protagonist than my first read. specifically the kind of hubris/ignorance found in all the side characters of F451 mimics what it feels like to talk with ai optimists. also, the way F451 is a world filled with people that are actively disengaged and comfortable being passively entertained feels almost too real. this book draws a lot of parallels with modern times, and it's a nice book to remind you that other people have felt this way in times of large technological change - and you're not crazy to feel depressed.
Go start working on that side project you use to be really passionate about. me and all the other serious engineers are excited to see it
[1] - https://www.youtube.com/watch?v=mb3uK-_QkOo
This sounds very closely related to "ownership", something we've been trying to get rid of through agile/scrum and "bus factor" talk for over a decade.
God I wish, they've all become annoying loud "thought leaders"
Once you know them for who/what they are, and you learn to be comfortable enough with not following them closely, or not knowing what the hip thing is right now, then you can learn to let go of that (almost) insatiable need to keep up. Let them have the room - and the mental energy it requires.
Amateur - learns construction on free time ad hoc/by doing, builds a cabin, enjoys living in it
Connoisseur - reads lots of books on construction, might build a cabin to verify competence, enjoys thinking about it
Professional - went to school and works in construction, enjoys the paycheck, doesn't have a cabin
I haven't read the motorcycle zen book yet, but I imagine that is the loving amateur angle, whereas for me I just thrive in knowledge. Translating that to the current AI hellscape, I kinda like that the code crafting bit is a bit less pronounced where I can instead focus on getting to know the system/model/domain of my work. It helps with the dystopian feelings I sometimes get from being in the mine. But if you are a passionate coder, I would imagine that letting someone else build your cabin would be extremely provoking.
Thank you for this post.
Seek mental stability, or whatever mental state that can push you to programming for 10 years without completely burning you out. If you can’t even do some programming after a relatively easy work day, you are burnt out.
BTW ^ is my state nowadays.
https://web.archive.org/web/19980206223800/https://www.norvi...
With all the “AI” has made coding/learning to code a dead end and unnecessary crud being peddled currently I don’t know if people who want to actually learn to program are going to find resources that can be as motivating as this and other articles from `the before times`. It leaves me slightly bummed out, but in my less pessimistic moments I think motivated learners are going to see through the hype and find these types of resource anyway.
On a side note, the Norvig’s articles about implementing a Scheme in Python were my first foray into designing and implementing programming languages, compilers, and interpreters which really shaped my interest all the way through to today.
1) http://www.catb.org/~esr/faqs/hacker-howto.html
Everyone around me codes with AI, and most of them produce better results than I do. That's natural. I'm good at some things, but I'm bad at many others. I still hand-code occasionally, but now the main is AI coding, and hand-coding is the sub.
This document probably held true until about 3 or 4 years ago. But since last year, I'm not sure. I have nothing to say other than 'Just do it.'
People say vibe coding has security issues, but honestly, I have security issues in my own code too, from TTL and all that. In the end, with vibe coding, knowing the right security keywords and understanding the problems seems to come from experience anyway.
Reading 'So You Want to be a Programmer,' I feel like conversations with other programmers and the whole process of being a programmer feel distant to me now. Since AI came out, I barely talk about programming with other programmers.
It's not just me—most Korean programmers around me are the same. The reason is simple: those kinds of programming discussions make us realize how limited our knowledge is, since our understanding is often filtered through English sources and then translated into Korean. So we just end up not talking to each other about it.
When I saw this document about 4 or 5 years ago, it felt like it was absolutely true. The environment has changed drastically, and reading this again now. Back then I treated it like a Bible, but not anymore. I realize that if you don't have a degree or aren't a native English speaker, there was always a limit to how much you could participate. These days, everything is changing so fast. As AI breaks down the English barrier, the quality of materials I can read has gone up, and I'm starting to think that even programming mindsets might change depending on language background.
But if I were to advise someone starting programming from scratch today, I'd probably just tell them to learn through vibe coding and get familiar with programming keywords and black-box coding.
Vibe coding has become the baseline these days. The domains individuals need to handle have become so broad that it's gotten more complex.
In the past, being good at just one domain was enough to make a living. But these days, everyone wants to become a full-stack developer—something that used to be rare. Even then, full-stack developers had a clear front-end or back-end bias, with some areas being shallow and others deep. Now, people are expected to be good at everything.
If you want to become a true expert, I'd say keep hand-coding and focus on a single domain. But if not, I'd say just go all in on vibe coding. Use it a lot, and build your own worldview through it
The feeling of hand-coding and vibe coding is so different that I can't help but tell people to practice both. They complement each other, but they don't really feel like they're connected or intertwined. They rely on different kinds of intuition.
Still, I think I'll keep hand-coding. Not because it's more productive, but purely because I enjoy it as a hobby. AI writes better code than I do, but hand-coding is still enjoyable enough as a hobby
Programming with AI enforces some good disciplines, which were always true, but could be avoided doing it by hand. Most importantly: you are shipping your tests. If you don't have reproducible automated tests then it probably doesn't work.
The reason is that the compiler's mechanical contract is 'deterministic.' AI, on the other hand, is 'probabilistic.' No matter how much you specify the same situation and details, it doesn't produce 100% identical results.
Abstraction should fundamentally share the same axis of change, but AI doesn't do that. And human code typically starts small, adjusts bit by bit, and refactors as requirements change or scale grows to realign the axis of change. AI's abstraction is fundamentally different from what humans create.
Of course, it can depend on the 'workflow.' If you work in small function units, it can act similarly to a deterministic system. But fundamentally, the market's expectation for natural language AI coding is based on 'large codebases.' Since it's not a codebase understood by a human, it effectively creates an abstraction that's different from my cognitive abilities.
The problem is that AI's abstraction varies from project to project. This is undeniably black-box coding. Sure, you can review it if you know how to read code, but my view differs from yours.
I don't think this is a new abstraction layer. I see it as a technique for controlling blast radius. Of course, you could review the entire codebase while working, but considering the recent vibe coding trend, where people only check core P0 and P1 parts and let AI generate the rest freely, it's even more clear that the focus is on scaling to sizes that humans couldn't handle before.
Of course, my perspective differs from yours, and I think you're a far better programmer than I am.
That's why I think hand-coding and vibe-coding share only the surface-level axis of producing an output, but the cognitive instincts they demand are completely different.
The core of vibe-coding is essentially predicting which part of the black box, if it breaks, would be most critical to the system, and isolating the blast radius. Hand-coding, on the other hand, is fundamentally about surveying the entire system, and definitively controlling and designing every control flow and state change.
In other words, one is an area of 'auditing,' giving up direct control in favor of managing risk, while the other is an area of 'creation,' shaping logical consistency from 0 to 1.
I imagine you also have experience as a PM.
A project manegaris a different profession from a programmer. It requires programming experience, but it's fundamentally a different role. In my view, vibe-coding is essentially a career transition toward being a PM. But separate from that, I don't think this is simply a new abstraction layer. I've seen enough cases where the same prompt and same environment produce different results
To assume the current cost of Claude Code and the like is largely fixed is not likely to be accurate. The economic incentive to lower the cost of ML compute at both training and inference is very strong -- and likely even stronger once the bubble bursts.
Once the compute cost is much lower, and the systems more advanced as well, then the future of programming changes. The role of the human in this may be more like: we need one senior experienced full-stack, and like 1-3 others, to build and maintain large complex apps reliably.
The distinction I see now is between teams that read PRs and teams that don't. I still think the former is a good approach... for now, but I don't expect this will necessarily be the case in a year (or less).
This article was such an inspiration to me when I was younger, and the advice, for that time, was very correct. However seeing it today really drives home how big the gap is going to be in really understanding code in just a few more years.
I hear this from time to time. But I still write code at my job. I'm not a software engineer and I don't work for a software engineering firm.
The original sin of the programming industry is not valuing expressive notation and expressive programming languages. (I am not talking about map/filter/reduce level party tricks but better metaprogramming and coherent abstractions). No amount of sacrificing tokens for Anthropicus is going to give you the same amount of understanding as writing the program.
Reading the code does not give you the knowledge of the 10 different approaches you would have tried and failed before coming up with that code. Why exactly a piece of code is the way that it is cannot be determined by just reading the code.
Reading a mathematical proof does not give you any meaningful understanding of it.
If you are experienced, attentive, curious, willing to explore, etc., that doesn't change after an LLM allows you to deeply discuss any concept at will, quickly try different prototypes and zone in on the correct implementation. You will use these tools to their full extent.
> Why exactly a piece of code is the way that it is cannot be determined by just reading the code.
If you maintained a good commit history and your code is self-documenting and you're not capable of understanding and navigating code you read, you can still literally just ask the LLM to explain the code within the context of the codebase. They are extremely good at that exact task. They will give you as much as you give them. If you want to know, and can understand, the nitty gritty, you can do that and no one is stopping you.
> Reading a mathematical proof does not give you any meaningful understanding of it.
Again: these things can function as personal tutors. Run the proof through an LLM and ask it what you care about. Furthermore, there are plenty of elegant proofs you can read which confer "meaningful" understanding.
Before just assuming that everyone telling you these tools are useful is less capable or experienced than you, it's worth considering if it's actually you who needs to maintain an open mind and attempt to learn from others.
> A lot of the time, I'm writing code that no LLM has seen before
I hear this tired point over and over from people who cannot fathom that others who use LLMs successfully could possibly also be working in a specialized domain. Frontier models are excelling at difficult, long-horizon tasks now. I write all sorts of esoteric stuff, and I can confidently hand a frontier model specification for a language it's never even seen before, working in a domain it's never encountered, and likely get good results, provided I have the knowledge and experience to guide the model.
The reality is that this "they are only good at things they have 'seen before'" talking point that often gets parroted is vaguely defined and largely based in opinion. Obviously, models perform worse when the input or expected output are out of distribution.
But this was much more true a couple years ago than it is today; the gap has closed considerably, and those who are learning to think deeply with these tools will be better positioned than those who arrogantly think that their process cannot be augmented by the most intelligent systems ever created.
Anthropic intentionally missed the opportunity to show that its models can develop really good native applications.
OpenAI’s latest desktop applications seem to be worse than before too.
1) By the time I’ve determined, and expressed to my satisfaction, exactly what I want, I’ve already done the hard work of coding that thing. The rest is fairly mechanical by comparison.
2) It’s a universal truth (which I know someone’s gonna argue with :D ) that reading and working with other peoples’ code is much less fun than reading and working with your own. This applies even if the other people are robots.
3) When checking and troubleshooting code, the bulk of the time is spent understanding it in the first place. If you wrote the code yourself this already implicitly happened and is ‘free’.
Put those four[1] things together and at least for me personally, AI-assisted coding isn’t a better experience than just doing it myself. It’s still great for bootstrapping yourself into a new unfamiliar language/environment though.
[1] Yeah it’s an off-by-one joke. ;)
There are HS interns at my company who admire me because I lived through a time without AI and I actually had to learn that stuff. I’m not kidding.
A linked-in post on CS enrollment at universities:
https://www.linkedin.com/posts/eric-pop_has-computer-science...
"In the past two years, the drop was ~20% at UC Berkeley and ~30% at UC Davis, while UC San Diego is the only one still rising."
On the other hand: LeetCode traffic rankings are up, so some people still solve programming problems by hand - or they hope to get a job, by being able to solve them.
https://www.semrush.com/website/leetcode.com/overview/
I think this is a confusing time. It will probably take a while, until things become clearer.
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/
Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=44697007 - July 2025 (102 comments)
Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=39001755 - Jan 2024 (302 comments)
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 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)