Nachem ich jetzt lange über Blooms Taxonomie und was die Ebenen im Detail bedeuten geschrieben habe, kann ich jetzt endlich zu dem kommen, was mir eigentlich am Herzen liegt:

Mein ganzes Leben lang haben andere die Ebenen von Blooms Taxonomie verwendet um zu beurteilen wie gut ich etwas verstanden habe - aber man kann diesen Spieß auch umdrehen, und das wissen um diese Ebenen des Verständnisses nutzen um selbst besser zu lernen! (Ehrlich gesagt, bin ich ziemlich angepisst das mir das nicht von Vorne herein genau dafür erklärt und beigebracht wurde)

Wie funktioniert das? Wenn Mensch ohne Plan lernt, dann neigen wir dazu uns zunächst auf den unteren Ebenen zu bewegen. Denn das ist (vermeintlich) einfacher und erscheint logisch. Aber aus der Forschung wissen wir, dass sich von vorne herein auf Fragen der 4. und 5. Ebene (also Analysieren und Bewerten) zu konzentrieren, nicht nur schneller, sondern auch tieferes Verständnis bringt.

Warum? Weil sich die Art und Weise verändert mit der wir uns mit dem Lern-Material beschäftigen. Auswendig Lernen ist ja nicht verzichtbar. Man muss sich die Fakten ja merken. Aber das passiert auch, wenn man sie Analysiert und Bewertet - ABER - wir kriegen die Analyse und Bewertung gratis dazu. (Wohlgemerkt, für etwas mehr Kognitive Anstrengung, aber Entspannung ist ja nicht das Ziel.)

Und das ist der Clou. Gleicher Zeiteinsatz, aber tieferes Verständnis.

🤯

Jetzt ist natürlich nicht jeder mit der Fähigkeit geboren, sich selbst einfach so Fragen auf der 4. und 5. Ebene zu stellen. Aber das ist auch gar nicht nötig. Denn KI kann dabei prima helfen.

Chat-GPT hat ein sehr gutes Verständnis von Blooms-Modell und kann endlos fragen auf Bloom Level 4 und 5 zu jedem Thema generieren. Die sind nicht immer perfekt, es reicht aber, um sich darauf einzustimmnen wie solche Fragen aussehen und effizient selbst zu solchen Fragen zu kommen.

Und das ist für mich ein gamechanger, und super sinnvoller Einsatz von KI.

Hier mal ein Auszug aus einem Chat mit Chat-GPT. Das ist sicher nicht perfekt, aber ein starker Anfang. Chapeau, Chat-GPT!

In meinem ersten Blog-Post habe ich mich mit Blooms Taxonomie beschäftigt. Im zweiten ging es um die ersten drei Ebenen seines Lernmodells. Hier geht es jetzt um die mir am wichtigsten ebenen vier und fünf. Und der Vollständigkeit halber auch auch um die sechste.

Und los gehts!

Die Ebenen von Blooms Taxonomie:

4. Analyse

Auf dieser Ebene geht es darum, Wissen und Informationen in seine Bestandteile zu zerlegen um Beziehungen und Strukturen zu erkennen und Verstehen. Hier geht es erstmals um kritisches Denken und das erkennen von Mustern.

Fragen: "Welche Elemente bilden das Gesamtkonzept?" oder "Wie hängen die Teile zusammen?" und "Was sind die zugrunde liegenden Annahmen?" Diese Fragen helfen uns, tiefer in das Thema einzutauchen und es aus verschiedenen Perspektiven zu betrachten.

Tätigkeit: Untersuchen, Zerlegen, Beziehungen erkennen, Vergleichen. Hier geht es darum, das erlernte Wissen zu analysieren, zu hinterfragen und mit schon gelerntem aus anderen Themen zu vergleichen und zu kontrastieren.

Die Fähigkeit, komplexe Informationen zu durchdringen und logische Verbindungen herzustellen.

Lernziel: Ich kann komplexe Informationen durchdringen, zerlegen und logische Beziehungen erkennen. Auch zu anderem bisher gelernten. Das Ergebnis dieser Lernstufe ist die Fähigkeit, das Gelernte zu analysieren und zu hinterfragen.

Daher ist diese Ebene und Ihre Fragestellung auch mit der nächsten so wichtig, um langfristig zu behalten was man gelernt hat (verknüpfungen und kontrastierung zu anderem was man schon kann). Außerdem: Wenn man sich von Anfang an mit diesen Fragen beschäftigt, kriegt man in der gleichen Lernzeit Ebene 1-3 quasi umsonst.

Beispiel: Ein Softwareentwickler könnte beispielsweise den Code eines Programms analysieren, um Fehler zu finden oder um zu verstehen, wie verschiedene Teile des Codes zusammenarbeiten. In einem Konflikt könnte ich die Argumente analysieren, um Bestandteile, Beziehungen zwischen den Argumenten und die dahinter stehenden Annahmen, deren Logik, und die historische Beziehung der konflikteten Parteien zu bewerten.

5. Evaluieren

Jetzt, wo wir das Wissen analysiert und zerlegt haben, geht es darum, dieses Wissen zu bewerten, zu kritisieren und zu priorisieren. Es geht darum, fundierte Urteile zu fällen und Kritik zu üben.

Fragen: "Ist diese These Valide?", "Wie effektiv ist diese Methode?", "Welche vor und Nachteile hat dieser Ansatz?", "Welcher andere Ansatz ist aus welchen Gründen besser?" oder "Welche Methode sollte ich priorisieren?" Diese Fragen helfen uns, das Wissen zu bewerten und Entscheidungen zu treffen.

Lernziel: Das Ergebnis dieser Lernstufe ist die Fähigkeit, das Gelernte kritisch anhand der für meine Situation relevanten Kriterien zu bewerten und Entscheidungen zu treffen. Es geht darum, das Wissen zu nutzen, um fundierte Entscheidungen zu treffen und Prioritäten zu setzen.

Tätigkeit: Führen von Debatten, Entscheidung zwischen Ansätzen, Bewerten von Projekten und Theorien. Hier geht es darum, das erlernte Wissen zu bewerten und zu priorisieren.

Beispiel: In einem Projekt oder bei der Softwareentwicklung verschiedene Strategien oder Umsetzungsmöglichkeiten bewerten und entscheiden, welche am besten umgesetzt werden sollte. Oder auch kleiner: Bewertung der Glaubwürdigkeit einer Quelle. Kritisches hinterfragen von Maßnahmen und (politischen) Entscheidungen.

6. Erzeugen

Einleitung: Die höchste Ebene ist das Erschaffen, bei dem ein neues oder originelles Werk entwickelt wird. Es geht darum, Wissen und Ideen auf innovative Weise zu kombinieren und neue Konzepte zu entwickeln.

Fragen: "Was wäre, wenn...?" oder "Wie könnte ich...?". "Könnte ich [Problem X] vielleicht auch ganz anders angehen?", "Kann ich diese Konzepte vielleicht auch so kombinieren?"

Lernziel: Kreativit und Innovativ eigene Ideen in Produkte umsetzen.

Tätigkeit: Entwickeln von Projekten oder Modellen. Schreiben von Texten. Entwerfen von Experimenten oder Prototypen.

Beispiel: Als Softwareentwickler entwickle ich eine Software. Ich schreibe ein Gedicht. Ich führe eine neue Software ein um ein altes Problem neu besser zu lösen.

Warum ist mir das so wichtig?

Seit den 1960er Jahren wird Blooms Taxonomie dazu verwendet, um einzuschätzen, wie gut ich und andere ein Thema verstanden haben. Und erst jetzt kriege ich raus, dass es a) existiert, und ich es b) dazu verwenden kann mein eigenes Lernen besser zu verstehen und zu vertiefen? Boah ey, wieso hat mir das in der Schule niemand erklärt? Oder wenn, wieso dann nicht auf eine Weise die ich verstanden habe? Ich fühle mich im Moment so, als wurde mir hier über Jahre etwas wichtiges vorenthalten.

So, das wars. Jetzt wisst Ihr so viel über das Modell und seine Ebenen wie ich auch. Nächstes mal soll es dann darum gehen wie man mit hilfe von KI sich selbst auf die Ebene des Lernens Katapultieren kann auf der man gerade sein will.

Bis dahin, bleibt neugierig und probiert es doch mal aus in diesen Kategorien über euer eigenes Lernen nachzudenken.

In meinem letzten Blog-Post habe ich mich mit Blooms Taxonomie beschäftigt. Mir hat dieses Modell viele Gedankenanstöße darüber gegeben, wie ich lerne. Ich habe die sechs Ebenen von Blooms Taxonomie vorgestellt und ihre Anwendung sehr knapp diskutiert. Heute möchte ich diese Ebenen vertiefen und anhand von Beispielen auf die Unterschiede zwischen den Ebenen eingehen sowie die jeweiligen Lernziele beleuchten. Mein Ziel ist es, mir und anderen, die Anwendung von Blooms Taxonomie in beim Lernen zu veranschaulichen. Los gehts!

Die Ebenen von Blooms Taxonomie:

1. Wissen

Die Grundlage für alles. Hier geht es darum, sich an Fakten und Informationen zu erinnern. (Wer hätte das gedacht? ;)

Fragen: "Was sind die Fakten?" oder "Was weiß ich über dieses Thema?"

Tätigkeit: Sich was merken. Hier helfen z.B. Gedächtnis-Tricks wie ein Gedächtnispalast, aber meine Empfehlung ist ein durchsuchbares Notizbuch als externalisiertes Gedächtnis zu führen. Warum? Weil das wunderbar für alle weiterne Ebenen verwendbar ist. :) Ich verwende derzeit Agenda, aber wenn ich jetzt neu anfangen würde, würde ich Logseq verwenden.

Lernziel: Ich kann dieses Wissen wiedergeben. Wenn Du aber nur auf dieser Ebene lernst, dann geht es Dir wie mir nach den Klausuren - eine Woche Später hatte ich das meiste erfolgreich wieder vergessen. :)

Beispiel: Welche Module und Funktionen gibt es grob in der Standardbibliothek meiner Programmiersprache? Oder: Welche Themen muss ich für die Klausur kennen? Welche Punkte hat jedes Unterthema?

2. Verständnis

Aufbauend auf Wissen, geht es jetzt darum Informationen zu interpretieren, zu erklären und erste Zusammenhänge herzustellen.

Es reicht nicht mehr aus, nur Fakten zu kennen, sondern es ist wichtig, ihre Bedeutung zu verstehen und sie in einen Kontext einzuordnen.

Fragen: "Kann ich das Gelernte in eigenen Worten erklären?" oder "Kann ich ein Beispiel für das Gelernte geben?" Damit kann ich das Gelernte verstehen und in einen Kontext einordnen.

Tätigkeit: Interpretieren, Erklären, In eigenen Worten wiedergeben, Zusammenfassen, mit schon gelerntem Vergleichen, Beispiele geben.

Lernziel: Ich kann das gelernte jemand anderem erklären. (Also unter andere dass, was ich hier gerade mache). Damit kriege ich selbst ein viel tieferes Verständnis der Materie, und vergesse es auch viel weniger. Hier greift die alte Volksweisheit: Wer lehrt, lernt zweimal.

Beispiel: vor einer Klausur einen guten und vollständigen Spickzettel zu schreiben ist super. Überraschung: den braucht man in der Klausur dann üblicherweise nicht. :) Warum hilft das? Weil man hier strukturiert die (Lern)-Notizen zusammenfasst. Gerne als Mind-Map oder als Info-Graphik. Optimal: In einer Lern-Gruppe oder einem Kollegen etwas erklären.

3. Anwendung

Mit dem Verständnis an der Hand, geht es jetzt darum Wissen in die Praxis zu übersetzen. Gefordert sind (noch) keine großen Übertragungsleistungen, sondern eine direkte Anwendung des Gelernten in bekannten Kontexten.

Fragen: "Wie kann ich das Gelernte in einer bestimmten Situation oder bei einer bestimmten Aufgabe anwenden?" oder "Welche Probleme kann ich mit diesem wissen lösen?" Es geht darum das Gelernt auf bekannte Probleme anzuwenden.

Tätigkeit: Anwenden, Ausführen, Durchführen. Hilft alles nichts, man muss es mal praktisch in bekannten und neuen Situationen anwenden.

Lernziel: Ich kann das Gelernte in ähnlichen Kontexten anwenden. Das Ergebnis dieser Lernstufe ist die Fähigkeit, einfache Problemlösungen durchzuführen. Es geht darum, das Gelernte in die Praxis umzusetzen und zu zeigen, dass man das Wissen nicht nur besitzt, sondern auch anwenden kann.

Beispiel: Ein Programmierer könnte eine Aufgabe aus Advent Of Code lösen um das dahinter liegende Konzept zu verstehen. Ein Administrator nach einer Schulung die Sicherheitseinstellungen eines Netzwerk Prüfen und verbessern. Ein Agiler Team-Teilnehmer ein neu gelerntes Projekt-Management Werkzeug in einem agilen Experiment ausprobieren.

Fazit

Beim Schreiben ist mir aufgefallen wie schwer es ist diese Ebenen kurz und Knapp vorzustellen. Es gibt ja noch drei weitere Ebenen, aber ich wollte eure geschätzte Aufmerksamkeit nicht noch weiter Quälen. :)

Daher habe ich hier abgetrennt. Diese ersten Ebenen sind zwar essenziell um zu verstehen wie das alles gemeint ist. Aber den eigentlichen Schatz heben wir erst auf der 4. und 5. Ebene: Analyse und Evaluation. Und darum geht es (sicher für den geehrten Leser völlig überraschend) in meinem nächsten Blog Post. :)

Vor einigen Wochen bin ich über ein wundervolles Youtube Video gestolpert, dass mich über Blooms Taxonomie des Lernens informiert hat. Bloom stellt darin eine faszinierende Methode vor, mit der man sich Wissen über ein Thema schnell und effektiv aneignen kann.

Das hat mich ein bisschen umgehauen, da ich in alle den Jahren in denen ich gelernt habe noch nie davon gehört hatte. Endlich ein brauchbares Modell, wieso manche meiner Lerngewohnheiten gut oder eben schlecht funktionieren. 

In kurz, Blooms Taxonomie ist ein Modell aus den 60' er Jahren, in dem er postuliert das es sechs Ebenen des Lernens gibt. Diese werden gerne als Pyramide visualisiert, was ich ungünstig finde → dazu gleich mehr.  

Die Pyramide fängt ganz unten (1) mit dem Auswendiglernen an. Dann lernt man (2) wie man Gelerntes erklärt. Dann (3) wendet man es direkt an. Dann lernt man (4) es mit anderem Wissen zu vergleichen. Dann es (5) gegen andere Ansätze zu priorisieren. An der Spitze der Pyramide (6) gewinnt man aus der Erfahrung aus der Anwendung, gewappnet mit den Analysen und Vergleichen, neue Erkenntnisse und Dokumentieren diese (zum Beispiel als Blog-Post).

Wenn man das sieht, erscheint es logisch, dass man diese Stufen brav der Reihe nach von unten nach oben durchläuft.

Und das ist der Clou - das ist genau falsch.

Stattdessen ist es viel schlauer, sofort mit dem Analysieren und Evaluieren anzufangen (Level 4 und 5).

Ja, das ist Anstrengender,  aber man kriegt damit die ersten drei Ebenen geschenkt, denn es passiert automatisch wenn man sich selbst mit den Fragen der Ebene 4 und 5 herausfordert.

Dazu kann mann jetzt auch noch Vergleichen wie sich das neue Wissen in das bereits gelernte einordnet, und Begründen, in welchem Kontext welcher der Ansätze die man kennt besser funktionieren.

Also: Versucht es mal! Nächstes mal gehe ich noch mal tiefer darauf ein was die einzelnen Ebenen ausmacht und danach, wie man KI dafür verwenden kann sich selbst beim lernen sofort auf Ebene vier und fünf zu katapultieren! 

Da ich sie selber nicht so soft benötige und dann immer vergesse wie sie heißen hier als Notiz an mich selbst:

• rich.inspect() ist super hilfreich um zu einem Objekt das man im Debugger vor Sich hat schnell eine Übersicht zu generieren was es kann und welche Daten es hat.
• objexplore.explore() baut auf rich auf und bietet einen interaktiven explorer mit im wesentlichen den gleichen Informationen.

Beide Tools sind super hilfreich, wenn man in einer (fremden) Code-Basis schnell einen überblick kriegen will wie Objekte interagieren und zusammenarbeiten.

Bei meiner Arbeit ist mir aufgefallen, dass viele Entwickler bei uns die Shell viel effektiver nutzen könnten, um ihre Arbeit besser und schneller zu machen. Da ich die Shell sehr viel nutze, habe ich dazu ein paar Ideen. 😇 Auf der anderen Seite gibt es immer wieder ein Nugget, das ich selbst nicht kenne – und das möchte ich natürlich auch lernen.  

In diesem Sinne: Ich freue mich über Tips, lasst uns gerne daraus einen Austausch machen, wie man seine Shell effektiv einsetzt.

Damit verständlich wird wie ich meine Shell verwende ist es wichtig zu verstehen dass es verschiedene Arten gibt einen Mac effektiv zu nutzen. Ich kategorisiere das für mich grob so:

• Fensterbasiert: Viele Fenster, oft klein, die sich gegenseitig teilweise verdecken. Spezialisierte Apps anstatt Monolithen. Terminal, Editor, Git GUI, Datenbank-GUI und ein Dokumentationsbrowser, anstatt einer IDE die alles inkludiert.
• Screen/Tmux Style: Auch viele Fenster, aber ohne das diese sich überlappen. Viel Full-Screen und oft ein Window Manger oder Terminal das sicherstellt das Fenster garantiert nebeneinander sind. IDEs arbeiten in der Regel so.
• Quake Shell-Style: Im wesentlichen irgend ein anderer Stil, aber mit einem globalen Shortcut, der jederzeit eine Shell in den Vordergrund bringt oder wieder verschwinden lässt - egal wo man gerade ist.
• Mehrere Desktops: Separation von Apps über mehrere Desktops oder Workspaces.

Ich bin ganz klar tief in dem Fensterbasierten Workflow verortet. Ich kenne natürlich auch die anderen Workflows, aber sie funktionieren für mich persönlich einfach nicht so gut. Ich finde überlappende Fenster wirklich großartig, weil ich damit auf einem sehr viel kleineren Bildschirm (14-Zoll-Notebook) genauso produktiv sein kann, wie auf einem sehr viel größeren Bildschirm. 

Ich hoffe sehr, dass die Apple-Vision bald so gut funktioniert und so leicht wird, wie ich es mir wünsche. Dann kann ich es mir meine Fenster fei um mich herum anordnen. Aber bis dahin bleibe ich bei überlappenden Fenstern.

Mir hat dieser Artikel über das Denken zweiter Ordnung sehr gut gefallen.

Er erklärt am Beispiel von 'Chestertons-Fence', warum es wichtig ist, vor Änderungen an Systemen das Denken zweiter Ordnung einzusetzen. Er nutzt dazu die Methapher eines Zauns über eine Straße. Diesen sollte man nicht einfach wegräumen, nur weil er nervt. Warum? Weil die Menschen die ihn gebaut haben hatten damit Aufwand, den Sie nicht einfach nur so zum Spaß investiert haben. Deren Gründe muss man verstehen um zu sehen ob der Zaun tatsächich weg kann, oder nach wie vor nötig ist.

Angenommen hinter dem Zaun befindet sich ein Straßenabschnitt, der mit Minen verseucht ist. Leider ist dies in der Ukraine ja ein häufiges Problem. Der Zaun sollte erst entfernt werden, wenn die Minen geräumt sind, um Todesfälle und Verletzungen zu vermeiden. Die Toten und Verletzten sind hier der Effekt zweiter Ordnung.

Denken zweiter Ordnung heißt also nicht nur zu hinterfragen, warum etwas so ist, wie es ist, sondern auch zu verstehen, warum die Menschen, die es geschaffen haben (in unserem Fall meistens Code), es auf diese Weise gebaut haben. Bevor ich Änderungen vornehme, sollte ich mir Zeit nehmen, um die Gründe für die ursprüngliche Gestaltung zu verstehen, da unbedachte Änderungen unerwünschte Effekte haben werden.

So zu denken finde ich nicht leicht. Oft misslingt es mir. Aber es ist für mich ein Ziel.

Was heißt das für uns Entwickler?

Besonders bei der Frage: Wieso sind unsere Systeme so wie sie sind? Ist das für mich super relevant. Aber auch immer wenn ich Programmiere. Wenn ich einen Zaun aufstelle, also z.B. etwas komplizierter mache als es sein könnte, dann schreibe ich einen Kommentar wieso ich mich gegen die einfachere Lösung entschieden habe, damit die nach mir kommenden verstehen ob meine - für Sie - überkomplizierte Lösung noch nötig ist. Wenn ich eine weiter reichende Entscheidung fälle, dann Dokumentiere ich diese gerne mit eineme Architektural Decision Record (ADR) der enthällt aus welchen Gründen wir uns so entschieden haben. Wenn ich eine Story schreibe, dann muss da nicht nur das Feature drauf, sondern eben auch der Grund dafür, damit ich oder andere später nachvollzieen können, wieso dieses Feature existiert, oder eben wieso es nicht mehr nötig ist. Idealerweise würde ich auch gerne vom Code über die Commits zur Story zurück kommen - aber das gelingt mir bisher regelmäßig nicht.

Fazit

Viele der Praktiken, die wir in der Softwareentwicklung als Standards ansehen, dienen eigentlich dazu, das Denken zweiter Ordnung zu erleichtern – ein wichtiger Zusammenhang, der oft unerwähnt bleibt, mir aber zunehmend klarer wird.

Ganz besonders wichtig ist mir aber der Respekt, im Zweifel sollte ich erst einmal annehmen das der andere sich etwas dabei gedacht hat. Bevor ich das nicht verstehe sollte ich nicht die Axt ansetzen.

Zu meinen Ikea Trådfri Leuchten habe ich mir jetzt einen Phillips Hue LED-Streifen dazu geholt. Letztlich aus drei Gründen:

• Weil die viel Heller sind als fast alle Konkurrenzprodukte
• Weil sie auch ZigBee verwendet und damit nahtlos in meine Ikea Trådfri infrastruktur passt (theoretisch…)
• Weil ich mir die Ikea Bridge sehr bewusst ausgesucht habe, weil sie eben ohne einen Cloud zwang daher kommt.
• Weil ich sie in einem Sonderangebot 3 Meter für 50 € bekommen habe.

Well, also der Klebestreifen auf der LED-Schlange verdient diesen Namen schon mal nicht. Nicht nur das man den in 10 cm Inkrementen abpulen musste, er klebt zwar prima an der Tapete - aber nicht am LED-Streifen. WTF?

Davon abgesehen ist er super hell und lässt sich über Tradfri gut anbinden und steuern. ABER: Tradfri pusht ihn NICHT nach HomeKit wie es das mit den anderne Ikea eigenen Produkten macht. 😣💩😣💩😣🤬

Software Updates spielt die Tradfri Basis auch nicht ein - aber ok, das kriege ich via Bluetooth hin, was der LED-Streifen auch noch kann.

Jetzt extra noch eine Hue Bridge zu kaufen, nur damit ich dieses eine Gerät auch in HomeKit schalten kann, sehe ich jedenfalls mal gar nicht ein. Also hab ich mein trusty schweizer Messer Python ausgepackt und mit etwas Code nachgeholfen das fehlenden Device von Trådfri nach HomeKit zu pushen. Et Voila. :-)

Fazit: Die Schaltzeiten leiden etwas, Kann durchaus auch mal eine Sekunde dauern, anstatt der fast instantanen schaltzeit der Lampen die direkt über die Tradfri Bridge gehen. Aber wurscht, keine extra Bridge, etwas Spaß mit Python und die Erfahrung das es leicht geht da beliebigen eigenen Code einzubinden, der z.B. schöne Hintergrund-Farbwechsel ambient Lights produziert.

Beim lesen dieses Interview mit Elon Musk (hier auch als Video) hatte ich wirklich Spaß.

Diese Dinge sind nichts neues - aber mir ist klar geworden dass ich in der Vergangenheit viel zu Wenig wert darauf gelegt habe Requirements als Dumm zu identifizieren und Los zu werden, sowie Prozesse zu löschen. Autsch. Mea Culpa - ich gelobe Besserung.

Hier vor allem für mich selbst archiviert:

Musk’s Engineering Philosophy:

Musk overviewed his five step engineering process, which must be completed in order:

1. Make the requirements less dumb. The requirements are definitely dumb; it does not matter who gave them to you. He notes that it’s particularly dangerous if someone who is smart gives them the requirements, as one may not question the requirements enough. “Everyone’s wrong. No matter who you are, everyone is wrong some of the time.” He further notes that “all designs are wrong, it’s just a matter of how wrong.”
2. Try very hard to delete the part or process. If parts are not being added back into the design at least 10% of the time, not enough parts are being deleted. Musk noted that the bias tends to be very strongly toward “let’s add this part or process step in case we need it.” Additionally, each required part and process must come from a name, not a department, as a department cannot be asked why a requirement exists, but a person can.
3. Simplify and optimize the design. This is step three as the most common error of a smart engineer is to optimize something that should not exist.
4. Accelerate cycle time. Musk states “you’re moving too slowly, go faster! But don’t go faster until you’ve worked on the other three things first.”
5. Automate. An important part of this is to remove in-process testing after the problems have been diagnosed; if a product is reaching the end of a production line with a high acceptance rate, there is no need for in-process testing. Additionally, Musk restated that he believes everyone should be a chief engineer. Engineers need to understand the system at a high level to understand when they are making a bad optimization. As an example, Musk noted that an order of magnitude more time has been spent reducing engine mass than reducing residual propellant, despite both being equally as important.

Inspiriert von diesem Video von 3Blue1Brown, hat sich mein Verständnis wie man über Covid-Tests nachdenkt, grundsätzlich gewandelt.

Zwar war mir schon sehr lange Bewusst, dass Test-Ergebnisse kontra-intuitiv sein können, weil sie eben auch Gesunde als krank erkennen können.

Das ist einfach nachzuvollziehen, wenn man einen Covid-Schnelltest anschaut. Die Güte dieser Tests wird fast immer mit zwei Zahlen angegeben: Sensitivität (wie viele der tatsächlich Kranken werden erkannt) und Spezifizität (wie viele der Gesunden werden auch als Gesund erkannt). Nehmen wir an unser Test hat jetzt 90% Sensitivität und 90% Spezifität (fiktive Zahlen für leichteres Rechnen - echte Zahlen kommen später).

Wende ich diesen Test jetzt auf 100 menschen in einem Land an, das Zero-Covid hat. Dann sollten trotzdem 10 Personen als Krank gemeldet werden. Was heißt das jetzt? Logischerweise nix, denn es sind ja alle Gesund.

Gehe ich stattdessen ins Krankenhaus auf die Covid-Station und mache den Test dort mit 100 Personen, dann sollten trotzdem 10 Personen als Gesund gemeldet werden. Was heißt das jetzt? Logischerweise auch nix, die Leute sind ja schon wegen Covid in Behandlung und nicht durch den Test plötzlich gesundet.

Und das ist die wichtige Denk-Änderung die 3Blue1Brown in seinem Video motiviert - man muss beim nachdenken über Testergebnisse einfach immer auch darüber nachdenken wie wahrscheinlich es ist das man tatsächlich Krank ist. (Bayes läßt grüßen)

Und jetzt kommt der Dreh - alles wird viel einfacher, wenn man von vorne herein nicht denkt dass der Test mir sagt ob ich gesund oder Krank bin, sondern:

Jeder Test hat ein Vorhersagekraft, und dieser Faktor verändert meine Wahrscheinlichkeit Krank zu sein.

Es wäre also viel Einfacher, wenn man bei Tests nicht Sensitivität und Spezifizität angibt, sondern daraus die Vorhersagekraft des Tests berechnet. Damit kann man dann nämlich plötzlich viel einfacher Denken und verstehen. Und insbesondere ist es viel einfacher eine 'Vorhersagekraft' nicht mit 'Wahrscheinlichkeit das ich Krank bin' zu verwechseln, was einfach jeder tut der sich mit dem Thema nicht intensiv auseinander setzt.

Und das beste: Wenn man nicht in Prozent, sondern in Verhältnissen rechnet, dann ist das sogar präzise!

Wie kommt man jetzt auf diese Vorhersagekraft (auch Bayes Faktor genannt)

Jeder Test ist durch zwei Zahlen (Sensitivität[welcher Anteil der Kranken wird erkannt], Spezifität[welcher Anteil der Gesunden wird als Gesund erkannt]) bzw. durch die Komplemente davon (Falsch-Negativ-Rate, Falsch-Positiv-Rate) bestimmt.

Interessiert man sich jetzt für die Frage was ein Positiver-Test aussagt, kann man aus dem Quotient von Sensitivität geteilt durch Falsch-Positiv-Rate die Vorhersagekraft eines Positiven Tests und aus dem Quotient von Falsch-Negativ-Rate geteilt durch Spezifität die Vorhersagekraft eines Negativen Tests erhalten.

Ein Beispiel: Angenommen ein Test hat Sensitivität 90% und Spezifität 95% (also Falsch-Negativ-Rate 10%, Falsch-Positiv-Rate 5%). Dann ist die Vorhersagekraft eines Positiven Tests 90%/5%=18. Das heißt, wenn ich einen Positiven Test habe, dann weiß ich, dass sich die Wahrscheinlichkeit das ich Krank bin 18 mal vergrößert hat zu dem wie sie vorher war. Und umgekehrt: Ein Negativer Test 10%/95%≈  1/10. In Worten: Ein Negativer Test verkleinert meine Chance krank zu sein um etwa eine Größenordnung.

🤯

Rechnet man in Prozent ist das leider nur eine Abschätzung, aber wenn man das ganze in Chancen) rechnet wird aus der Abschätzung eine präzise Formel!

🤯 🤯

Schauen wir also mal auf ein paar reale Zahlen an.

In Berlin (stand 13. Mai 21, sind nach Pavels Covid Tabelle) derzeit einer von 394 Personen Ansteckend.

Für einen Covid-Test den ich gerade da habe findet sich hier eine Sensitivität ~93,5% und Spezifität ~98%.

Die Vorhersagekraft eines Positiven Tests ist 93,5%/2% ~47. Demnach wächst meine Chance heute ansteckend zu sein von 1/394 um das fast fünfzigfache auf etwas mehr als 1/4.

Die Vorhersagekraft eines negativen Tests ist 6,5%/98%~0,06. Demnach wächst meine Chance Gesund zu sein um fast zwei Größenordnungen von 1/394 auf etwa 6,5/38.612.

Oh wie schön wäre es, wenn das auch überall so kommuniziert würde…