Wednesday, February 4, 2026

Tuesday, February 3, 2026

turdles

THE MOST IMPORTANT THING

FOR ANY SYSTEM TO DO

IS TO LOSE MY DATA

FFS!

indictment

every computer with a "bios" should have a dual bios so you can unhörk yourself, ya know?

Monday, February 2, 2026

thumb it

# The Most Practical Software Estimation Rules of Thumb

*Extracted from Hacker News discussion on "How I Estimate Work as a Staff Software Engineer" (143 comments)*

---

## 1. The "Multiply by Pi" Rule *(Most frequently cited)*

Multiply your initial estimate by **π (3.14)**. This comes from Alistair Cockburn and was mentioned by multiple commenters as having an "almost magical" corrective effect.

> *"The old guys in the 80's and 90's would say kiddingly multiply your original estimate by pi"* — shoknawe

**Variant:** One commenter's mentor said: *"Make the estimate in great detail. Then multiply by 2. Then double that number."* (Effectively 4x)

---

## 2. The "Bump the Unit" Rule

Take your estimate and move to the next human time unit:

- A few days → **a week**

- A week → **a month**

- A month → **a year**

- A year → **a decade or never**

> *"It's wildly pessimistic but not as inaccurate as I'd like."* — dcminter

---

## 3. The "Orders of Magnitude" Method *(Highly practical)*

Don't estimate precise numbers. Instead, answer these questions:

- Is it going to take more than **2 hours**?

- More than **2 days**?

- More than **2 weeks**?

- More than **2 months**?

- More than **2 years**?

If the estimate is too wide, break it into smaller chunks. If you can't break it down, decide if it's worth gathering more information—or scrap the project.

> *"If you can answer these questions, you can estimate using a confidence interval."* — xn

---

## 4. The "Two Days or Less" Threshold

Gather the team. For each task, on the count of three, everyone gives thumbs up (can ship in ≤2 days) or thumbs down.

If it's thumbs down, **break it down further** until you have thumbs-up tasks.

> *"It generally implied if we collectively thought a task would take more than two days to ship, it may require breaking down."* — hosainnet

---

## 5. Invert the Process: Start with the Deadline

Don't ask "how long will this take?" — **find out the time budget first**, then work backwards to determine what scope is achievable.

> *"Someone already has a time constraint. There's already a deadline. Always. Find out what it is and work backwards."* — fogzen

> *"Instead of asking for an estimate, why don't they say: we have until date X, what can we do?"* — etamponi

---

## 6. Estimate in Work Hours, Then Track

The only meaningful unit is **actual work hours**. And critically: **follow up on every estimate** to improve calibration.

> *"My team had several months when we were within ±10% in the aggregate"* — tuna74

> *"If you don't close the loop, if you don't keep track of what you estimated vs. how long it took, how are your estimates going to get better? They aren't."* — AnimalMuppet

---

## 7. The 2x Rule (for Experienced Teams)

Simply **double your initial coding estimate** to account for non-coding work (planning, testing, integration, communication).

> *"As a rule of thumb, 1.5x or 2x your raw coding time estimate"* — cited from Vadim Kravcenko

**For inexperienced teams:** Use **3x**.

---

## 8. Ballpark First, Details Later

Counterintuitively, rough ballpark estimates are often **more accurate** than detailed work breakdowns, because breakdowns miss unknowns.

> *"I find that ballpark estimates are often more accurate than estimates based on work breakdowns"* — fallinditch

One commenter described abandoning a year's worth of detailed Gantt charts, getting a developer's gut estimate of "2 months," adjusting to 14 weeks—and it took exactly 14 weeks.

---

## 9. The Tracer Bullet Approach

Before estimating a large project, build a quick **end-to-end proof of concept** that touches all the tricky parts. This surfaces unknowns early and makes subsequent estimates much more tractable.

> *"Making estimates then becomes quite a bit more tractable"* — cube2222

---

## 10. Present Options, Not Points

Never give a single number. Return with **multiple plans at different risk levels**:

- **Plan A:** Aggressive timeline if X, Y, Z all go right

- **Plan B:** Safer approach with tradeoffs

- **Plan C:** Requires external help

> *"I never come back with a flat 'two weeks' figure. I come back with a range of possibilities, each with their own risks."* — original article

---

## The Meta-Rule (Most Important)

### Scope is flexible. Dates are not.

The real skill isn't predicting how long things take—it's negotiating scope to fit the available time. Features can always be cut, simplified, or phased.

> *"Scope is always flexible. The feature or commitment is just a name and a date in people's heads. Nobody but engineers actually care about requirements. Adjust scope to fit the date, everyone is happy."* — fogzen

---

## Quick Reference Summary

| Rule | Multiplier/Method |

|------|-------------------|

| Pi Rule | Initial estimate × 3.14 |

| Double-Double | Detailed estimate × 2 × 2 |

| Bump the Unit | Days → Weeks → Months → Years |

| 2x Rule | Coding time × 2 (or 3x for new teams) |

| Orders of Magnitude | >2hrs? >2days? >2wks? >2mos? |

| Two Days Threshold | If >2 days, break it down |

---

## Key Insights from the Discussion

### Why Estimation is Hard

1. **Unknown unknowns dominate** — The work you can't predict always takes 90% of the time

2. **Estimates are political tools** — They're used by management to negotiate resources, not to plan engineering work

3. **Precision ≠ Accuracy** — Detailed breakdowns often miss more than gut estimates

### What Actually Works

1. **Track your estimates** — Close the feedback loop to improve over time

2. **Start with constraints** — Find out the real deadline before estimating

3. **Pad scope, not time** — Having features you can cut gives you execution-time flexibility

4. **Communicate early** — Surface problems as soon as you see them, not at the deadline

### The Uncomfortable Truth

> *"It is not possible to accurately estimate software work. Software projects spend most of their time grappling with unknown problems, which by definition can't be estimated in advance."* — Sean Goedecke (original article)

But this doesn't mean you shouldn't estimate—it means you should estimate **differently**: focus on unknowns, present ranges, and negotiate scope rather than pretending you can predict the future.

---

*Source: https://news.ycombinator.com/item?id=46742389*

indictment

I think most all day-job programming languages should start with an AST/ASG and make that public and well defined and have a s-expr supported core syntax.

i come not to bury php

license: public domain CC0

NOTE: expanded version here: https://claude.ai/public/artifacts/64cf67f1-6067-4187-b15f-fdf4402274ef

Design Document: A Modern PHP‑Inspired Web Runtime for Node + TypeScript

1. Introduction: The Spirit of PHP

PHP earned its place in web history not because it was elegant, but because it was immediately useful. Its defining virtues were:

Zero‑friction iteration — edit a file, refresh the browser, see the result.
Stateless execution — every request starts fresh, no global state leaks.
Trivial deployment — copy a file to a server and it runs.
Beginner‑friendly failure model — crashes affect only the current request.
Massive accessibility — no build steps, no daemons, no containers.

These qualities created a development loop that felt like a REPL for the web. You didn’t “build” an app — you tinkered with it, live, with instant feedback.

But PHP’s strengths came bundled with limitations:

No type safety
Inconsistent standard library
Weak module system
Poor tooling
Limited modern ergonomics
No REPL, no notebook‑style exploration
Primitive deployment safety

The goal of this project is to preserve the spirit of PHP while modernizing everything else, using Node + TypeScript as the foundation.

2. Vision: Expanding and Modernizing PHP’s Wins for Node + TypeScript

The core idea is simple:

Bring PHP’s frictionless iteration and deployment model into the TypeScript + Node ecosystem, enhanced with modern tooling, REPL workflows, and programmable safety.

This means:

TypeScript as the first‑class language
Node as the long‑lived host
VM contexts as the per‑request sandbox
A TS loader that eliminates build steps
A local development loop that feels like a notebook
A remote REPL for staging and production
A sync‑based deployment model
A programmable friction pipeline for safe deploys
VSCode integration for diagnostics and deploy UX
A batteries‑included web standard library

The result is a system that feels like:

PHP’s simplicity
Node’s ecosystem
TypeScript’s safety
Cloudflare Workers’ isolation model
Jupyter’s iterative workflow
Git’s extensibility

All fused into a single, coherent developer experience.

3. High‑Level Goals

3.1 Zero‑Friction Local Development

Local iteration should feel like breathing:

tsweb dev starts everything
Hot reload on file change
Instant TS → JS transform
Automatic context reload
Browser auto‑refresh
Inline VSCode diagnostics
Local REPL for experimentation

No build step. No bundler. No config.

3.2 Safe, Structured Deployment

Deployment should be:

sync‑based (like PHP)
secure (key‑based auth)
environment‑aware (staging vs prod)
programmable (hook pipeline)
deliberate (double confirmations, branch checks)

3.3 Stateless Request Execution

Each request runs in a fresh VM context:

No global state leakage
Deterministic behavior
Easy debugging
Safe remote REPL

3.4 Batteries‑Included Web Standard Library

A cohesive TS‑native stdlib:

Request/response helpers
Cookie/session utilities
File uploads
Routing
DB connectors
HTML templating

3.5 Canonical Setup Across All OSes

Everything should “just work”:

npm package + CLI
optional Docker image
VSCode extension
minimal configuration

4. Architecture Overview

┌──────────────────────────────────────────┐
│              tsweb CLI                   │
│ dev, deploy, repl, logs, diff            │
└───────────────────┬──────────────────────┘
                    │
                    ▼
┌──────────────────────────────────────────┐
│      Environment & Friction Engine       │
│ staging/prod rules, hooks, confirmations │
└───────────────────┬──────────────────────┘
                    │
                    ▼
┌──────────────────────────────────────────┐
│        Secure Deployment Channel         │
│ signed payloads, key-based auth          │
└───────────────────┬──────────────────────┘
                    │
                    ▼
┌──────────────────────────────────────────┐
│            Remote TS Runtime             │
│ VM pool, TS loader, hot reload, REPL     │
└──────────────────────────────────────────┘

5. Core Components

5.1 TypeScript Loader

A fast, production‑grade TS loader:

Uses swc/esbuild for TS → JS
Caches aggressively
Works inside VM contexts
Supports hot reload
Integrates with VSCode diagnostics

This eliminates the build step entirely.

5.2 VM Context Pool

Node’s VM module provides per‑request isolation:

Fresh global scope per request
Deterministic teardown
No state leakage
Optional snapshotting for speed

This recreates PHP’s statelessness.

5.3 Web Standard Library

A cohesive, batteries‑included API:

Request, Response (WHATWG)
Cookies, sessions
File uploads
Routing
DB connectors
HTML templating
JSON helpers

This replaces Node’s low‑level primitives with something closer to PHP’s ergonomics.

5.4 Local Development Loop

tsweb dev provides:

File watcher
Hot reload
Automatic TS compilation
Browser auto‑refresh
Local REPL
Inline VSCode diagnostics

This is the modern equivalent of “edit file → refresh browser.”

5.5 Remote REPL

A secure REPL for staging and production:

Evaluate code in isolated contexts
Inspect logs
Run smoke tests
Debug issues
Validate migrations

This is a superpower PHP never had.

5.6 Deployment System

Deployments are:

sync‑based (diff of changed files)
signed (key‑based auth)
environment‑aware
safe (friction pipeline)
fast (no build step)

Deployment flow:

Compute diff
Run friction hooks
Sign payload
Upload to server
Server verifies signature
Server reloads VM contexts
Health checks
Swap traffic

5.7 Programmable Friction Pipeline

Friction is a first‑class concept.

Each environment defines a pipeline of hooks:

{
  "environments": {
    "staging": {
      "friction": ["confirm_environment", "show_diff"]
    },
    "prod": {
      "friction": [
        "confirm_environment",
        "show_diff",
        "require_clean_working_tree",
        "require_on_main",
        "double_confirm",
        "type_environment_name"
      ]
    }
  }
}

Hooks are just TypeScript functions.

Teams can add:

Slack notifications
Jira ticket checks
Peer approval
Deployment windows
Custom validations

This prevents accidental deploys without slowing down intentional ones.

6. Developer Workflow

6.1 Local Development

npx tsweb dev

Edit files
Save
Browser reloads
Errors appear in VSCode
REPL available

6.2 Deploy to Staging

npx tsweb deploy staging

Light friction
Diff preview
Single confirmation

6.3 Remote Debugging

npx tsweb repl staging

6.4 Deploy to Production

npx tsweb deploy prod

Heavy friction
Branch enforcement
Clean working tree required
Double confirmation
Type environment name

7. Why This System Matters

This design:

preserves PHP’s magic
fixes PHP’s weaknesses
leverages Node’s ecosystem
embraces TypeScript’s safety
integrates with modern tooling
supports REPL‑driven development
enforces safe, deliberate deployments
remains simple, predictable, and fast

It’s not a framework.
It’s not a serverless platform.
It’s not a bundler.

It’s a developer experience layer that makes building web apps feel effortless again — but without sacrificing safety, structure, or modern ergonomics.

Sunday, February 1, 2026

gigo

there is so much brain dead bad ux in the world.

so glad ios actively prevents me from, like, saving a file i have open in safari, to the filesystem. still. in 2026.

so glad bitbucket is a nightmare. especially on mobile.

so glad google drive ui is a bit of a nightmare, on any platform.

claude in ios safari? train wreck.

(blogger kind of sucks, still, too.)

Night of the Living Duh

Wednesday, February 4, 2026

two words

Tuesday, February 3, 2026

turdles

indictment

Monday, February 2, 2026

thumb it

indictment

i come not to bury php

Design Document: A Modern PHP‑Inspired Web Runtime for Node + TypeScript

1. Introduction: The Spirit of PHP

2. Vision: Expanding and Modernizing PHP’s Wins for Node + TypeScript

3. High‑Level Goals

3.1 Zero‑Friction Local Development

3.2 Safe, Structured Deployment

3.3 Stateless Request Execution

3.4 Batteries‑Included Web Standard Library

3.5 Canonical Setup Across All OSes

4. Architecture Overview

5. Core Components

5.1 TypeScript Loader

5.2 VM Context Pool

5.3 Web Standard Library

5.4 Local Development Loop

5.5 Remote REPL

5.6 Deployment System

Deployment flow:

5.7 Programmable Friction Pipeline

6. Developer Workflow

6.1 Local Development

6.2 Deploy to Staging

6.3 Remote Debugging

6.4 Deploy to Production

7. Why This System Matters

Sunday, February 1, 2026

gigo