Ninad Sachania YouTube channel summaries
Theme: AI lock-in skepticism + niche survival (Tsoding) and anti-bloat, anti-premature-optimization, know-why-not-guess craftsmanship (Blow). Note: most are short clips with auto-generated captions — phrasing approximate.
Tsoding
- How to fight evil AI companies (link)
LLM-only metadata (llms.txt, agents.md) and bloated AI docs = deliberate vendor lock-in + compute rent-seeking. Round-tripping info through LLMs degrades signal like repeated JPEG compression. Fix: don't attack data centers — expose the tricks publicly so people stop playing along. - How to survive as programmer in age of AI (link)
Carve out small quality niches big "slop corpos" won't bother serving — they're slow and bloated. Example niche: fast performance software (File Pilot). Defend it. - Trick to measure code complexity (link)
Count semicolons, not lines. In C-like langs each semicolon ≈ one statement; line count distorts via multi-line formatting. Wren VM "under 4,000 semicolons." Good-enough proxy. - Why he doesn't work on Operating Systems (link)
Not difficulty — format. OS dev = long multi-stream project, but episode 1 gets 1000+ viewers then everyone drops off. Needs self-contained stream-sized hook (idea: "GS kernel" booting to a REPL). - Why he doesn't use Odin (link)
Tongue-in-cheek: scared of the creator, who jumps into chat to aggressively defend Odin on any criticism. Never tried it; "good language" hedge. - Why he doesn't have a job (link)
Money stops motivating once basic needs met. Pre-streaming: freelance gig → save → live off savings. Took office job once; frugal probation salary lasted 6 months, then walked when offered permanent. - Bun's rewrite from Zig to Rust (link)
Rant: rewrite added ~300k lines, Bun now +1M lines. A JS-engine wrapper 3x the size of a full game engine (The Sinking City, +300k). "Literal insanity."
Jonathan Blow
- Fought John Romero over DOOM's asset loading (link)
As a student, raged that DOOM's linear-scan asset lookup should've been a hash table. Romero defended it. Blow now admits he was wrong — profiling showed lookup time negligible; hash table costs more memory/fragmentation/bugs. Use array of records; optimize only on real need. Lesson: when skilled people build something that looks wrong, assume you don't understand why. - Why code size should be small (link)
Bloat self-reinforces: as code grows, understanding erodes → devs add instead of refactor → grows faster. Either spirals or freezes the project. Keep small deliberately, especially in legacy. - How to finish projects (link)
Used to start, never finish. Turning point: named the pattern, then past 30 confronted gap between self-image (does important things) and reality (hadn't). Decided to get serious. - Why the Dragon Book is terrible (link)
Rejects the classic compiler textbook flat — "terrible," learning from it makes you bad at compilers. Maybe OK in 1986, "not even then." Calls universal university assignment "an ethical breach." - How web programmers solve problems (link)
Mocks guess-and-check: throw "stupid things at the wall," keep what works. His philosophy: "We want to know the correct answer... what is right." - Disables Microsoft Defender, huge speed-up (link)
Operation 14s with Defender → ~5s without (≈3x). Offended Windows won't let him permanently disable it. Preempts "you're using it wrong" pushback. - On parallel programming (link)
'90s parallelism techniques were already what's "good" today. Post-'90s "magical" auto-parallelism is worse — a regression masked by decline in programmer expertise. Today's parallelism = '90s tech dressed up as new.
Eskil Steenberg
- Why he doesn't use version control | BSC 2025 (link).
No git — "never gave me anything." Single flat source dir, strict naming so a function's prefix tells its file. Never deletes; wraps dead code in #ifdef DEPRECATED. Occasional dated snapshots, never goes back. Team = independent "library releases," teammates adopt or ignore. "Born C, always C."