> Each decision solved the problem in front of it. Nobody was asked to look at the sum of all actions.

This is the perfect description of Telstra as a company.

This reminds me of this: https://obamawhitehouse.archives.gov/blog/2015/03/26/why-we-...

I saw the talk version of that and it has lodged in my memory. The point he made was that "health.gov" was made by a bunch of teams that made sure that their part worked, but nobody was in charge of making the whole thing work.

This is sadly "normal" for large bureaucracies.

Every time I see a giant, multi-million dollar catastrophe, it's always "proper", "documented", "enterprise", "by the book", and... "a total failure". The reason is always that nobody actually cares about the final outcome, only the paperwork in front of them that they need fill out, the checkbox that needs to be ticked, or the compliance requirement that needs to be met.

This, in my opinion, is some part of how we are schooling people - do as you are told and follow the rules and some part of not having stakes in the outcome.

No this is what the corporate world does to you.

There's a brief period when you join any company where you really want to improve things, and then about a year in the system has asserted towards the mean.

Nothing to do with schooling, every thing to do with business structures.

This was inspiring, thanks for sharing.

Why did you include the source tracker in your link?

Definitely not on purpose! I keep forgetting that ChatGPT does that now, which is rather irritating because I don’t use it to write comments but the tracker makes it look like I do.

I do use ChatGPT to resolve vague memories of articles read long ago into concrete URLs I can share, which is one of the best uses of the accursed things right now!

I assure you that I am an organic meat human like yourself and the article dates itself to the “before times” and can also be trusted to be free of contamination.

ChatGPT is a far more useful search engine than Google, duckduckgo, etc.

It won’t last, but just as Google was so much better than hotbit, altavista, yahoo etc back in the day.

> This is most legacy telecoms everywhere.

This is the perfect description of most legacy telecoms everywhere.

Aigile

NIH syndrome

While I understand the intent of this exercise, couldn't someone just wasm compile the Servo html5ever Rust codebase?

That's because OP wrote that

> These days a great SDK, not a great API, is a hallmark, and maybe even a necessity, of a world class development experience.

IMO, you can't build a great SDK without a great API. Duct tape only goes so far.

I agree with you.

I actually don't see any value-add from SDKs that wrap HTTP requests. HTTP is a standard, and my programming environment already provides a way to make requests. In fact it probably provides multiple, and your SDK might use a different one from what I do in the project, resulting in bloat. And for what gain? I still need to look at docs and try my best to do what the docs are telling me to.

Now if it's a statically typed language then I kinda get it. Better IDE/lsp integration and all. But even then, just publish an OpenAPI spec and let me generate my own client that's more idiomatic with my project.

This is one of the sentiment that powers the Common Lisp ecosystem. There's already good data structures and functions in the standard (and quasi standard) library, why do you need to invent new ones? In other languages (Node JS), you take a library and it brings a whole kitchen with it.

I agree with the sentiment that great APIs are a prerequisite to great SDKs, but great SDKs are really about time saving. Consider AWS's API, which requires a specific signing mechanism. That is annoying to implement manually. In general, the common method of shared-secret passed via bearer token is pretty insecure. I hope to see that change over time, and SDKs can help facilitate that.

I like the middle ground where I generate the models from OpenAPI but stick to my preferred HTTP library of choice in the language I’m using.

But you _can_ put a good SDK in place to abstract away a terrible API.

I've done this at work to ease use for clients -- once they're happy with the SDK interface I can do whatever I want behind the scenes to shore up the API/backend without impacting those same clients and their OK SDK.

As the saying goes 'if you cannot solve it with duct tape, you did not use enough duct tape' ;)

Malicious access to these tokens is malicious access to the service.

Rails 8 will by default use the DB for cache, queues and WebSocket broadcasting - https://fly.io/ruby-dispatch/the-plan-for-rails-8/

though, sqlite will not be used for the websocket broadcasting

Not so fast https://github.com/rails/rails/pull/52889