Percentiles Are a Low Bar—Here's Why
The claim that reaching 95%-ile is easy sounds elitist at first. But the opposite is true: for most activities, most people can get relatively good without exceptional talent. The key qualifier is that 95%-ile here means among participants, not the general population—and definitely not among people who practice deliberately. For many activities, being roughly 10%-ile among those who practice can place you at 90%-ile or higher among everyone who participates.
Abstract discussions of this idea tend to devolve into Rorschach tests. Scott Adams' widely cited argument that you should be 75%-ile at two things rather than extraordinary at one is a good example—taken literally, the claim is silly, so conversations about it inevitably fall back on priors rather than evidence. Concrete examples are more productive.
Overwatch: A Case Study in Basic Mistakes
In Overwatch, players at 90%-ile and 95%-ile constantly make game-losing errors—like standing next to the objective instead of on it while the match timer runs out. This isn't a matter of talent. Most players at those ranks have put in hundreds of hours, yet still make mistakes that are simple to identify and fix once pointed out.
Why does this persist? Four common explanations:
- People don't care about winning
- People haven't practiced enough
- People lack talent
- People don't know how to spot their own mistakes
The first explanation doesn't hold up. By 30%-ile, players regularly express frustration at teammates perceived as uncaring or unskilled—they clearly want to win. The second fails too: players stably ranked at 50%-ile have typically invested hundreds of hours, and the mistakes in question are simple enough that time alone should have fixed them.
The third explanation—lack of talent—is a common complaint on forums, but it's largely misplaced. You don't need extraordinary talent to fix a mistake like "stand on the objective."
The fourth explanation is the most compelling. Many players never review their own gameplay. Overwatch even provides built-in tools: kill cams that show how you died from the attacker's perspective, and full-game replays. Other games often require separate recording software. Despite this, forum posts regularly appear from players who have spent 1,200 hours stuck at 10%-ile. When they finally post a video, feedback from other players immediately helps them improve—sometimes moving them from 10%-ile to 40%-ile in a short time.
This pattern—wanting to improve, not seeking feedback, and improving quickly when feedback arrives—persists well into the 95%-ile and above.
Real-World Activities Are Harder to Optimize
Games with rating systems have a clear objective: increase your rating. Any specific mistake—like not stepping onto the objective—has a measurable impact on your win rate. Real-world activities lack this clarity. "Being a good speaker" could mean giving informative talks, entertaining talks, prestigious keynotes, or paid appearances. Each goal demands different strategies, and it's unclear how a given mistake (like spending 8 minutes of a 20-minute talk introducing yourself) affects each one.
Games also benefit from a large community of enthusiasts who have figured out what works. Want to be 99%-ile at bridge? Learn the basics, read a beginner book on cardplay, and practice applying it. Want to be a good speaker? There's no such straightforward path—great speakers give directly contradictory advice, and few people obsessively improve, so rigorous curricula are scarce. Ironically, this means it's easier to climb percentiles in real-life activities because so few people are even trying.
Consider table tennis. A local bar hotshot who beats every random challenger might be 99%-ile, but someone with no talent who practices at a club two hours a week will have a serve you can't return. Most real-life activities lack even that level of deliberate practice.
Deliberate Practice Works, Even With Imperfect Methods
Even mediocre feedback methods can yield dramatic results when the baseline is near zero. Helping a speaker prepare from 2013 to 2017, the first practice talks were average for a large tech conference. The speaker then did roughly 30 practice runs per public talk, with feedback on half. The first public talk was well above average, and subsequent talks improved further.
Most speakers don't practice at all—one conference speaker had only 15 minutes of material for a 40-minute talk the night before. By that standard, 30 practice runs seems obsessive, but it's rational when you consider the audience: a 30-minute talk to 300 people is 150 person-hours of their time. Spending 15 hours practicing is proportionate. And this level of practice pales next to a middling table tennis club player's hours.
This isn't to say the feedback method was ideal. Pedagogy research shows that laypeople helping each other is among the worst improvement techniques, and one-on-one coaching is far more effective. But even a bad method creates enormous relative improvement when most people don't practice at all.
Writing improvement follows the same pattern. In the early days of this blog, feedback came from one partner who also didn't know what was wrong beyond "something looks off." Hiring a professional editor changed things—they provided vocabulary to discuss structural problems, much like design patterns gave names to OO design issues.
Programming Has the Same Pattern
Programming has no rating system, but the same principle applies: recording and reviewing your own work reveals inefficiencies you'd never notice otherwise. Michael Malis found this by recording his screen while coding:
One incredibly useful exercise I've found is to watch myself program. Throughout the week, I have a program running in the background that records my screen. At the end of the week, I'll watch a few segments from the previous week. Usually I will watch the times that felt like it took a lot longer to complete some task than it should have. While watching them, I'll pay attention to specifically where the time went and figure out what I could have done better. When I first did this, I was really surprised at where all of my time was going.
For example, previously when writing code, I would write all my code for a new feature up front and then test all of the code collectively. When testing code this way, I would have to isolate which function the bug was in and then debug that individual function. After watching a recording of myself writing code, I realized I was spending about a quarter of the total time implementing the feature tracking down which functions the bugs were in! This was completely non-obvious to me and I wouldn't have found it out without recording myself. Now that I'm aware that I spent so much time isolating which function a bugs are in, I now test each function as I write it to make sure they work. This allows me to write code a lot faster as it dramatically reduces the amount of time it takes to debug my code.
Watching recordings of your own work reveals pointlessly time-losing habits. Fixing those habits can double productivity, simply by clawing back wasted time. One concrete example: when needing to wait two minutes, reading something distracting leads to losing several more minutes. Keeping a queue of useful work for dead time avoids that trap.
The critical point is to actually track what you're doing. People's guesses about their own behavior rarely match reality. It's normal to operate a complex software system with metrics and tracing, but not to apply the same tools to yourself—even though you're more complex than any software you run.
This productivity boost is orthogonal to choosing the right problems to work on—it's a 2x speedup independent of what you're working on.
Meta-Techniques That Work
Two broadly applicable techniques stand out:
- Get feedback and practice. Ideally from an expert coach, but even a layperson or yourself works if you can record or trace what you're doing.
- Use guided exercises or exercises with solutions. These are easy to find for "old" games like chess or bridge, and in fields like math the Springer Undergraduate Mathematics Series (SUMS) books include problems with solutions.
These aren't novel. Kotov's 1970s books—Think like a Grandmaster, Play Like a Grandmaster, Train Like a Grandmaster—cover the same ideas, because they're among the most obvious paths to improvement.
