Someone posted a tone generator on Hacker News. Just a website that makes beeps. You pick a frequency, it plays a sine wave. That’s it. No accounts, no AI, no blockchain, no pitch deck. A digital fork stuck into a wall outlet of pure simplicity.
And then the comments section exploded into a physics lesson that made half the internet realize they’d been wrong about something their entire lives.
The simplest tools don’t simplify the world. They expose how complicated it actually is.
Here’s what happened. Someone mentioned mains hum — that low, buzzing drone you hear near transformers, old electronics, badly shielded guitar amps. You know the sound. You’ve heard it a thousand times. Most engineers, musicians, and audio nerds will tell you it’s 50Hz or 60Hz, depending on where you live. Europe? 50Hz. North America? 60Hz. Case closed.
Wrong.
Mains hum is not 50Hz. It’s not 60Hz. It’s 100Hz or 120Hz. Always has been.
The reason isn’t some obscure electrical engineering footnote. It’s a phenomenon called magnetostriction. When a magnetic field is applied to a material — say, the iron core of a transformer — that material physically changes shape. It expands and contracts. But here’s the catch: it doesn’t care about polarity. It only cares about amplitude.
An AC waveform crosses zero twice per cycle. It hits maximum amplitude twice per cycle. So a 50Hz current doesn’t vibrate the core 50 times per second — it vibrates it 100 times. The hum you hear is double the line frequency. Always.
Your ears have been hearing 100Hz your entire life, and your brain has been filing it under 50Hz. The tool didn’t create new knowledge. It just gave someone a reason to say it out loud.
That’s the real story here. Not the tone generator. The tone generator is almost irrelevant. It’s a sine wave player. You could build one in ten lines of Python. Someone in the comments even pointed that out: “Your next mission: code it yourself like they did in the 1970s.”
And that’s the thread that ties this whole thing together. In the 1970s, computing was hands-on. You didn’t download an app. You didn’t open a browser tab. You sat down with a manual, some registers, and a speaker, and you made it beep. The beep was the point. The beep was proof that you understood the machine.
Somewhere between then and now, we traded that exploratory spirit for convenience. We got APIs and frameworks and abstractions layered so deep that most developers couldn’t tell you what frequency their electricity hums at — let alone why.
And then someone drops a tone generator on a feed full of people arguing about AI agents and billion-dollar valuations, and the most upvoted comment is a physics correction about magnetostriction. Another comment simply reads: “I am making music right now.”
That’s not a tool. That’s a catalyst.
The best artifacts aren’t the ones that do the most. They’re the ones that make you do something — think, argue, build, remember.
We’ve been conditioned to evaluate tools by their feature lists. How many endpoints. How many integrations. How many parameters in the model. But the tone generator has zero features worth bragging about, and it triggered a better technical discussion than most product launches on the front page of any tech publication this year.
Because it didn’t try to teach anyone anything. It just sat there, making a sound, and waited for someone to notice what was missing from their own understanding.
The lesson isn’t “build simple tools.” The lesson is that knowledge transfer doesn’t happen through documentation. It happens through friction. Through someone saying “actually, that’s not quite right” in a comment thread. Through the gap between what you assume and what’s true.
A tone generator can’t teach you about magnetostriction. But it can create the moment where someone else does.
And maybe that’s what we lost when we stopped coding things ourselves in the 1970s — not the skill, but the moments where being wrong in public was the fastest way to learn something real.
FAQ
Q: Isn't this just a trivial detail about transformers? Who cares?
A: If you design audio equipment, shield electronics, or work in power systems, this 'trivial detail' determines how you filter noise. If you're a musician, it explains why your amp buzzes the way it does. The detail is trivial only to people who don't build things.
Q: What's the practical takeaway for builders?
A: Stop optimizing for feature density. A tool that does one thing and invites correction, experimentation, or nostalgia will generate more engagement and knowledge transfer than a bloated platform that tries to anticipate every use case.
Q: Isn't this just nostalgia for a time when computing was harder?
A: No. It's nostalgia for a time when computing was honest — when you couldn't hide behind abstractions and the distance between your assumption and reality was one beep away. The difficulty wasn't the point. The immediacy was.