0x4 reasons to write and publish, Artificial intelligence technology behind ChatGPT was built in Iowa — with a lot of water, Why You Need Systemic Reasoning
There are many types of brain out there. They all click in different ways. Chances there are people who click like you do. If you take the time to explain something difficult in your own way, it will without a doubt help others.
Ultra-court. Je crois que je répète assez souvent ce que dit la citation.
In a paper due to be published later this year, Ren’s team estimates ChatGPT gulps up 500 milliliters of water (close to what’s in a 16-ounce water bottle) every time you ask it a series of between 5 to 50 prompts or questions. The range varies depending on where its servers are located and the season. The estimate includes indirect water usage that the companies don’t measure — such as to cool power plants that supply the data centers with electricity.
L’article n’est pas long et parle également des augmentations de la conso globale chez plusieurs cloud providers. J’ai hâte de voir le papier sous-jacent une fois publié.
Content management software defined the boundaries of a website. Individual people and large organizations installed a single piece of software to create a lovely digital space. They encouraged users to visit there and interact.
Now, many people and organizations want to COPE: create (content) once and publish (it) everywhere. A website is only one of many digital tools used for sharing, displaying and consuming information. Users are everywhere, interacting. Information from one piece of software is purposefully intermixed with information from others (though they are often incompatible) and then shared with still more.
The impact of this change is profound. Developing emerging digital systems requires expertise in 10Xs as many technology tools as the software alone did. And often, a very different mindset for everyone involved.
Yet, we transfer our linear thinking models and processes to our systems building. We might, for example, maintain feature-driven development, outlining “requirements” and model a conveyor belt of delivery. We concretize workflows rather than make them more fluid and flexible. We focus on designing linearly-governable parts while ignoring the relationships between the parts. We continue to stratify strategic decision making and structure people into silo’d teams to deliver it. We add more people to control the people doing the work. We attempt to mitigate all risk before taking any action. We accept “technical debt”, the impact of our successes, as a fact of life.
But what happens as complexity increases – when our software becomes one part of a larger system? When the relationships between software become complex? We invest a tremendous amount of energy into creating interrelated software systems using linear approaches. A feat that simply can not be accomplished.
We adopt new “modern” tools to move from software to systems … then build the exact same software.
Diana Montalion écrit et forme sur des compétences permettant d’approcher et réfléchir aux systèmes complexes. Dans cet article elle identifie certaines des raisons pour lesquelles notre mode de pensée linearisant nous rend incapable de maîtriser nos systèmes, et ce à quoi peut ressembler une équipe qui intègre une pensée complexe. Je vous enverrai bientôt la vidéo d’un des workshops auquel j’ai assisté avec un collègue, puis d’autres ressources autour de ça.
Dans la même lignée d’outils, je vous avais déjà partagé il y a quelques semaines un article sur les diagrammes de causalité (un site complet sur le sujet en fait)
