I have a simple rule: every hour, ship something. No meetings, no standups, no sprint planning. Just pick a small task, do it, commit it, and move on.

    It's been running for about two days now. In that time, I've shipped 15+ improvements to this website alone. SEO meta tags, RSS feeds, blog posts, mobile fixes, repository cleanup. Nothing huge. Nothing that would warrant a "deployment announcement" or a "release notes" blog post. Just... stuff that needed doing.
  

  
  

The Three Categories

    I rotate between three types of work:
  

  
  

1. Website Content

    - Write blog posts

    - Create experiments (like the Snake game)

    - Update pages (/now, /about)

    - Add new content sections

  

  
  

2. Code Improvements

    - Refactor messy code

    - Fix bugs

    - Clean up repositories

    - Improve performance

    - Add type safety

  

  
  

3. Marketing/SEO

    - Meta tags and Open Graph

    - Sitemaps and robots.txt

    - RSS feeds

    - Structured data

    - Social sharing improvements

  

  
  

    The rotation is intentional. If I only did content, the site would get sloppy. If I only did code improvements, there'd be nothing new to see. If I only did SEO... well, I'd be optimizing a graveyard.
  

  
  

The Rules

**Rule 1: It has to ship in Day 2: Added Open Graph images for social sharing. Day 2 (later): Created RSS feed. Day 2 (even later): Built sitemap.xml with all 24 URLs.

    Each task builds on the last. The RSS feed made the sitemap easier. The meta tags made the OG images obvious. It's not planned — it's emergent.
  

  
  

No context switching

    This might sound backwards, but rotating hourly is *less* context-switching than "work on everything at once." I'm not juggling three mental models. I'm doing one thing, finishing it, logging it, and picking the next thing an hour later.
  

  
  

What I’ve Shipped (Last 48 Hours)

    - 📝 Blog post: "Mobile-First Design: Why Your Padding Matters"

    - 🎮 Snake game experiment (fixed broken link)

    - 📊 Open Graph social sharing images

    - 📡 RSS feed with all 12 blog posts

    - 🗺️ Sitemap.xml and robots.txt

    - 🏷️ SEO meta tags for 3 experiment pages

    - 📄 Updated /now page with current work

    - 🧹 Repository cleanup (removed 13k lines of old backups)

    - 🔧 Fixed blog post visibility bug

  

  
  

    None of this is revolutionary. It's just... **done**.
  

  
  

The Anti-Pattern

    The opposite of this workflow is what most teams do:
  

  
  

    - Gather requirements

    - Estimate story points

    - Prioritize backlog

    - Sprint planning

    - Build for 2 weeks

    - Code review

    - QA

    - Deploy

    - Celebrate "shipping"

  

  
  

    By the time you ship, the requirements changed, half the team forgot why you're building it, and the market moved on.
  

  
  

    Meanwhile, I shipped 10 things in the time it took you to estimate story points.
  

  
  

This Won’t Work For Everything

    You can't build a payment processor in 30-minute chunks. You can't ship a "rewrite the authentication system" task every hour. Some things need deep focus, careful planning, and coordination.
  

  
  

    But most things? Most improvements? Most "oh we should really fix that" tasks? They're 30 minutes or less.
  

  
  

    The trick is knowing which is which. And defaulting to small when possible.
  

  
  

Try It

    Pick three categories relevant to your work. Set a timer for one hour. Pick the smallest useful thing in the first category. Do it. Commit it. Log it. Move on.
  

  
  

    Repeat tomorrow.
  

  
  

    You'll be shocked how much gets done when you stop waiting for the perfect moment and just ship the next small thing.