惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Y
Y Combinator Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
V2EX
博客园 - 三生石上(FineUI控件)
Hugging Face - Blog
Hugging Face - Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
罗磊的独立博客
博客园_首页
量子位
雷峰网
雷峰网
GbyAI
GbyAI
小众软件
小众软件
酷 壳 – CoolShell
酷 壳 – CoolShell
D
DataBreaches.Net
H
Hackread – Cybersecurity News, Data Breaches, AI and More
The Cloudflare Blog
IT之家
IT之家
WordPress大学
WordPress大学
人人都是产品经理
人人都是产品经理
Apple Machine Learning Research
Apple Machine Learning Research
P
Proofpoint News Feed
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 聂微东

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
My GitHub was a graveyard. So I deleted 30+ repos
Amarjit · 2026-06-28 · via DEV Community

I started on GitHub in 2010. Last week I sat down and went through every single repo. I had over 60. I got it down to 26, with a few more still to go.

That's over 30 repos gone. Twelve years of commits, side projects, experiments, half-finished ideas - deleted. My earliest commit now shows as 2022. It used to be 2010.

What was actually in there

There were some serious projects in there too, but these are the ones that stood out.

A roulette predictor - though not entirely for the reasons you might think. OK, a small part of me did want to beat the house. But the real reason: I wanted to see it. Everyone knows a coin flip is 50/50, but how do you actually visualise a 35 to 1? Statistics on a page don't do it. So I built a simulation, set it to eye speed, and watched my balance crawl down into the negative millions in real time. Then I cranked it to super speed, ran tens of thousands of games, and every single one ended the same way - if you played long enough, you lost. Every time. No exceptions. The maths were always there, but watching it happen is something else.

Worth noting: I know the ball isn't true random since Python's random module uses a PRNG under the hood, but it's close enough for what I was trying to understand. The house edge doesn't care either way.

A CoinMarketCap scraper - built during COVID when everyone was glued to crypto prices. I wanted to spot the next trending coin before it blew up, so I used an exponential moving average over a rolling window to identify coins with rising momentum, then ran a sentiment checker on top using Google Trends data to see if search interest was following the price. Did I get rich? I did not.

A test download server I used to share files with people on my local network. A Shopify product importer that somehow turned into a full Rust app with a GUI - I was just testing, it escalated. A load of repos where I was kicking the tyres on game engines and programming patterns.

None of it was finished. None of it was structured. Half of it I couldn't even remember writing until I opened it.

The one that actually stung: a lessons and quiz app I built for my daughter to help her with schoolwork. She got A's. I made her sit there and listen while I explained how I built it. Good memories. But the code was dead, the repo was private, and nobody was ever going to open it again, including me.

I deleted it.

Why I kept them for so long

Because deleting felt like losing something. Not just the code. Something more specific.

I know exactly when most of those repos were written. Late nights after work, weekends where I told myself I'd just spend an hour on something and looked up to find it was 2am. Periods where I was between contracts and needed something to keep my head in the game. Stretches where I was just genuinely excited about an idea and couldn't stop. That kind of time sticks. You remember the state of mind you were in, what you were listening to, what you were trying to figure out.

There's also the quiet pride of it. Nobody else knew those repos existed, but I did. I'd built things. Real things, even if they were half-finished and scrappy. Deleting them felt like admitting they didn't count.

Some of those repos, I genuinely didn't want to delete. They represent periods where I was properly absorbed in a problem - losing track of time, working through something for the sake of understanding it. That feeling is what makes a good engineer. But the repos were never the point. That feeling was. And you'll get it back with the next thing you build. That's the only way to chase it anyway.

But here's what I eventually had to accept: the code isn't the memory. The memory is already in your head, or it's not. A private repo nobody opens isn't preserving anything. It's just clutter with a timestamp.

And the truth is, the longer you leave dead code sitting there, the more it starts to feel like a graveyard you're responsible for maintaining. Every time you open GitHub looking for something, you walk past all of it. It just sits there.

Deleting it wasn't losing something. It was just finally admitting it was already gone.

Your GitHub profile is a tool, not a trophy cabinet

It's there to showcase work, host open source projects, store things you actively use, and back up what matters. It's not there to be an archaeological record of every time you spun up a folder and typed git init.

When you hoard repos, you end up searching through a hundred dead projects every time you want to find something. Worse, you start to confuse having old code with having skills. They're not the same thing.

If you were to rebuild any of those projects today, you'd do a better job. That's the point. You've moved on. Let the repos move on too.

What's actually worth keeping

Keep it if it's structured like a real project. A README that explains the problem, why it exists, and how to use it. Licensing. Deploy instructions if relevant. Something someone else could actually open and use.

One I kept, and actually put proper effort into, is this: fedora-atomic-nvidia-secureboot-akmods.

I was moving from Windows to Linux and settled on Fedora Atomic. I like the immutable layered upgrades - it's always been a pain point in Windows not knowing what the OS is quietly changing under you. Getting the Nvidia drivers installed with Secure Boot took me three full days of reading, trial and error, and cross-referencing sources. So I documented it properly, wrote an install script others could actually run, and made it public.

That's a useful repo. Real problem, structured properly, useful to someone else. That's the bar.

Write about it instead

When you're researching something properly, you don't read one article. You cycle through multiple sources, multiple angles, multiple takes on the same topic. Even if there are a hundred articles on your subject, yours is still worth writing - because it's your perspective, at your point in time, with your own misunderstandings and breakthroughs in it.

Write about what you learned and why you did it the way you did. That lives online and compounds over time. A deleted repo disappears. An article doesn't.

Same goes for consulting and contract work. The repos you created under a company account are gone the moment you leave. Commits, context, all of it. Write about the approach, what you learned, what you'd do differently. Not the company's internals. Just what you actually took from it.

The "I might need it later" exception

You probably won't. But if you genuinely think you might, extract what matters into documentation. Put it somewhere central. If it's still sitting there untouched a year from now, delete it then.

If you're keeping something to demonstrate skills, fine. But it needs to look like a project - not something abandoned mid-thought with no README and a single commit from four years ago.

Next steps

I've also got hundreds of codebases backed up offline. Drives full of projects, experiments, half-finished things I convinced myself I'd come back to.

I'm going to Ctrl+Delete the lot.

If I haven't opened it in years, I'm not going to. And if I ever did need something from it, I probably wouldn't find it anyway buried under everything else.

Same logic applies. Keep moving forward.

Start somewhere

If you can't think of anything to make, pick something that actually interests you and treat it like a real project from day one. It doesn't need to be the next Linux kernel or even a useful ls replacement. It just needs to be something you care enough about to structure properly, document, and finish.

Stop squirrelling away old code. There's too much still to build.

At the end of the day, do what works for you. If you want to keep every repo, keep them. This is just what worked for me.