Boring tools win: why experienced programmers distrust frameworks and rewrites

The Short Version

Experienced programmers in these conversations keep landing on the same advice: pick tools you know, learn them deeply, and spend your effort on the product instead of on the stack. Pieter Levels runs profitable businesses on PHP, jQuery and SQLite and suspects that some popular frameworks are pushed by money more than merit [1]. Guido van Rossum says no one can predict which technology will last, so accept an imperfect choice, keep a plan B and do not overthink it [2]. ThePrimeagen argues for knowing your tools well enough to avoid detours, and for understanding old code before replacing it [3]. The FFmpeg and VLC maintainers will use a new language for new projects but warn against rewriting working software [4]. None of them is against trying new things; what they distrust is switching as a substitute for shipping.

Table of contents

What They Said

Pieter Levels: the stack that stays the same

Levels builds everything with vanilla HTML, JavaScript with jQuery, PHP and SQLite [1]. He never got around to learning Node.js because his projects kept growing, and his reason for staying is short: PHP "just stays the same and works." [1] With that stack he has built and launched over 40 startups, mostly alone [1]. Interior AI made $10,000 to $20,000 a month within a week and still makes $40,000 to $50,000; Remote OK, his remote job board, peaked around $140,000 a month in 2021 [1].

In what he calls his most controversial take, he suspects heavily funded JavaScript frameworks push developers toward expensive hosting platforms and pay influencers to promote them [1]. This is his suspicion, offered as such, and Fridman's response is measured: he agrees there is value in questioning conventional wisdom and wants real data on developer speed and happiness across frameworks, even proposing to build the same page in several frameworks himself [1].

The same pragmatism covers the rest of his kit. Levels insists tools matter less than knowing them well, works on one MacBook screen on a couch, and joins Fridman in warning against gear acquisition syndrome [1]. Fridman adds his own lesson from podcasting, that a single light and simple equipment work fine because the content is what matters [1].

What the simple stack buys him is speed. Without funding he has to move fast, so he launches within about two weeks and checks whether people will pay [1]. One product started as just an HTML page, a Stripe payment link and a Typeform for photo uploads [1]. His operations are equally plain: cron jobs, health-check pages with green or red emoji, and errors sent to Telegram [1]. He deploys straight to production, live in seconds, with around 37,000 commits in 12 months. "I'm gonna be canceled for this," he jokes, but it lets him fix reported bugs within minutes [1].

Levels is not hostile to new technology. His AI businesses began by playing with Stable Diffusion when it appeared [1]. The new thing went into the product; the plumbing stayed old.

Guido van Rossum: you cannot predict the winner, so stop trying

The conversation with Python's creator starts from Fridman's own regret. He recalls investing years in ActionScript, Flash and Java applets, and describes the problem every programmer faces: the community's signal is noisy, people get excited about new tools year to year, and you have to guess whether a tool defines a generation or "is this just a fad that will pass" [2]. On whether to drop PHP for something newer, Fridman voices the conservative case himself: "Why fix something that's not broken?" [2]

Van Rossum's answer has three parts.

First, replaced technologies are not wasted. In most cases the particular technology is eventually replaced, he says, but many of the concepts it introduced are preserved; nobody uses Java applets anymore, but reactive web pages have not gone away [2]. The technology that was thrown away was often essential to get started: "There wouldn't be jet planes without propeller planes, I bet you." [2]

Second, nobody could have known. Looking back 20 years you might say a detour was a waste of time, "But nobody could know that." [2] He cautions against building a spreadsheet to predict lifetime earnings from a language choice, since the inputs cannot be measured [2].

Third, the advice itself: accept that not every choice will be perfect, keep a plan B in the back of your mind, and do not overthink it [2].

His own career shows the conservative instinct applied to a codebase. When he started Python he wanted something working in about three months, so he cut corners and wrote code as simply as possible [2]. When operating systems added threading, the team did not want to rewrite the whole interpreter to be thread safe, and the global interpreter lock was the result; he still calls it a pretty nice Goldilocks point [2]. Python 3.11 got 10 to 60% faster without a just-in-time compiler, through work on the existing interpreter [2]. And the lesson he draws from the painful Python 2 to 3 transition, which the team says it underestimated, is that there will not be a Python 4 anytime soon [2].

He also models slow tool changes personally. He used Emacs from the early 1980s until about two years before the conversation, and compares it to a comfortable Toyota with 100,000 miles, against PyCharm as an 18-wheeler [2].

Van Rossum adds a qualification that keeps this from being a rule against novelty. Young people should try unusual things: nine times out of ten you learn why everyone else does it differently, and one time out of ten you discover something better [2].

ThePrimeagen: know your tools, and understand code before you replace it

Michael Paulson, who spent about ten years at Netflix, makes the case from daily practice [3]. Knowing his tools deeply means fewer "side quests," so he can write a thousand lines on a plane without looking anything up [3]. He limits editor tweaking to about once a year to avoid endless tinkering [3]. His broader point is that if you spend 50,000 hours programming, you should know your editor deeply, whatever it is [3].

On rewrites he tells a story against himself. He stresses learning why existing code was written a certain way before rewriting it, and recalls deleting a colleague's odd-looking code in the Falcor data-fetching library, only to reproduce it almost line for line: "I am the idiot in the situation." [3]

He is also skeptical of the evidence people use to justify switching. A benchmark showing Zig beating other LLVM-based languages, he explains, mostly reflects how the code was written, not the language [3].

Paulson is the least conservative of the four about languages. He suggests everyone explore a dynamic language, a strict one and eventually a functional one, uses Go as his workhorse for web backends, and experiments with Zig and Jai [3]. He recommends building things from scratch, like an HTTP server, when you want to truly understand a concept, and wants a tech culture where it is okay to reinvent the wheel to learn [3]. His method for a new language is itself a form of depth over novelty: read the entire language reference first, eight to ten hours for Zig, so you have a mental index of what is possible, then build [3].

Jean-Baptiste Kempf and Kieran Kunhya: new code has to beat what exists

The FFmpeg and VLC maintainers face the rewrite question in its sharpest form, as the suggestion that their C and assembly should move to Rust.

Kunhya values Rust's memory-safety goals but says the language has an "Esperanto vibe." [4] He compares it to the Sinclair C5: to get people to switch, something has to be as good as or better than what exists [4]. He would welcome Rust in FFmpeg if it meets the same testing and stability bar [4].

Kempf speaks as someone who uses the newer tool. His startup Kyber is written mostly in Rust, and he says it is excellent for new projects, but he warns against rewrites, since reading code is far harder than writing it [4]. He adds that pairing Rust with handwritten assembly breaks the safety model [4].

Their caution reflects what the existing code already does. FFmpeg's SIMD assembly typically runs 10x to 50x faster than C, and the AV1 decoder dav1d, whose motto was "every cycle matters," contains roughly 30,000 lines of C and 240,000 lines of handwritten assembly [4]. FATE, FFmpeg's testing system, enforces bit-exact output across a huge matrix of operating systems, compilers and CPU architectures [4]. VLC still runs on everything from Windows XP to Windows 11 [4].

It also reflects who has to live with the result. The core community of FFmpeg is 10 to 15 people, and most contributors do not stay, so the maintainers hold a high bar for anything added: "It needs to be maintainable. It needs to be excellent." [4]

Where They Agree, and Where They Don't

They agree that depth in a tool beats the choice of tool. Levels says tools matter less than knowing them well [1]. Paulson says to know your editor deeply, whatever it is [3]. Van Rossum drove the same editor for decades [2].

They agree that working software deserves respect. Levels will not replace a stack that works [1]. Van Rossum would not rewrite the interpreter for threads and will not repeat a Python 3-style break [2]. Paulson learned to ask why code exists before deleting it [3]. Kempf warns against rewrites outright [4].

They agree that the reasons given for switching are often weak. Levels points to funding and paid promotion behind frameworks [1]. Fridman calls the community signal noisy [2]. Paulson says language benchmarks mostly measure how the code was written [3]. Kunhya says that for people to switch, the new thing has to be as good as or better than what exists [4].

They agree that new technology is fine in its place. Levels built on Stable Diffusion [1], van Rossum tells young people to try unusual things [2], Paulson experiments with Zig and Jai [3], and Kempf wrote a new company in Rust [4].

They differ on how much exploring to do. Paulson recommends learning several kinds of language and reinventing things to learn [3]. Levels never got around to Node.js and treats that as no loss [1]. The difference follows their goals: Levels is describing how to ship a business alone [1], Paulson how to grow as a programmer [3].

They differ on what simple practice suits a team. Paulson admires Levels's push-straight-to-production style for a solo developer but says it would not work at a company with hundreds of engineers [3]. The FFmpeg maintainers rely on exhaustive testing before anything is accepted [4].

They differ on whether language choice matters at all. Van Rossum says not to overthink it [2], yet he would recommend TypeScript over plain JavaScript because strict typing helps you keep your head straight about what your code does [2]. Fridman pushes back in the same conversation, saying there really are better and worse choices of programming language for a given person [2].

Why It Works

Stable tools let knowledge compound. A stack that stays the same means nothing has to be relearned [1], and deep familiarity removes the detours Paulson calls side quests [3].

Old code holds knowledge that is not written down. Paulson's deleted code came back almost line for line because the original author had already solved the problem [3]. Kempf's version of the point is that reading code is far harder than writing it [4].

Existing systems carry years of testing and compatibility. FFmpeg's bit-exact tests across platforms and VLC's support for old operating systems are assets a rewrite would have to earn again [4]. Python's C extensions, which power essentially all of data science and machine learning, are why any break would need years of warning [2].

The future is unpredictable, so analysis has low returns. Van Rossum's argument is that the inputs to any forecast of a language's value cannot be measured [2].

Constraints speed things up. Levels's 12 startups in 12 months forced him to cut features to fit a month, and he concludes more broadly: "I think constraints probably make you happy." [1]

Incentives behind new tools are not always the user's. This is Levels's claim about funded frameworks and hosting platforms, and he presents it as a suspicion, not a finding [1].

The evidence throughout is experience: Levels's revenue on an old stack [1], Python's three decades and its hard-learned transition [2], Paulson's Netflix stories [3], and FFmpeg's performance numbers [4]. Fridman's wish for real data on frameworks is a reminder that nobody here cites a controlled comparison [1].

Where It Applies, and Where It Doesn't

The advice fits solo builders and small teams who need to ship and validate quickly [1], long-lived codebases with many dependents [2][4], and anyone tempted to rewrite code they do not yet understand [3].

It fits less well in four cases the sources themselves raise. New projects are a fair place for a new language, as Kempf's Kyber shows [4]. Learning is a fair reason to try something unfamiliar or rebuild something that exists [2][3]. Some newer tools are simply recommended: van Rossum prefers TypeScript to plain JavaScript [2], and he moved to VS Code after decades on Emacs and liked it [2]. And a new tool that clears the existing bar is welcome, which is Kunhya's stated condition for Rust in FFmpeg [4].

Boring does not mean frozen. Van Rossum's team made Python much faster by improving what they had [2], and FFmpeg's maintainers keep writing new assembly for new codecs [4].

Sometimes the old way does lose. Fridman's years in Flash and ActionScript did not transfer, and he describes leaving C++ for Python as difficult but driven by asking which language he is more productive in [2]. Van Rossum's point is only that you could not have known in advance [2].

What To Do With It

1. Start with the tools you already know. Levels's stack is the one he learned first, and it carries every product he sells [1].
2. Launch before you optimize the stack. A page, a payment link and a form were enough to test demand [1].
3. When choosing a technology, set a limit on deliberation. Accept that the choice may be imperfect, keep a plan B, and move on [2].
4. Go deep on one editor and one language. Paulson's test is whether you can work for hours without looking anything up [3].
5. Cap the time you spend tuning your setup. Paulson limits editor tweaking to about once a year [3].
6. Before rewriting code, find out why it is the way it is. Paulson's Falcor story is the warning [3]; Kempf's rule is that reading is harder than writing [4].
7. Hold any new language or framework to the existing bar. It should be as good as or better than what is there, with the same tests passing [4].
8. Use new languages for new projects, not for replacing working ones. That is how Kempf uses Rust [4].
9. Be skeptical of benchmarks and of enthusiasm. Ask whether a comparison measures the tool or the way the code was written [3], and who benefits from the recommendation [1].
10. Experiment on the side, especially early in a career. Van Rossum expects most experiments to teach you why the standard way is standard, and a few to turn up something better [2].

Sources

1. Pieter Levels on Building Solo Startups, Photo AI, Simple Code and Digital Nomad Life · Lex Fridman Podcast
2. Guido van Rossum on Python 3.11's Speedup, Type Hints, the GIL and the Future of Programming · Lex Fridman Podcast
3. The Primeagen: Programming, AI, ADHD, Productivity, Addiction, and God · Lex Fridman Podcast
4. FFmpeg and VLC with Jean-Baptiste Kempf and Kieran Kunhya: Codecs, Assembly, and the Volunteers Behind Internet Video · Lex Fridman Podcast