Why I Stopped Overthinking "Fair" Random Selection (And Why You Probably Should Too)

Last month, I got pulled into a Slack conversation about selecting team members for a rotation. Someone suggested a "proper" solution: seed-based RNG, audit logs, cryptographic hashing. I watched this conversation spiral for two hours. By the end, we still hadn't picked anyone. That's when I realized: we were solving the wrong problem.

The original problem wasn't technical at all. It was social. We needed people to believe the process was fair, and we'd gotten so caught up in tooling that we'd lost sight of what actually builds trust. That's what drew me to this article—because it takes a question that sounds trivial on the surface and peels back the layers of what "fairness" actually means in practice.

The Credibility Problem Nobody Talks About

Here's what most developers get wrong about randomness in non-cryptographic contexts: we think the algorithm matters more than transparency. It doesn't. I've seen teams build elaborate systems with proper RNG seeding and audit trails that still got questioned because nobody in the room understood the process.

The article nails this early: a draw is only trustworthy if the audience can understand and reproduce it. That's not a technical constraint—it's a social one. This changes how you should approach the problem entirely.

When your team is twelve people and you're picking who reviews the next PR, pulling names from a hat works fine. Everyone watches. Everyone understands. There's no hidden algorithm to question. When you're running a company-wide giveaway in front of fifty people on a livestream, the same approach becomes impractical and actually breeds suspicion—people wonder if the host did something clever with how they shuffled.

Three Real Approaches, Three Real Trade-offs

The physical method (slips of paper, actual shuffling) has advantages we've forgotten in the era of digital everything. There's genuine transparency. There are zero dependencies. But it scales terribly, and you can't easily add weights or maintain historical records. I've used this for small team decisions and it works beautifully—fast, no setup, people relax. Try it with three hundred entries and suddenly you're running a raffle with operational overhead.

The spreadsheet approach hits the practical middle ground for most recurring workflows. Sort by a RAND() column, keep metadata columns for timestamps and pool state, export to CSV for reporting. This is what I actually use in production for things like sprint planning randomization or load-balancing decisions in testing. The downside is documentation—non-technical teammates need explicit instructions, and there's always someone who'll ask if Excel's RNG is "random enough."

Purpose-built tools (web-based spinners, dedicated pickers) solve the friction problem for public-facing draws. The psychology matters here—people expect animation and interaction. A boring list selection feels suspicious in ways that a wheel spinning doesn't, even if the underlying mechanism is identical. For hackathon team draws or community events, this is worth the minute of setup.

My Take: Choose Process Over Perfection

I think the article's core insight is this: the tool should match the context, not the other way around. I've watched engineers reach for "proper" solutions when a simpler one would work because we're trained to think "more sophisticated" equals "better."

Here's where I'd push back slightly: the article emphasizes audit trails and reproducibility, which matter for compliance scenarios. But for most internal team workflows, you're optimizing for the wrong metric. You should optimize for whether people believe it was fair, and that's often cheaper and simpler than you think.

The real decision framework isn't "How do I implement the best RNG?" It's: "Who needs to trust this, and what process will convince them?" Those are different questions entirely.

The Practical Reality

In my Islamabad-based team, we've mostly landed on lightweight spreadsheets for repeating draws and physical methods for one-off decisions. We save the web tools for client-facing giveaways. The key insight from all of this is that you should spend more time thinking about the decision criteria (pool size, frequency, audience size, stakeholder skepticism level) than debating implementation details.

What Would You Do Differently?

Here's my question for you: what's a randomization process you've built or questioned recently? Did you find that the technical solution you chose actually addressed the real concern, or were you solving a problem that existed somewhere else?

Source: This post was inspired by "Picking a Random Name From a List: A Practical Decision Guide for Engineers" by Dev.to. Read the original article