The Problem with "Quick Tasks"

You sit down to write an email. Simple enough. But then you want to include a specific number to back up your point. "Let me just check that real quick," you think.

Forty-five minutes later, you're deep in a Python script, calculating statistics from a CSV file. The email? Still unfinished.

Without nested timers, you just see "Email task: 2 hours." That's useless.

With nested timers, you see the real story:

• Email (5 min)
  • Research claim (10 min)
    • Write Python script (45 min)
      • Debug CSV parsing (30 min)
      • Format output (20 min)

That's when it hits you: "I'm 45 minutes into calculating a number for one line in an email. I could just say 'I estimate roughly 20%' and add a note that I can dig deeper if needed."

The Scope Creep Cascade

Every programmer knows this pattern. You start fixing a bug. The bug is in a function that's poorly named. While you're there, you might as well rename it. But wait—that name is used in twelve other places...

Three hours later, you've refactored half the codebase and the original bug is still there.

This isn't a character flaw. It's how work actually happens. Tasks spawn subtasks. Nested timers make it visible so you can ask: "Is this worth it right now?"

Pattern Recognition

After a few weeks of honest tracking, patterns emerge:

• "Quick CSS tweaks" always turn into browser compatibility research
• "Simple database queries" somehow involve rewriting migrations
• "Just updating the README" becomes documenting the entire API

Once you see your own patterns, you can plan accordingly. That "15-minute" CSS fix? Block out an hour.

The timer doesn't judge you for spending an hour perfecting a five-line function. It just shows you that you did it, so you can decide whether that hour was well spent.

Made cloud infrastructure really easy to use for your developers.

Key Features

• Command-line Elm interpreter with server-side standard library (file I/O, databases, APIs)
• Primary use case: Infrastructure-as-Code using Elm (like Pulumi, but better)
• Built-in Kubernetes resource definition library for 60+ standard resources
• Tightly integrated - works with Kubernetes out of the box

How it works:

1. Write Elm scripts using your normal IDE with autocomplete and type checking
2. Execute scripts from command line like any other interpreter (python, node, etc.)
3. Scripts can read files, query databases, make API calls, and process stdin/stdout
4. Manipulate Kubernetes resource definitions as typed data structures instead of debugging YAML template variable substitution
5. Elm compiler catches configuration errors before they hit production

Key Benefits:

• Programs are typically half the size of configuring the same resources with Pulumi TypeScript
• Elm's excellent data modeling lets you precisely encode infrastructure constraints into the type system
• Maintenance-friendly: Excellent compiler messages, no global state, can't build complex abstractions - just functions with implementations right there to read
• Type-safe configurations catch errors before they hit production