Hacker News: wry_durian

New comment by wry_durian in "Sawe becomes first athlete to run a sub-two-hour marathon in a competitive race"

wry_durian — Sun, 26 Apr 2026 21:48:35 +0000

I suspect there would be larger deltas due to improvements in nutrition and fueling. As another poster has mentioned, today's runners are ingesting so many more carbs per hour than 20 or 30 years ago. And if doping trends have changed over time, that's another factor. (No clue either way, but it's a potential factor.)

There's been lots of research into shoes though, so you might be able to work something out. For instance Jack Daniels (the running coach, not the beverage!) found that adding 100 grams to a running shoe increased aerobic effort by around 1%.

New comment by wry_durian in "The West forgot how to make things, now it’s forgetting how to code"

wry_durian — Sun, 26 Apr 2026 11:10:15 +0000

If "winning" the beer game means not overreacting to short-term signals, then you can view that as a form of slack. You're sometimes paying a bit extra to hold onto something that you have no immediate short-term use for.

New comment by wry_durian in "Notion leaks email addresses of all editors of any public page"

wry_durian — Sun, 19 Apr 2026 17:23:49 +0000

That's exactly backwards. In the current regime, it's precisely the billions of people who are affected by data breaches (and who happen to be taxpayers!) who are footing the bill.

New comment by wry_durian in "Generative AI and Wikipedia editing: What we learned in 2025"

wry_durian — Sat, 31 Jan 2026 23:28:03 +0000

Note that this article is only about edits made through the Wiki Edu program, which partners with universities and academics to have students edit Wikipedia on course-related topics. It's not about Wikipedia writ large!

New comment by wry_durian in "Show HN: I used Claude Code to discover connections between 100 books"

wry_durian — Sun, 11 Jan 2026 15:46:37 +0000

Indeed, I'm not seeing a "so what" here. LLMs make mental models cheap, but all models are wrong, and this one is too. The inclusion of Donalla Meadows' book and the quote from The Guns of August are particularly tenuous.

New comment by wry_durian in "Why Understanding Software Cycle Time Is Messy, Not Magic"

wry_durian — Mon, 09 Jun 2025 20:25:49 +0000

One intuition for the variability argument comes from binary search, where you learn the most when you eliminate half the possibilities. You can apply the same logic to your product development or testing strategy by intending to fail more frequently. (In the testing context, this could look like testing at a higher level of integration.) This adds variability to the process but you will learn more and faster, which typically results in economic upside.

In terms of resources, Will Larson's An Elegant Puzzle hits on some of these themes and is very readable. However, he doesn't show much of his work, as it were. It's more like a series of blog posts, whereas Reinertsen's book is more like a textbook. You could also just read a queuing theory textbook and try to generalize from it (and that's where you'll read plenty about high-capacity queues, for example).

New comment by wry_durian in "Why Understanding Software Cycle Time Is Messy, Not Magic"

wry_durian — Sun, 08 Jun 2025 12:43:37 +0000

The book has a chapter about how to optimize variability in the product development process. The key idea is that variability is not inherently good nor bad, we just care about the economic cost of variability. There are lots of asymmetries in the payoff functions in the software context, so the area is ripe for optimization, and that means sometimes you'll want to increase variability to increase profit. But if we're mostly concerned that software development is too variable, there are lots of ways to decrease it, like pooling demand-variable roles, cross-training employees on sequentially adjacent parts of the product lifecycle, implementing single high-capacity queues, etc.

New comment by wry_durian in "Why Understanding Software Cycle Time Is Messy, Not Magic"

wry_durian — Sun, 08 Jun 2025 09:46:49 +0000

Cycle time is imprtant, but three problems with it. First, it (like many other factors) is just a proxy variable in the total cost equation. Second, cycle time is a lagging indicator so it gives you limited foresight into the systemic control levers at your disposal. And third, queue size plays a larger causal role in downstream economic problems with products. This is why you should always consider your queue size before your cycle time.

I didn't see these talked about much in the paper at a glance. Highly recommend Reinertsen's The Principles of Product Development Flow here instead.

New comment by wry_durian in "Treasury agrees to block DOGE's access to personal taxpayer data at IRS"

wry_durian — Thu, 20 Feb 2025 23:55:43 +0000

It can very much so be a data breach for government to "have access to" other agencies' data. Check whether U.S.C. § 3552(b)(2) contains any exceptions or carve-outs for government agencies!

One of the main points of privacy legislation is to functionally limit the government's ability to collect, use, disclose, and retain personal information in the first place. That's entirely contrary to the idea that government departments can share or access it pell-mell.