This summer, NCAA Division I voted to remove altitude and track-size conversions, which had been in place since 1981, claiming that “there is no true science being applied.” Division II is poised to follow in 2027–28, endorsing a letter from the president of the coaches’ association claiming that “the data behind altitude conversions are rife with inaccuracies, and were not developed based on scientific evidence.”

I acquired every TFRRS 60 m and 60 mH result from 2007–2026. The data clearly show that 1) altitude significantly benefits short sprinters, 2) the old NCAA adjustments were about 2x too small, and 3) measurable venue effects remain after accounting for altitude. In fact, the model estimates that the fastest track in America is 90 ms faster over 60 m than the median sea-level venue—enough to vault 2026’s 73rd-fastest 60 m athlete into the top 16 and a ticket to NCAA nationals.

I’ve been playing with InstantDB and Tanstack Router recently. InstantDB exposes a hook useQuery to fetch data, with a fairly typical { data, error, isLoading } return value.

Using useQuery directly in page components means that the component has to handle loading and error states directly, instead of using pendingComponent and errorComponent in the router.

One naive approach is to use db.queryOnce inside a data loader. This works, but means that the component will not be aware of any updates to the data—InstantDB’s most important feature.

Instead, we can combine db.queryOnce and db.useQuery to 1) fetch any initial data in the loader, and 2) use db.useQuery to subscribe to updates in the component:

Despite turning 30 last November, I ran my fastest times ever this year: 6.78 in the 60m, 10.55 in the 100m, and 21.26 in the 200m. Indoors, I missed qualifying for USATF nationals by just 0.03s. Outdoors, these were my first PRs since 2022, and my first time cracking 1000 points on the WA scoring tables.

The main change? I nearly doubled my sprint volume.

From 2022-2024, I averaged about 300 meters a week of maximal sprinting (accelerations and flies). This year, I pushed that to 556 meters, an almost 90% increase. At my age and with my injury history, this was a huge risk. But it paid off for me. Below, I’ll detail everything I did to make it work, as well as all the other changes I made this year.

Tracking a record’s last modified time is a common application requirement. In Postgres, a typical implementation might look like this, using a BEFORE UPDATE trigger on a last_modified_at column:

CREATE TABLE foo (
    id SERIAL PRIMARY KEY,
    name TEXT,
    last_modified_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE OR REPLACE FUNCTION update_last_modified_at()
RETURNS TRIGGER AS $$
BEGIN
    NEW.last_modified_at = now();
    RETURN NEW;
END;
$$ LANGUAGE 'plpgsql';

CREATE TRIGGER update_last_modified_at_trigger
BEFORE UPDATE ON foo
FOR EACH ROW
EXECUTE PROCEDURE update_last_modified_at();

This works in most cases, but breaks an assumption that’s likely made by the application: last_modified_at isn’t necessarily monotonically increasing, even if the system clock is. This can cause problems when the application uses last_modified_at as a watermark for processing changes.

Almost four years ago, I wrote a post about the relationship between temperature and speed, finding a linear relationship on 30m fly times with an R² of 0.21. I’ve kept tracking every rep since then—instead of 150 data points, I now have almost a thousand. I’ve also gotten more sophisticated with how I estimate fly and acceleration times from single reps that deserves its own blogpost. For now, what’s important is that across this four-year dataset, I have 642 30m acceleration reps and 451 10m fly reps, with temperatures ranging from 14° to 95° F.