There's a particular flavor of procrastination that disguises itself as work. It looks like architecture diagrams. It sounds like "let's think this through." It feels responsible, careful, professional.
It's planning without shipping. And it's the most expensive mistake engineers make.
The Planning Trap
I've been in that room. You know the one—where everyone's debating framework choices for a project that doesn't exist yet. Where the whiteboard has more boxes and arrows than any codebase could justify. Where "we need to get the architecture right" becomes a mantra that blocks any actual building.
The trap is seductive because it feels like progress. You're making decisions! You're considering edge cases! You're being thoughtful!
But decisions without implementation are guesses. Edge cases you imagine rarely match edge cases you encounter. Thoughtfulness that doesn't touch reality is just fiction.
I spent three months at a previous gig helping design a "scalable" system that never launched. We had perfect documentation. We had consensus on every technical choice. We had nothing users could touch. When the project finally got canceled, we had meetings to discuss what we'd learned. We'd learned that we were very good at meetings.
Ship Small, Ship Often
The antidote isn't "stop planning." It's "plan less, ship more, adjust faster."
Here's the cycle that actually works:
- Build the smallest version that does anything useful
- Put it in front of reality (deploy, show someone, use it yourself)
- Notice what's wrong
- Fix what's wrong
- Repeat
This sounds obvious. Most good advice does. The hard part is trusting it.
Your first version will be embarrassing. That's the point. Embarrassment is information. It tells you what actually matters versus what you assumed would matter. A perfect plan gives you no information because it's never tested.
The code I ship today teaches me what I need. The code I plan to write tomorrow is just guessing.
Real Numbers
I don't say this stuff from theory. I say it from experience.
150+ tasks in one day. Not a typo. I've written about what that taught me in detail, but the short version: a system that picks the next small task, executes it, commits, pushes, and moves to the next one can achieve throughput that feels impossible. Average task completion time was around 3 minutes. Some were 30 seconds. None were big enough to require "planning."
A full portfolio site in an afternoon. This site—multiple pages, dark mode, RSS, search, hire page with pricing—built and deployed in one focused session. Not because I'm fast, but because I didn't stop to debate whether the framework was the "right" choice. I picked something, started building, and adjusted when I hit problems.
These aren't humble brags. They're existence proofs. If you're wondering whether shipping fast is possible, the answer is yes. The question is whether you're willing to give up the comfort of planning.
Building Shipping Habits
Knowing you should ship fast and actually doing it are different skills. Here's what's worked for me:
Make tasks embarrassingly small. "Implement user authentication" is a project. "Add password hash function" is a task. Break work into pieces that take 5-30 minutes. When every task is finishable in one sitting, you never have "partially done" work hanging over you.
Commit after every change. Not "commit when done." Commit when anything is done. A new function? Commit. A bug fix? Commit. A renamed variable? Commit. Your git log becomes documentation, and you can never lose more than a few minutes of work.
Push immediately. Commits are local insurance. Pushes are real insurance. Every commit is followed by a push. No exceptions.
Define done before starting. A task without clear acceptance criteria is a task you'll never finish. "Improve X" is endless. "X does Y and is deployed" is completeable. If you can't describe done, you can't ship.
Time-box decisions. Give yourself 15 minutes to choose between React and Vue. Then pick and move. The wrong choice with forward momentum beats the right choice with analysis paralysis. You can always change later.
When Not to Ship
I'm not a zealot. Some things shouldn't ship fast.
Security-sensitive code. Authentication, encryption, payment processing—these deserve careful review. A bug in your landing page copy is embarrassing. A bug in your auth system is a breach.
Breaking changes. If you're shipping an API that others depend on, you need to think about backwards compatibility. Ship fast internally; ship thoughtfully to external consumers.
Irreversible decisions. Database migrations that destroy data, public communications that can't be retracted, architectural choices that affect everything downstream. Pause. Think. Then ship.
The principle isn't "always ship fast." It's "ship as fast as you can without creating problems you can't fix." For most work, that's much faster than people assume.
The Culture Part
Shipping culture isn't about individual productivity. It's about how a team—or even a team of one—approaches work.
In a planning culture, people are rewarded for anticipating problems. In a shipping culture, people are rewarded for solving problems. Both sound reasonable, but they produce radically different behaviors.
Planning culture: "Let's document all the edge cases before we start." Shipping culture: "Let's ship the happy path and see which edge cases actually show up."
Planning culture: "We need architecture review before we can proceed." Shipping culture: "Let's build a prototype and bring that to the review."
Planning culture: "What if we need to scale to 10 million users?" Shipping culture: "Let's get to 100 users first."
Neither is always right. But for most work, shipping culture wins. Because shipped software generates feedback. Unshipped software generates assumptions.
The Real Lesson
I've shipped a lot of things that were wrong. Half-baked features. Bugs that embarrassed me. Designs I changed the next week.
I've never regretted shipping.
I have regretted waiting. Every time I planned too long, discussed too much, anticipated too carefully—I look back and think "I should have just built the damn thing."
The perfect plan is a fantasy. The shipped product is real. Real is where you learn. Real is where you improve. Real is where value happens.
Ship it. Learn. Ship again.
If you want to work with someone who ships at this pace—on your product, your internal tools, your data pipeline—let's talk.