> JSON retries generated 7x to 14x more output tokens than the args path.
But!
> On PowerShell, the cost gap between args and JSON was 9x. On Bash, it collapsed to 1.5x.
The conclusion of the post is "cli args are better than JSON", but the argument for why only holds up on Windows. This post says more about Powershell than anything else.
I have the same experience, but there's another dimension I want to throw out: breadth versus depth.
I've wildly increased my breadth of learning. If I'm ever curious about anything, even a passing thought, I can scratch that itch in a way I never could before.
But am I going deep? Acquiring new skills? Eh... I usually go far enough to unblock myself and/or settle a curiosity. I don't think that's good or bad, but it does present a certain set of tradeoffs that are different than going deep.
This kind of thinking is why a lot of market place startups fail.
You have two parties engaging with each other in a subpar way, and your solution is to make things better for one party (hiring side) and significantly worse for the other (candidates). Trying to convince candidates that this is good for them, won't make it so. Eg:
> Every stamp that you hand out, pass or fail, leaves a candidate richer than they showed up. This attracts strong candidates to you, because even your rejections are worth something to them.
Candidates don't want stamps. They want stable work.
Very much on the same page as far as the holy grail! Would love if I had all that data (and it was actionable).
As for the Stryd... take this all with a grain of salt because I only have a consumer level understanding but:
You can establish your FTP, but then the issue is setting zones from there. My understanding is that the big thing with establishing them is having an accurate estimation of LT1 and LT2 lactate thresholds. Most zone calculators are approximating that, but those calculators are based on a large body of data comparing lactate levels to cycling power in a controlled environment (a lab). That large body of data doesn’t exist for running power, and I recall reading that the little bit that does indicates that formulas for cycling power’s impact on L1/L2 thresholds don’t line up with running power. It’s also been maybe 4 or 5 years since I was engaged with this so the science may have improved!
Watch wise, when I used it, I have a Garmin Fenix, and it had options to show watts/zones/etc. You can even plug in zone based workouts just like you can with cycling power. I did find it a bit of a pain to monitor on a watch vs a bike computer, but not too big of a deal.
This is pretty cool! Your note about cycling power meters changing the way you perceive effort matches my experience as well. One other bit from my experience: I'm a runner and a cyclist, and I've always lusted after having cycling style data and prescribed workouts for my running. When Stryd launched I was all in, but... all it gave me was power numbers. It didn't have the tribal knowledge that came with my cycling power meter. Eg - lots of online content about zones, free and paid workouts / plans to target different goals (eg sprinting vs long endurance). It almost seems like any discussion of serious training on a bike comes back to watts.
But with the Stryd, all I got was power numbers, and the option to signup for a monthly paid subscription with some training plans that were pretty bare bones. It seems like running power meters just haven't been adopted widely enough for that critical mass of information to emerge. My realization from this is the data is useless without the tribal knowledge of how to use it. So my Stryd sits in a drawer somewhere, and I'm back to running by heart rate.
I had an advanced algorithms professor who was brilliant but not always put together. Eg - he didn't always dress himself correctly. Think, two different shoes or a button shirt mis-buttoned so there was an extra hole at the top.
He came in one day and wrote this problem on the board, and asked if anyone could solve it in O(n log n). No one did, he seemed really disappointed. The TA came in afterwards, and someone asked why we were going over this specific problem. Would it be on the final? The TA said "You professor gave you this problem because he went to a conference recently, and this was announced to great fanfare as a new unsolved problem. For the last two weeks, he's been asking anyone who will listen if they can solve this problem."
> JSON retries generated 7x to 14x more output tokens than the args path.
But!
> On PowerShell, the cost gap between args and JSON was 9x. On Bash, it collapsed to 1.5x.
The conclusion of the post is "cli args are better than JSON", but the argument for why only holds up on Windows. This post says more about Powershell than anything else.