Software developers have the bad habit of switching to programming languages and tools that result in applications consuming most of the resources from hardware advancements. The new 2025 laptop runs faster than the old 2015 laptop, but not nearly as fast as its components' raw improvements should provide. The switch from installed desktop applications to on-demand web applications has resource consumption that should rightly be called gluttonous. These switches have mostly burdened the user and not the developer. With the recent advent of vide coding and agentic workflows these costs are now felt by the developer. And the costs are enormous. Collectively our datacenters consume the power output of whole electric generation facilities and the surrounding watersheds to cool them down. I don't see how this is a sustainable advancement; not for the profession and not for the planet.
Programming by coincidence
The more I think about vibe coding and see it in practice the more I am reminded of David Thomas' and Andrew Hunt's admonishment in The Pragmatic Programmer
We should avoid programming by coincidence -- relying on luck and accidental successes -- in favor of programming deliberately.
Why Stripe’s API Never Breaks
The short video Why Stripe’s API Never Breaks introduces how Stripe handles API versioning. Stripe's API URLs do not include a (consequential) version number and yet every API release is supported. Instead,
- The API client includes in each HTTP requests a header with the client's API release date, eg "X-Stripe-Version: 2024-01-23".
- Stripe's API server transforms the dated request into a current release request.
- Stripe's API server transforms the current release response into the dated response.
This does mean that each new API release needs transformers for all previous releases. I suspect that there are few breaking changes and most transformers default to the previous release's transformers.
Using a version HTTP header does not seem different than using a version number in the URL path, but there is something elegant about maintaining stable URLs across API versions. It also seems easer in most web frameworks (eg Rails) to introduce the transformers after routing.