Wir haben zu viele Ebenen der Abstraktion verwendet

• In der Tech-Branche gibt es zunehmend Menschen, die nur gelernt haben, wie man Tools und Automatisierung nutzt, während die technische Tiefe – also das Verständnis dafür, wie die darunterliegenden Schichten funktionieren – schwindet
• Abstraktion macht Arbeit leichter, ähnlich wie ein Lenkrad oder eine Servolenkung, aber wenn etwas kaputtgeht oder eine Störung auftritt, sinkt die Wiederherstellungsfähigkeit, wenn niemand das Innere versteht
• Der Druck, schnell zu veröffentlichen und Kosten zu senken, bündelt viele Rollen in einer Person wie bei DevOps oder DevSecOps und führt zu mehr Automatisierung und weniger tiefem Verständnis
• Im Sicherheitsbereich kann blindes Vertrauen in das grüne Licht GUI-basierter Penetrationstest-Tools dazu führen, dass echte Kompromittierungen lange unentdeckt bleiben
• Wer Technik lernt, sollte nicht nur Trends hinterherlaufen, sondern die von Tools ersetzten Aufgaben auch selbst ausführen und die Haltung eines Engineers bewahren, der Code und die unteren Schichten durchdringt

---

Die Lücke im technischen Verständnis, die Abstraktion verdeckt

• Heute gibt es viele „Experten“, die wissen, wie man Tools konfiguriert, aber nicht verstehen, wie Technik in tieferen Schichten tatsächlich funktioniert
• Abstraktion an sich ist notwendig
  • Ein Lenkrad ist eine Abstraktion, die das Fahren eines Autos erleichtert
  • Eine Servolenkung ist eine weitere Abstraktion, die das Fahrerlebnis noch verbessert
• Das Problem zeigt sich, wenn die Abstraktion bricht
  • Wenn niemand die zugrunde liegende Technik versteht, ist es schwer, die defekte Schicht zu reparieren
  • Auch wenn ein Tool Normalbetrieb signalisiert, kann man den tatsächlichen Zustand des Systems womöglich nicht beurteilen
• Die Tech-Branche wird stark von Gewinnzielen und Release-Geschwindigkeit getrieben
  • Dadurch werden mehr Abstraktion und Automatisierung eingeführt
  • Weniger Menschen müssen mehr Arbeit übernehmen
  • Statt tiefem Verständnis wird die Bedienung bestimmter Tools betont
• Die klassischen Rollen von Programmierern und Systemadministratoren verschieben sich hin zu Modellen wie DevOps und DevSecOps, bei denen Entwicklung, Sicherheit und Betrieb in die Rolle einer einzelnen Person gelegt werden
  • Da es schwierig ist, dass eine Person Entwicklung, Sicherheit und Systemadministration jeweils vollständig beherrscht, wird möglichst viel automatisiert
  • Das Ergebnis ist, dass moderne Fachkräfte zwar lernen, bestimmte Tools zu benutzen, über die zugrunde liegende Technik aber kaum etwas wissen

Welche Haltung Menschen brauchen, die Technik lernen

• Das moderne Leben hängt stark von Technik ab, aber die Technik selbst wird immer schwerer zu verstehen
• Auch im Sicherheitsbereich gibt es Kritik daran, dass viele nur wissen, wie man vorgefertigte Penetrationstest-Tools benutzt, von Sicherheit selbst aber wenig verstehen
  • Wenn in der Web-GUI eines Tools ein grünes Licht erscheint, wird leicht angenommen, dass alles in Ordnung ist
  • Selbst wenn ein echter Angreifer bereits ins System eingedrungen ist und Daten im Darknet verkauft, werden Datenabfluss oder Kompromittierung möglicherweise nicht entdeckt
• Als Beispiel dafür, dass manche Studierende nicht einmal das Konzept von Dateien und Ordnern kennen, wird ein Slashdot-Artikel verlinkt
• Für Menschen, die Technik lernen, sind folgende praktische Ansätze wichtig
  • Nicht nur Moden oder Trends folgen
  • Nicht nur Tools lernen, sondern verstehen, wie die zugrunde liegende Technik funktioniert
  • Wenn möglich, die Aufgaben, die ein Konfigurationstool übernimmt, wenigstens einmal manuell ausführen
  • Wenn möglich, den Code des Tools ansehen
  • Weiter lernen und experimentieren und sich tiefer in Technologien eingraben, die einen interessieren
  • Wenn möglich, ein Homelab aufbauen und es als Spielplatz zum Lernen und Kaputtmachen nutzen
  • Nach Dingen fragen, die man nicht versteht, und nicht automatisch annehmen, dass jemand anderes es schon besser weiß
• Das bedeutet nicht, dass jeder alles von den ersten Prinzipien her verstehen muss oder keine Tools verwenden darf
  • Abstraktion ist notwendig
  • So wie Lkw-Fahrer fahren und Mechaniker Lkw reparieren, gibt es Fachgebiete
• Das Kernproblem liegt darin, dass die ingenieurmäßige Haltung bei Menschen, die mit Technik arbeiten, schwächer wird
  • In der Softwareentwicklung werden zu viele Expertenrollen durch Tools und Automatisierung ersetzt
  • Immer weniger Menschen verstehen auch nur die Schicht direkt unter der, auf der sie arbeiten
  • Wenn Webentwickler ohne Wissen über TCP/IP, DNS, HTTP, TLS und Sicherheit nur mit vorgefertigten Tools oder Frameworks Websites bauen, sinkt ihr Nutzen erheblich, sobald Probleme auftreten

[GN⁺]

Hacker-News-Kommentare

• Auch in der Geschichte der Luftfahrt gab es eine Zeit, in der jemand, der ein Flugzeug fliegen konnte, es auch entwerfen und bauen konnte; ich frage mich, ob man sich damals ebenfalls Sorgen über eine Zukunft machte, in der Menschen im Cockpit sitzen, die die First Principles der Maschine nicht wirklich verstehen.
  Heute sind wir an die Vorstellung gewöhnt, dass Fliegen und Bauen getrennte Fähigkeiten und Berufe sind, und wir akzeptieren es auch ganz selbstverständlich, dass ein Luftfahrtingenieur nichts vom Bauxitabbau oder der Aluminiumschmelze verstehen muss.
  Es ist beruhigend, wenn man den gesamten Weg von Logikgattern bis zu Web-Requests überblicken kann, aber zwingend nötig ist es nicht. Dass es weniger Engineers mit einem solchen Gesamtüberblick gibt, ist weniger ein Warnsignal als vielmehr ein Zeichen für die Reife der Technologiebranche und die Ausdifferenzierung der Fachgebiete.

  • Das Problem ist, dass es sehr lange dauert, bis Technologie gut und zuverlässig genug wird, um wirklich ohne Verständnis betrieben werden zu können.
    Bei Aussagen wie „Lasst uns alle wieder zu Assembly zurückkehren“ etwa mussten Programmierer auch noch ziemlich lange, nachdem Hochsprachen Mainstream geworden waren, Assembly kennen. Selbst wenn man den Großteil der Arbeit in C oder Pascal erledigte, waren die Abstraktionen von Compilern und Debugging-Tools undicht.
    Das heutige Problem besteht darin, dass wir leaky abstractions schichtweise übereinanderstapeln, ohne ihnen Zeit zum Reifen zu geben. Sie werden unter der falschen Annahme entworfen, dass Entwickler immer nur auf dem Happy Path unterwegs sein werden, und sollen Arbeitszeit sparen; tatsächlich geht aber der größte Teil der Zeit fürs Debugging von Situationen drauf, in denen es nicht wie geplant läuft. Wenn man den Happy Path schneller macht, aber den Unhappy Path langsamer, ist das in der Regel ein Nettoverlust.
  • „Eines Tages werden die Sterne so vertraut sein wie die Wegweiser, Kurven und Hügel auf dem Weg nach Hause, und eines Tages wird dies das Leben in der Luft sein. Doch bis dahin werden die Menschen vergessen haben, wie man fliegt. Sie werden Passagiere in Maschinen sein, gesteuert von Fahrern, die sorgfältig dazu befördert wurden, sich an beschriftete Knöpfe zu gewöhnen, und in ihren Köpfen wird das Wissen um Himmel, Wind und die Wege des Wetters so unnötig sein wie eine vorüberziehende Fiktion.“ — Beryl Markham, West with the Night, 1942
  • Der Copilot von Air France 447 scheint zu dieser Beschreibung zu passen. Er kam so schnell wie möglich auf hochautomatisierte Airbus-Muster und hatte nur 250 Stunden Erfahrung auf anderen Flugzeugtypen.
    Weil die Airbus-Automatisierung einen Strömungsabriss nahezu unmöglich macht, solange nicht etwas massiv schiefgeht und das System auf Direct Law zurückfällt, verstand er nicht richtig, wie ein Stall funktioniert. Genau das passierte auf diesem Flug, und als der Kapitän ins Cockpit zurückkehrte, erkannte er den tiefen Stall sofort, aber es war bereits zu spät.
    Zugehöriges Mentour-Pilot-Video: https://invidious.protokolla.fi/watch?v=e5AGHEUxLME&t=1
  • Ich sehe bei dieser Analogie einige Probleme. Es ist nicht einmal klar, ob der Originaltext wirklich ein Verständnis auf Ebene der First Principles fordert; außerdem muss nicht jeder an einer Universität Flugwissen oder eigene Flugfähigkeiten haben, und fürs Fliegen gibt es Alternativen.
    Der Flugprozess hat von Anfang an physische Grenzen, aber Computing und die Denkrahmen dafür sind endlos veränderlich und haben einen breiten Anwendungsbereich. Überträgt man den Unsinn, der heute verkauft wird, auf die Luftfahrt-Analogie, ist es eher so, als würde man Eselsreiten als Fliegen verkaufen. Ein beträchtlicher Teil der Kunden hat nicht das Wissen, den Unterschied zu erkennen.
    Eine wichtige Zutat für Fortschritt ist, dass man erst dann einen großen Sprung auf einer Grundlage machen kann, wenn man herausgefunden hat, wie man etwas einfacher macht. Wird es zu komplex, gibt es Grenzen dafür, wie weit und hoch man kommt. Es ist ein bisschen so, als hätte man technische Schulden auf Menschheitsmaßstab vergrößert.
    Leider erkennen wir in der Geschichte schlecht die Momente, in denen etwas eine Stufe einfacher wurde. Rückblickend wirkt es nämlich ganz selbstverständlich.
  • Wenn die Titel und Stellenbeschreibungen von Piloten, Flugzeugmechanikern und Luftfahrtingenieuren so ähnlich wären, dass man sie kaum auseinanderhalten kann, wäre das ein Grund zur Sorge.

• Ich glaube, Kinder bekommen heutzutage nicht genug Anerkennung. Vor ein paar Wochen zeigte mir der Sohn eines Freundes ganz begeistert ein Roblox-Spiel, das er mit seinen Freunden baute.
  Es war kanadisches Thanksgiving, also waren viele Familienmitglieder und Bekannte da; er hatte schon vorher ausgesucht, welche Teile die einzelnen Leute interessieren würden, und ich war derjenige, dem er „Lua zeigen“ wollte.
  Die Leute denken, weil Smartphones oder Laptops abgeschlossen sind und keine Neugier wecken, seien Kinder auch nicht neugierig, aber mir scheint eher, dass Erwachsene weniger neugierig geworden sind.
  Natürlich baut das auf Abstraktionen auf, aber zwischen den Bergen hoher Abstraktionen gab es immer Täler, in die eine neugierige Minderheit hinabstieg. C64 BASIC erlaubte es, per POKE beliebige Speicheradressen zu beschreiben, aber es ist auch ziemlich cool, wenn einem ein zehnjähriges Kind ein komplexes 3D-Sammelspiel mit FPS-Elementen erklärt.

  • Spiele zu entwickeln halte ich für einen unterschätzten Einstieg in Programmierung und Softwareentwicklung insgesamt. Bei mir hat es funktioniert.
  • Roblox ist zwar ein geschlossenes, vom Unternehmen kontrolliertes Ökosystem, aber es ist programmierbar und offen genug, um sogar HTTP-Requests zu machen; als schlechtes Beispiel taugt es daher kaum.

• Das klingt nach einem alten Mann, der Wolken anschreit.
  Dass manche Leute Experten sind und andere nur so halbwegs zurechtkommen, ist nichts Neues. Nicht jeder kann ein Retter sein wie der Autor, der die Hälfte dieses kurzen Textes mit Selbstbeweihräucherung verbringt.
  Der Text hat kaum etwas mit Abstraktion zu tun. Nach den ersten beiden Absätzen verliert der Autor das Interesse an seiner eigenen These.

  • Die Texte auf dieser Seite sind im Allgemeinen so und landen gelegentlich auf der Startseite. Es gibt vieles, das emotional nachvollziehbar ist, aber der Autor kommt fast nie über „Ich bin der Klügste, und ich finde, das ist nicht gut“ als Argument hinaus.
  • Ich hatte zumindest konkrete Beispiele oder bestimmte Fälle erwartet, aber da war gar nichts. Auch ein „alter Mann schreit Wolken an“-Text kann in Ordnung sein, wenn er Beispiele oder Substanz hat, weil man daraus etwas lernen kann; in diesem Fall klingt der ganze Beitrag aber wie ein schlechter HN-Kommentar.
  • Geht mir ähnlich. Ich weiß nicht, wie dieser Beitrag so weit nach oben gekommen ist.
    Auch die Beispiele sind miserabel. „Jemand hat ein modernes Framework verwendet und wurde gehackt, aber die Performance-Probleme lagen nicht am Hack, sondern daran, dass das Framework furchtbar langsam war“ — doch welches Framework war es, wie konnte man allein am Diff erkennen, dass es langsam war, und was hat die Unfähigkeit, ein Tool auf Performance zu trimmen, mit Abstraktion zu tun?

• Ein weiteres Problem ist, dass wir mehrfach die falschen Abstraktionen übernommen haben. In der heutigen Softwarebranche gibt es eine arrogante Monokultur, die glaubt, am Ende der Geschichte angekommen zu sein und alles verstanden zu haben.
  Tatsächlich glaube ich, dass wir bei vielen neueren Technologien den falschen Weg eingeschlagen haben. Bis etwa 2014 schien alles in die richtige Richtung zu gehen, aber danach fühlte es sich so an, als ob der Fortschritt zurückgedreht wurde und alle anfingen, dieselben überhypten Frameworks zu verwenden. Weil Unternehmen diese Frameworks allen aufgezwungen haben, wurde Softwareentwicklung ineffizient und demotivierend.
  Ich habe ein SDK gebaut, das ich für persönliche Projekte nutze; es ist mindestens 10-mal produktiver als die Mainstream-Frameworks, die ich bei der Arbeit verwendet habe, und der Code ist viel leichter zu lesen und zu warten. Selbst wenn ich es einem Junior zeige, der das Framework nicht kennt, kann er damit produktiv arbeiten. Mit diesem SDK habe ich in Teilzeit in zwei Monaten eine No-Code-BaaS-Plattform gebaut; mit Mainstream-Tools und -Frameworks hätten ich oder jemand anderes das meiner Einschätzung nach kaum in 12 Monaten Vollzeit geschafft.

  • Wahrscheinlich ist dieses Framework nicht deshalb produktiv, weil es das beste verfügbare Framework ist, sondern weil du es selbst gebaut hast, seine Interna gut kennst und es gut zu deiner Denkweise passt.
    Natürlich kann es gegenüber anderen Frameworks Vorteile haben, aber Vertrautheit schafft Expertise, und Expertise schafft Produktivität.
    Bevor Trockenbauschrauben populär wurden, waren viele erfahrene Handwerker überzeugt, dass Schrauben langsamer und schlechter seien; aber sowohl ein Nagel-Experte als auch ein Schraub-Experte erledigen die Arbeit schnell und gut.
  • Zu der Aussage „Unternehmen zwingen allen dieses Framework auf“: Unternehmen bestehen aus Menschen, und man erwartet, dass die Entscheidungsträger mit Kontext und Wissen die richtigen Entscheidungen treffen.
    Es gibt Gründe, warum wir „diese Frameworks“ verwenden, ob im Frontend oder Backend. Diese Gründe mögen dir nicht gefallen, aber in der Unternehmensprogrammierung geht es nicht nur um die Reinheit einer Sprache, sondern um Faktoren, die Geld verdienen, wie Einstellbarkeit, Wartbarkeit und Kontinuität.
    Was passiert, wenn das Unternehmen dein maßgeschneidertes SDK nutzt und du gehst? Du magst glauben, man könne es anderen leicht beibringen, aber in technische Entscheidungen eines Unternehmens fließen sehr viel mehr Faktoren ein.
  • Mich würde dieses SDK interessieren. Ob du es öffentlich hostest, oder falls nicht, ob du zumindest erklären kannst, worin sich dein Ansatz von Mainstream-Frameworks unterscheidet.

• Die Aussage „Viele der sogenannten Experten von heute wissen nur, wie man irgendein Hype-Tool konfiguriert, verstehen aber auf einer tieferen Ebene überhaupt nicht, wie die Dinge funktionieren“ trifft mich stark.
  Alle kennen auswendig gelernte Abläufe wie „Um X zu tun, füge diese Zeile in die Konfigurationsdatei ein“, aber wenn man etwas tun muss, das nur leicht von X abweicht oder eine Variante von X ist, wissen sie nicht, wie sie vom Skript abweichen sollen. Schlimmer noch: Sie bringen Leute dazu, Zeit damit zu verschwenden, das Gespräch von nicht-ganz-X wieder zurück zu X zu lenken. Das erinnert an die Metapher, die verlorene Brieftasche nur unter der Straßenlaterne zu suchen.

• Ich finde es großartig, dass wir ein technisches Ökosystem geschaffen haben, eine Art „techosystem“, in dem man auch mit sehr engem Wissen beitragen kann. Weniger positiv formuliert heißt das auch, dass Unternehmen billigere Arbeitskräfte einstellen können, die weniger Technik beherrschen müssen.
  In vielen Fällen glaube ich, dass mittelmäßige Lösungen besser sind als gar keine Lösung. Das Internet von 1995 bis 2005 wurde auf mittelmäßigen Lösungen aufgebaut, und es hat wirklich Spaß gemacht.
  Tiefgehende Experten sind weder eine aussterbende Art noch eine knappe Ressource mit Geheimwissen aus der Zeit vor der Abstraktion. Im Gegenteil: Es gibt heute mehr davon als je zuvor. Sie definieren sich nicht dadurch, dass sie den Stack von oben bis unten durchgearbeitet haben, sondern durch die Neugier, auch in Bereiche hineinzuschauen, die nicht ihre eigene Schicht sind.
  Denn nicht nur oben kommen weitere Abstraktionsschichten hinzu; auch die unteren Schichten ändern sich, etwa mit NVMe, WebGPU, WebAssembly, QUIC und AVX512.
  Allerdings sind tiefgehende Experten ein Luxus, den die meisten Teams nicht brauchen, und ich denke, eine der wichtigsten Fähigkeiten technischer Führungskräfte ist zu wissen, wann man unbedingt so jemanden einstellen muss.

• Eine Zunahme der Abstraktionsebenen ist notwendig. Das menschliche Gehirn wird von Jahr zu Jahr nicht wesentlich leistungsfähiger, aber die Zahl der verfügbaren Werkzeuge wächst; um sich konzentrieren zu können, brauchen wir also Abstraktion.
  Ich denke nicht, dass das bedeutet, die Zukunft sei düster. Programmierer, die Geschäftsprobleme bearbeiten, können in Hochsprachen sehr produktiv sein, ohne EUV, Compiler, Assembly, Befehlssätze, Kernel, USB-Protokoll, HTTP, Dies, Leiterplatten usw. zu kennen. Auch Piloten müssen nicht alles über Aerodynamik, Zugfestigkeit, Aluminium, Gummi, GPS usw. wissen.
  Allerdings ist die Fehlanpassung von Anreizen in der modernen Gesellschaft durchaus eine Diskussion wert. Ich vertraue Piloten im Allgemeinen mehr als Business-Softwareentwicklern, Forschern oder Bankern. Wenn es zum Absturz kommt, ist der Pilot nämlich als Erster da.

• Software für ein Katapult erfordert einen anderen Ansatz als eine übermäßig generische CRUD-App, die so etwas wie die Anzahl deiner Villen offenlegt.
  Es gibt viel dumme Software auf der Welt, und das ist in Ordnung. Auch viele „echte Probleme“ sind ziemlich dumm und erfordern kein heroisches Engineering.
  In erschreckend vielen Fällen reicht einfach zusammengefrickelte Schrottsoftware völlig aus.
  Ich hasse das auch, aber ich komme zu dem Schluss, dass ich entweder mit meinem überlegenen Engineering selbst ein Geschäft aufbauen und die Konkurrenz schlagen muss, um zu beweisen, dass sie falschliegen, oder akzeptieren muss, dass ich nur Wolken anschreie.

  • Ein erheblicher Anteil der Software für Katapulte wird ebenfalls, wie oben beschrieben, ohne Source Control oder Unit-Tests zusammengeschustert.
    Krankenhäuser prüfen bei Kaufentscheidungen die Softwarequalität kaum über ein Niveau wie „dieser Button lässt sich nicht drücken“ hinaus.

• Es ist auf seltsame Weise passend, dass ein Text, der Abstraktion kritisiert, den Satz „Es gibt heute Studierende, die nicht einmal wissen, was Dateien und Ordner sind“ als Hyperlink setzt.
  Der Link führt zu einem Slashdot-Thread, von dort zu einem PC-Gamer-Artikel, der wiederum einen Verge-Artikel paraphrasiert und verlinkt, und der Verge-Artikel führt zu einer Frage auf Stack Exchange.

• Anders gesagt: Das ist Cargo-Cult-Programmierung. Ich habe vor zwei Jahren darüber geschrieben [1], und die Reaktionen waren polarisiert: entweder volle Zustimmung oder heftige Angriffe, es sei Gatekeeping
  Ich wünschte, es gäbe einen besseren Weg, diese Krankheit zu heilen, ohne das berufliche Immunsystem von Engineers zu triggern, die tief in ihre Lieblingstechnologien investiert haben
  [1] https://medium.com/the-engineering-manager-guide/cargo-cult-...

  • Ich denke, das war schon daran zu erkennen, dass er Ausdrücke wie „react expert“ und „node expert“ in Anführungszeichen gesetzt hat. Es ist ziemlich klar, dass er seine Rolle darin sah, offenzulegen, dass sie keine wirklichen Experten sind
    Die beiden verstanden die Frage nicht, aber er präzisierte sie nicht und zog auch nicht in Betracht, dass das Problem bei der Frage liegen könnte
    Den Satz „Ich bat einen React.js-Experten, verschiedene SPA-Ansätze zu vergleichen, etwa direkte DOM-Manipulation, MVC-basiertes clientseitiges Templating, komponentenbasierte DOM-Manipulation und das Kompilieren zu Vanilla JS“ verstehe ich ehrlich gesagt auch nicht
    Ich weiß nicht, ob „zu Vanilla JS kompilieren“ bedeutet, TypeScript zu JavaScript zu kompilieren, und was das mit dem DOM zu tun haben soll. Auch „MVC-basierte komponentenbasierte DOM-Manipulation“ klingt seltsam. Es wirkt eher wie jemand, der ein Buch über Design Patterns gelesen hat und Leuten Punkte abzieht, wenn sie nicht dieselben Begriffe verwenden wie er, nicht wie jemand, der Entwicklung tiefer versteht
  • Die Fragen in dem Artikel waren gut. Trotzdem finde ich es schade, dass wir vielleicht etwas Wesentliches verloren haben, weil es seltener geworden ist, dass Menschen Stolz auf ihre Fähigkeiten, ihre Arbeit und ihre Leistungen empfinden
    Wer echte Freude an der Zufriedenheit hat, eine Arbeit gut erledigt zu haben, verbringt meiner Ansicht nach meist mehr Zeit damit, etwas wirklich zu verstehen, als jemand, der die Arbeit einfach nur fertigbekommen will
    Aber was bringt uns diese Neugier? Mir fällt dazu diese Anekdote aus fortune(6) ein, und ich frage mich, wie viele Menschen ohne Neugier sie verstehen würden
    Ein Anfänger versuchte, eine defekte Lisp-Maschine zu reparieren, indem er sie aus- und wieder einschaltete. Knight sah das und sagte streng: „Man kann eine Maschine nicht reparieren, indem man sie einfach aus- und wieder einschaltet, ohne zu verstehen, was falsch ist.“ Knight schaltete die Maschine aus und wieder ein. Die Maschine funktionierte
  • Ich halte das Konzept Gatekeeping für wirklich schädlich. Wann immer dieser Vorwurf verwendet wird, steckt fast immer die implizite Annahme dahinter, dass Gatekeeping selbstverständlich schlecht sei
    Es wird als eine Art entscheidender Zug benutzt: „Du betreibst Gatekeeping, also habe ich gewonnen“ – eine absurde Vorstellung. Es ist nichts falsch daran, hohe professionelle Standards zu verteidigen, und genau das ist im Kern Gatekeeping. Wenn ich zum Arzt gehe, bin ich sehr froh darüber, dass Medizin ein Beruf mit Gatekeeping ist
  • Ich habe den Blogbeitrag gelesen, um zu verstehen, woher die negativen Reaktionen kommen, und er wirkt kämpferisch und arrogant. Es fühlt sich an, als wolle er Menschen mit Detailfragen abprüfen, um zu zeigen, dass er mehr weiß