Toots from 2025-11-11#
“As for yourself, instead of focusing on redundancy, invest in learning to use those cloud servic…#
“As for yourself, instead of focusing on redundancy, invest in learning to use those cloud services correctly.”
https://www.subbu.org/articles/2025/tangled-mess/?__readwiseLocation=
Mastodon Source 🐘#
“Welcome to Senior Leadership! You made it! There’s no delegating this task, but it’s not a…#
“Welcome to Senior Leadership! You made it! There’s no delegating this task, but it’s not a task. It’s a strategy, and you don’t delegate strategy; you explain it loudly, repeatedly, and then you become The Consequence.”
https://randsinrepose.com/archives/become-the-consequence/?--readwiseLocation=
Mastodon Source 🐘#
“I eventually won the argument, but here’s the thing: that AI is going to train the next genera…#
“I eventually won the argument, but here’s the thing: that AI is going to train the next generation of developers. And those developers aren’t going to have the patience, institutional knowledge, or masochistic dedication required to navigate AWS’s deliberately Byzantine experience. They’re going to build on platforms that don’t make them prove their worth through suffering.”
https://www.theregister.com/2025/11/04/aws_genz_misery_nope/
Mastodon Source 🐘#
AWS has immensely powerful primitives, but both the inner-loop and team/department wide DX is extremely weak. I can absolutely understand why new teams aren’t willing to pay the cognitive onboarding cost.
Teams are increasingly rewarded to reduce TTM. It takes a long time just to deploy a containerized application. Even longer if you want to deploy that via a CI/CD pipeline to multiple accounts. Once you start composing multiple services it’s another significant learning investment.
Mastodon Source 🐘#
The AWS Well-Architected Framework offers excellent guidance for development. Yet the AWS blog posts consistently use Console-driven development with Resource: * IAM policies.
Those AWS Blog posts, and in fact nearly all AWS documentation, have been a significant adoption accelerant. Documentation has been a competitive advantage.
But those documents encoded POLA violations and there was a chasm between spinning up a service in the Console and scaling that to 5, 10, 100+ person teams. I always thought there was a huge opportunity to author blog posts that spoke more to the customer than the PM.
Mastodon Source 🐘#
That competitive advantage is dissolving with LLMs and expectations to increase delivery velocity. Capabilities that were novel to the Alice in Chains fans (11 9’s of durability?, new compute in less than 8 weeks?) are table stakes for Tyler, The Creator fans.
Access to these novel capabilities has drifted into the background. Access is now largely ubiquitous, what remains is optimizing feedback cycles.
For Team Tyler, their first inner loop AWS feedback cycle (it works!) is opaque, overly complicated, and frustrating. How long do we expect people to incrementally hill-crawl the IAM policy landscape as they run into IAM Action & ARN barriers?
Mastodon Source 🐘#
I know there are ecosystem benefits to working through that first inner loop, but I also know that there are many services (including those that are built on AWS) that make git push handle 90% of the job.
There’s also a paradox of choice, higher order services implying service independence where none exists, AWS-internal metric goals (how would you measure the magnitude of “reducing latency of customer dev loops”?), and generally, exposing Conway complexity to customers instead of making “the right way, the easy way”.
Corey is on point with this summary: “The difference between the Vercel user experience and the AWS user experience is purely one of the will to have a good experience at the highest levels of the company.”