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.

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