digitallogic

The thing is, without the FAA mandating something like this for SRE’s, no one will do it. In the moment, getting the broken thing back up and running is seen as far more important than the learning opportunity.

I noticed this constraint a few years ago when the SRE/DevOps hiring market was really tight, but no one was investing in non-senior talent. I ended up founding a startup that tried to address this by supplying training via simulated outages. Maybe we were too early.

> You have enough budget for only the first floor, but you have a big family, and you know you’ll want a second one in a couple of years. > Adding the infrastructure to support a 2nd floor is MUCH cheaper right now than it will be when you actually want that 2nd floor.

The problem with this thinking is it requires certainty about the future. It's much cheaper right now IF AND ONLY IF you end up needing the thing. If you don't need it, then you've threw time and money down the drain.

Where I think this analogy weakens is you probably have far more certainty of whether or not you want a big family then you do on whether or not a new product line will see major adoption.

> LIFE EXPECTANCY AT BIRTH

Given the huge infant mortality rates until very recently in human history, this is often pretty misleading. Life expectancy at say, 2yo, is far greater.

> it is unlikely to survive several moves

I have several pieces that have survived 3-4 moves. The trick is when assembling, use wood glue with any dowels. On their own, these dowels only have friction to hold them in place, and over time, the surface of the area where they are inserted compresses, reducing friction. Hence you get that typical side to side sway. The glue mitigates this problem.

> from a technological standpoint, don't appear to have much IP that cannot be easily replicated.

They have network effects and strong brand recognition, both of which are hard to replicate.

There's a lot of great things about this piece, but I'm kind of stuck on the "Hieronymus Bosch Butt Music". Listened to it a bunch of times now. https://www.youtube.com/watch?v=OnrICy3Bc2U

Maybe that's the point?

> having kids may make one less ambitious

Can't say this resonates with me. Though being a dad has wildly changed what I'm ambitious about.

ITT: a lot of undiagnosed ADHD

Some big findings:

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

Document for other developers: you put in the work for someone else to get what they want.

Documenting for Claude: you put in the work to get what you want.

Seems pretty straightforward.

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.

> 1-2% on millions of dollars is significant but it's not nearly as impactful as finding Product-Market-Fit in your actual business.

You've got really significant, broader lesson here for startups at this stage.

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

> Teams typically implement their earliest version of an access control system with a home-grown solution or an open source library. Many implement role-based access control, often with roles, attributes, and authorization logic hard coded and/or tightly coupled with their business logic.

Here's the thing, teams do this for a reason. Each one of these checks takes all of 2 minutes to add. And the next one takes 2 mins to add, and so forth. Until it's a total mess. But, as someone who been through this cycle multiple times, that's exactly what I would do again in the future. Because, on day zero, if my options are "the 2 minute solution" or "spend hours/days/weeks? evaluating a vendor for a problem I won't have for years"... well, the choice seems pretty clear there.

> As a product grows in usage and complexity, this is no longer enough. But the thing is... while it's not enough... I can add to it. Far more easily than I can to refactor everything to support a vendor provided system. And I know it'll be a big ball of mud, but at just about every decision point along the way I'm better off not switching. And every time I add something to my system, it's that much harder to adopt yours.

It feels like there's a circular dependency here. The easiest time to adopt your product (day zero) is also when I'm least likely to get value out of it. Solve that for me, and I'm very interested in your product.