YouTube occasionally recommends me math videos, some of which are lectures about a topic, but others of which are just about a single problem in particular. This latter type tends to have the hallmarks of low-effort clickbait, being short in duration and having a thumbnail and title that seek immediate attention, using all the usual clickbait tactics.1 I sometimes fall for this, but not in the way the uploader intends. When a video tries to entice viewers by posing a question in its thumbnail/title, I often treat it as a challenge to answer the question without watching the video. After all,
- I should be able to, provided I think I have the tools.
- I should be able to in much less time than the 5 minute duration of these videos.
Despite today’s overemphasis on short-form content, many videos still manage to waste a surprising amount of time by starting with a ton of front matter and redundant setup and motivation. This is one reason for the excessive length of these math videos, though another reason is sometimes that the maker uses a bad approach to the solution.
Understanding a problem often means that, more than just being able to solve it, being able to solve it quickly2. This rule is not universal but appears throughout mathematics, especially in computer science. Indeed, the difference between the ability to solve a problem and the ability to solve it quickly (in some sense) is the primary motivation for the study of complexity theory and has ramifications for cryptography, etc. I suppose my instinctual insistence on speed here is also partly due to my years spent doing timed problem-solving competitions. I’ve participated in countless individual and team math, science, and computer programming competitions since high school, so many that I don’t remember all their names. The main recurring ones were Mu Alpha Theta in high school and ACM ICPC and IEEE Extreme in college3. In these competitions, having just basic insight about a problem is sometimes enough, but the problem setters usually design it so that a naive solution takes a punishingly long time or is entirely infeasible.
The emphasis these competitions place on speed has downsides, as it prevents setting good but inherently long problems, and it tends to put undue weight on memorized shortcuts rather than deep understanding. It is annoying to lose to someone who has simply memorized one more canned trick than you have, even though your overall understanding of the topic may be superior. Still, my opinion after all these years is that being able to solve a problem quickly is, in most real-world settings, a favorable sign of better understanding. Meanwhile, this sign is weaker in competitive settings, because competitors are tempted to spend less time doing high-quality learning and more time memorizing shallow tricks and drilling the exact form of problems they expect to turn up in competition. But regardless, the mantra of “speed is good” holds both in competitions and in real life.
Say what you like about these clickbait videos, but they do get views, and I bet some of those views aren’t even bots! I’ve decided to start writing up my solutions and publishing them on this blog. Although the ideal audience may be limited to curious high schoolers (assuming they still make those), at least I get to gratify some nostalgia and work on my LaTeX skills.
YouTube thumbnail math posts
- Bright colors, heavy use of exclamation points and question marks, YouTube face ↩︎
- My apologies to TwoSet. ↩︎
- Starting some 20 years ago, I spent a lot of time on HackThisSite, Project Euler, HackerRank, LeetCode, and CodeEval (a similar but now defunct site). Most challenges posed by these sites have some form of time constraint applied to them, even when unlimited time is allowed for thinking about the problem. ↩︎