Boring tools win: why experienced programmers distrust frameworks and rewrites
Pieter Levels ships profitable products with PHP and jQuery, Guido van Rossum advises picking technologies without overthinking it, ThePrimeagen talks about choosing tools, and the FFmpeg maintainers are wary of rewrites. Their shared view pushes back on the habit of chasing new stacks instead of shipping.
Experienced programmers keep landing on the same advice: pick tools you know, learn them deeply, and spend your effort on the product instead of on the technology under it. None of the four voices here is against trying new things. What they distrust is switching tools as a substitute for shipping.
Pieter Levels runs profitable businesses, mostly alone, on plain HTML, older JavaScript, PHP and a simple database. He never moved to newer tools, and his reason is that PHP "just stays the same and works." The simple setup buys him speed. He launches within about two weeks to see whether people will pay, and one product began as a page, a payment link and a form. He suspects that some popular frameworks are pushed by funding and paid promotion more than merit. That is his suspicion, offered as such. He is not hostile to new technology, since his AI products began by playing with a new image model. The new thing went into the product while the plumbing stayed old.
Guido van Rossum, the creator of Python, says nobody can predict which technology will last. A technology that gets replaced is not wasted, because its ideas carry on. Looking back, a detour may seem a waste of time, "But nobody could know that." His advice is to accept that not every choice will be perfect, keep a plan B, and not overthink it. His own team declined to rewrite Python's core for threading and learned from one painful version change not to repeat it. He also tells young people to try unusual things, since most experiments show why the standard way is standard and a few turn up something better.
ThePrimeagen, who spent about ten years at Netflix, argues for knowing your tools well enough to avoid detours. He limits tinkering with his setup to about once a year. On rewrites he tells a story against himself: he deleted a colleague's odd-looking code and ended up reproducing it almost line for line. He is the keenest of the four on exploring new languages to learn.
Jean-Baptiste Kempf and Kieran Kunhya, who maintain the video software VLC and FFmpeg, face the rewrite question directly. Kempf uses the Rust language for a new company and calls it excellent for new projects, but warns against rewriting working software, since reading code is far harder than writing it. Kunhya says a replacement has to be as good as or better than what exists.
They agree that depth in a tool beats the choice of tool, that working software deserves respect, and that the reasons given for switching are often weak. They differ on how much exploring to do and on what suits a team as opposed to a solo builder. The evidence is experience, and nobody cites a controlled comparison.
What to do with it: start with the tools you already know. Launch before you optimize the technology. Set a limit on deliberation when choosing. Go deep on one editor and one language. Cap the time you spend tuning your setup. Find out why code is the way it is before rewriting it. Use new languages for new projects. Be skeptical of benchmarks and enthusiasm. Experiment on the side.