wry_durian

I don't know which video it is either, but what I've found helpful is checking aerobic decoupling. If your heart rate is drifting upward significantly over the course of an hourlong easy run despite not increasing your pace or power, then the bottleneck is probably your aerobic engine. I don't track it daily because it's a noisy metric, but looking at the overall distribution is useful.

After that it's probably determining your LTHR accurately (don't just accept what your Garmin or Apple Watch says it is). This gives a better sense of how hard to push on your hard days, and it's also useful to see what % of HRmax your threshold lands at.

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%.

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.

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.

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!

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.

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).

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.

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.

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.