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

推荐订阅源

Google DeepMind News
Google DeepMind News
C
Check Point Blog
J
Java Code Geeks
腾讯CDC
Martin Fowler
Martin Fowler
MongoDB | Blog
MongoDB | Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
博客园 - 三生石上(FineUI控件)
Apple Machine Learning Research
Apple Machine Learning Research
大猫的无限游戏
大猫的无限游戏
Engineering at Meta
Engineering at Meta
罗磊的独立博客
Last Week in AI
Last Week in AI
B
Blog
IT之家
IT之家
S
SegmentFault 最新的问题
D
DataBreaches.Net
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
GbyAI
GbyAI
博客园 - 聂微东
U
Unit 42
有赞技术团队
有赞技术团队
Y
Y Combinator Blog
MyScale Blog
MyScale Blog

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
Perfect Is the Enemy of Done — and I Learned That the Har...
Joel Bennett · 2026-06-13 · via DEV Community

Joel Bennett

I had something that worked. It wasn't pretty. There were rough edges. A few things I wanted to clean up before anyone saw it. So I kept going.

Three weeks later I was still cleaning things up.

The feature I was going to add after launch somehow became a requirement before launch. The design that was good enough somehow needed one more pass. The thing that worked fine somehow needed to be rebuilt the right way before I could feel okay about shipping it.

Nobody asked for any of that. I did it to myself.

This is the trap I fall into more than any other. Not building the wrong thing. Not targeting the wrong person. Just refusing to ship the right thing because it isn't perfect yet. And perfect, I've had to learn over and over, is the enemy of good.

The version sitting on my machine helping nobody is not better than the imperfect version in someone's hands. It doesn't matter how clean the code is, how tight the design is, how well-thought-out the edge cases are — if it's not shipped, it doesn't exist.. The user can't tell you what's wrong with something they've never seen.

What I've noticed is that the things I agonize over before shipping almost never come up after. The rough edge I spent three days smoothing — nobody mentioned it. The flow I rebuilt from scratch because it felt slightly off — users navigated it without a second thought. The stuff that actually needed fixing was stuff I didn't even know was a problem until real people used it and showed me.

That's the thing about building in your own head. You manufacture problems. You imagine friction that isn't there. You optimize for a user experience you've never actually watched a real person have. Meanwhile the real problems — the ones that actually matter — are invisible to you until someone else finds them.

Ship it. Watch what happens. Fix what breaks..

That's not laziness. That's the actual process. The first version is a question, not an answer. You're asking the world whether this thing is useful and whether it works. You can't get that answer sitting at your desk making it prettier.

I've shipped things I wasn't proud of. Some of them became the most useful things I've built — not because they were good at launch but because real feedback made them good. I've also sat on things until they were "ready" and by the time I shipped them the moment had passed or I'd lost interest or the problem had changed.

Good enough and shipped beats perfect and sitting on your machine every single time.

Get it out. Improve it after.


Joel Bennett · Founder, 928 Builds · Tucson, AZ · 928builds.com #software build #lessons the hard way