Variable Roulette: I Handed My Side Project's Repo to the Internet for Seven Days

Last month I did something that made a friend of mine physically wince: I put my active side project on the internet with write access open to anyone. Not a fork. Not a suggestion box. The actual repo, main branch, no review required.

The project is a small scheduling tool I've been building for my rec league softball team — nothing precious, but seven months of my evenings live in that codebase. For seven days, it belonged to strangers.

Here's the lab report.

The Rules (There Were Almost None)

I set up a fresh deploy, posted the repo link on a couple of Discord servers and a Reddit thread, and wrote exactly three rules on the README:

1. Don't delete the deploy script.
2. Leave a one-line note in CHANGES.md explaining what you did (this rule lasted about four hours).
3. You can't claim authorship later. This is a lab, not a portfolio.

That's it. No linting gate, no required PR template, no code owners file. I wanted maximum chaos with a paper trail, and the paper trail turned out to be the most valuable part of the whole experiment.

The Naming Hall of Shame

Let's just get right to it, because I know that's why you're here.

• handleUserLogin() became doTheAuthThing()
• A 40-line function that validates schedule conflicts was renamed to vibes()
• Someone added a constant const MAGIC_NUMBER = 7 with no comment. It's the number of days in a week. I checked. The scheduler already knew how many days a week had.
• A boolean flag called isReady got flipped to isntNotReady. Double negative. It worked.
• My most-used utility, formatDate(), now has a sibling called formatDateButForReal() that two different contributors depend on.

My personal favorite: someone renamed the entire utils directory to stuff and updated zero imports. The build broke for eleven minutes until a different anonymous stranger fixed it, left the message "my bad, saw it broken, fixed it," and vanished forever. That's the internet working as intended, honestly.

The Part That Actually Hurt: Onboarding Friction

Once I stopped laughing (day two, roughly), I started noticing a pattern in the CHANGES.md notes. A ton of the rename chaos wasn't trolling. It was confusion.

People renamed things because they couldn't figure out what things did. processEntry() doesn't tell you anything. handleData() tells you less than nothing. When a stranger with zero context hits a function like that, they either guess or they rename it to match their guess. About 60% of the "crime scene" commits were people documenting their own confusion in code form.

That's a free usability study I would have paid for. Every rename was a UX bug report filed against my own naming conventions.

The Crimes That Were Secretly Upgrades

Here's the uncomfortable part: I kept eleven of the changes. Permanently.

Someone flattened my deeply nested retry logic into a clean early-return pattern that I've now stolen for two other projects. A different person split a 300-line module into three files with names so obvious I felt embarrassed. One contributor added a two-paragraph comment above the scheduler explaining daylight saving time edge cases — something I'd been avoiding thinking about for months, and they were right to force the issue.

The best keepers shared a trait: they all made the codebase easier for the next stranger. Which is also what makes it easier for me, two weeks from now, when I've forgotten everything.

What I'd Do Differently

Three tweaks if I run this again:

• Branch protection, but only for the deploy script. Rule #1 got violated twice and cost me a Saturday morning.
• A glossary file. Ten minutes of writing "what things mean in this repo" would have cut the confused renames in half.
• A required commit prefix, like CHAOS: — not to gatekeep, just to make the archaeology easier afterward. Sifting through git log for changes titled "oops" and "ok now for real" got old fast.

Would I Do It Again?

Yes, and I plan to — next time on a project with actual users, which is either braver or dumber, I haven't decided.

The honest takeaway: my codebase wasn't as readable as I believed, and the fastest way to find that out was to hand it to people with no stake in being polite about it. Every side project has a gap between what the code says and what the author thinks it says. Strangers close that gap in about forty-eight hours.

The repo is back under lock and key now. vibes() stays. I've grown attached.