Juniors are also more likely to be the MOST proficient/comfortable with AI tooling.

Pair them with a senior so they can learn engineering best practices:

And now you've also just given your senior engineers some extra experience/insights into how to more effectively leverage AI.

It accelerates the org to have juniors (really: a good mix of all experience levels)

> Juniors are also more likely to be the MOST proficient/comfortable with AI tooling.

Why? That seems unlikely to me. That's like saying juniors are likely the most comfortable with jj, zed, or vscode.

I think a big part of the switching cost is the cost of learning a different model's nuances. Having good intuition for what works/doesn't, how to write effective prompts, etc.

Maybe someday future models will all behave similarly given the same prompt, but we're not quite there yet

Same here. Gemini really excels at all the "softer" parts of the development process (which, TBH, feels like most of the work). And Claude kicks ass at the actual code authoring.

It's a really nice workflow.

It's really not that nefarious.

IAD datacenters have forever been the place where Amazon software developers implement services first (well before AWS was a thing).

Multi-AZ support often comes second (more than you think; Amazon is a pragmatic company), and not every service is easy to make TRULY multi-AZ.

And then other services depend on those services, and may also fall into the same trap.

...and so much of the tech/architectural debt gets concentrated into a single region.

Right, like I said: crazy. Anything production with certain other clouds must be multi-AZ. Both reinforced by culture and technical constraints. Sometimes BCDR/contract audits [zones chosen by a third party at random].

It sure is a blast when they decide to cut off (or simulate the loss of) a whole DC just to see what breaks, I bet :)

The disconnect case was simple: breakage was as expected. The island was lost until we drew it on the map again. Things got really interesting when it was a full power-down and back on.

Were the docs/tooling up to date? Tough bet. Much easier to fix BGP or whatever.

It also doesn't help that most companies using AWS aren't remotely close to multi-region support, and that us-east-1 is likely the most populated region.

> but the US is going to ensure that the energy capability is there.

We're doing a pretty shit job of ensuring that today. Capacity is already intensely strained, and the govt seems to be decelerating investment into power capacity growth, if anything

The capital cost is even less insane than the fact that power utility companies are the real constraint on this industry.

North American grids are starving for electricity right now.

Someone ought to do a deep dive into how much actual total excess power capacity we have today (that could feasibly be used by data center megacampuses), and how much capacity is coming online and when.

Power plants are massively slow undertakings.

All these datacenters deals seem to be making an assumption that capacity will magically appear in time, and/or that competition for it doesn't exist.

We have a nuclear power plant in Taiwan that was built and never switched on, seems it'd be the perfect way for Taiwan to claw its way into not just providing chips but also just popping them straight into a data center in Fulong.

How this is not more examined is beyond me….

The Rust equivalent is more like using `unsafe` and derefing raw pointers

Yeah and you can explicitly assert a null is a string in TS, but it's explicit. You can't build a Rust program without those asserts but it's trivial to skip the type checking for TS which is more of a linter than a type system.

I disagree that TS is more of a linter. But I definitely feel sympathetic to that perspective.

I’ll pull off the cleanest, nicest generic constraints on some component that infers everything perfectly and doesn’t allow invalid inputs, just for a coworker to throw @ts-nocheck on the entire file. It hurts

Like all things: the extremes are never good, and it's all about getting a healthy balance.

- Kids need lots of time with their parents

- Kids need lots of time around other kids

You can do that by sending them to daycare, and ALSO spending lots of time with them when they're home.

You can also do that by taking time off work, and then taking your kid(s) to places with other kids.

Both work; and it depends on your context which works for you.

This looks super neat!

But for the love of God, AWS really needs a better approach to naming products.