Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Ein Schläger und ein Ball kosten insgesamt 1,10 $. Der Schläger kostet 1 $ mehr als der Ball! Wie viel kostet der Ball?
10 Cents? Herzlichen Glückwunsch, Sie sind gerade in die kognitive Falle getappt, die Daniel Kahneman in seinem Buch Thinking, Fast and Slow untersucht hat. Bevor wir fortfahren: Die richtige Antwort lautet 5 Cent. Aber natürlich rechnen die meisten Menschen nicht nach, sondern verlassen sich einfach auf ihr Bauchgefühl. Das ist nichts anderes als ein mentaler Reflex, den Kahneman System Eins nennt.
Laut Kahneman ist System Eins der automatische und intuitive Denkmodus des Gehirns, der oft zu schnellen Reaktionen führt. Dieses System unseres Gehirns ist stets reaktionsfreudig und sucht ständig nach Mustern, die es mit wenig Aufwand lösen kann. Die traurige Realität ist jedoch, dass dieses System oft falsch liegt.
Auf der anderen Seite steht System Zwei, ein langsamerer, bewussterer Prozess, bei dem man sich mehr Mühe gibt. Es fängt an zu funktionieren, wenn wir uns selbst davon abhalten, zu schreien "10 Cent". Dieses System verbraucht jedoch Energie und ist deshalb nicht die erste Wahl für unser Gehirn. Diese beiden Systeme tauchen nicht nur in Logikrätseln auf.
Für Entwickler bestimmen sie, wie Code geschrieben wird, wie Probleme behoben werden, ob Sie auf einen Build warten oder einen kurzen Blick auf Slack werfen, und vieles mehr. Wenn beide Systeme jedes Mal, wenn Sie Ihre IDE öffnen, funktionieren, stellt sich die Frage, welches System Sie häufiger verwenden und wie Sie das eine oder das andere nutzen können, um Ihre Entwicklungspraktiken zu verbessern? Lassen Sie es uns herausfinden!
Kahneman 101 - Schnelles und langsames Denken
Bevor wir uns damit beschäftigen, wie diese beiden Systeme zur Steigerung der Entwicklungseffizienz eingesetzt werden können, sollten wir uns ansehen, was sie eigentlich sind. Kahneman, ein Psychologe, der den Nobelpreis für Wirtschaftswissenschaften erhielt und diese Systeme vorschlug, wurde nicht für Finanzprognosen oder Marktvorhersagen ausgezeichnet.
Tatsächlich wurde er für eine Realität ausgezeichnet, die die Wirtschaftswissenschaftler lange Zeit ignoriert hatten. Die Tatsache, dass Menschen keine rationalen Entscheidungsträger sind. Kahneman verbrachte 50 Jahre seines Lebens damit, zu untersuchen, wie Menschen Entscheidungen treffen, wenn sie mit Unsicherheit konfrontiert sind. Die Ergebnisse seiner Arbeit haben die Annahme, dass Menschen auf der Grundlage von Logik und Vernunft entscheiden, völlig verändert.
In seinem Buch "Thinking, Fast and Slow" stellte Kahneman ein Modell des menschlichen Gehirns vor und behauptete, dass es in zwei Systeme unterteilt ist:
| Merkmale | Funktionsweise | |
| System 1 | Schnell
Emotional Günstige Intuitiv |
Dieses System zieht auf der Grundlage von Mustern voreilige Schlüsse, selbst wenn diese Muster irreführend sind. Es ist das System, das instinktiv schreit "10 Cents" bei dem Schläger-und-Kugel-Rätsel. Für Entwickler ist es das, was Sie sagen lässt "Sieht für mich gut aus" wenn man den Code sieht, aber nicht wirklich darüber nachdenkt. |
| System 2 | Teuer
Langsam Logisch Kontrolliert |
Dieses System wird aktiviert, wenn Sie sich selbst ertappen, bevor Sie die falsche Antwort schreien, oder wenn Sie ein bestimmtes Entwurfsmuster durchdenken, um herauszufinden, ob es für Ihre Projektarchitektur geeignet ist. Dieses System setzt sich jedoch nur dann in Gang, wenn Sie es dazu zwingen. |
Was bedeutet das alles für Entwickler? Die Antwort ist, dass Ihr Gehirn ständig zwischen einem "schnell, aber falsch" oder einer "langsam, aber richtig" Prozess. Aber hier ist der Haken: Wenn Sie müde und erschöpft sind, verwendet Ihr Gehirn automatisch System Eins, und das kann die Qualität Ihres Codes stark beeinträchtigen.
System Eins vs. System Zwei System Zwei - Was verwenden Entwickler am häufigsten?
Wenn Sie einen Entwickler fragen, auf welches System er sich am meisten verlässt, wird die Antwort mit Sicherheit System Zwei sein. Es ist langsam, logisch und erfordert Aufwand. All das passt perfekt zur Codierung. In einer Live-Umfrage haben sich sogar fast 90 % für System Zwei ausgesprochen. Sie haben nicht Unrecht. Und warum? Die meisten Entwickler brauchen tiefes, konzentriertes Denken.
Aber hier ist das Problem. System Zwei ist ziemlich teuer, da es eine begrenzte kognitive Ressource verbraucht, die wir gemeinhin als geistigen Treibstoff bezeichnen. Wenn dieser Treibstoff zur Neige geht, schaltet das menschliche Gehirn automatisch auf System Eins um, und wenn die Aufgabe immer noch Präzision erfordert, ist das einfach schade.
Ein ziemlich tolles Konzept, oder? Nun, es ist nicht nur Theorie. Verhaltenswissenschaftler haben reale und messbare Beweise dafür gefunden, dass unsere geistige Energie ähnlich wie ein Handy-Akku funktioniert. Jedes Mal, wenn Sie einen Code schreiben, ein Debugging durchführen oder verhindern, dass Sie abgelenkt werden, entleert sich der Akku. Dr. Gloria Mark, die 15 Jahre lang die menschliche Aufmerksamkeit untersucht hat, behauptet das:
- Die durchschnittliche Person überprüft ihre E-Mails 77 Mal pro Tag.
- Die Zeit, die vor dem Umschalten auf dem Bildschirm verbracht wird, beträgt nur 3 Minuten und 47 Sekunden.
- Es dauert 25 Minuten, bis man sich wieder voll auf die ursprüngliche Aufgabe konzentrieren kann, nachdem man abgelenkt wurde.
Die drei Minuten Wartezeit, die Sie auf einer Baustelle benötigen, um Ihre E-Mails abzurufen, kosten Sie also in Wirklichkeit 25 Minuten. Aber das ist nicht der schlimmste Teil. Jedes Mal, wenn Sie den Kontext wechseln, kehrt Ihr Gehirn automatisch zu System Eins zurück, selbst wenn Sie in System Zwei gearbeitet haben. Das ist der Grund, warum Fehler passieren, die Qualität sinkt und Sie am Ende schreiben "Okay-Code".
Ist "Okay Code" Schlimmer als schlechter Code?
Nicht jeder schlechte Code ist eine echte Bedrohung. Es gibt Zeiten, in denen "Okay-Code" genauso gefährlich sein kann, wenn nicht sogar noch gefährlicher. Was ist der Grund dafür? Er lässt sich kompilieren, er besteht die Tests, und er schlüpft oft unbemerkt durch Pull Requests.
Im Grunde genommen ist Code, der im System One-Modus geschrieben wurde, gerade gut genug, um unter dem Radar zu fliegen. Das Tüpfelchen auf dem i sind Code-Reviewer, deren geistiger Treibstoff aufgebraucht ist. Sie werfen einen Blick auf solchen Code und sagen, "Sieht für mich gut aus."
Diese Pipelines funktionieren von Haus aus wie Modelle des Systems Eins, und das Ergebnis ist mittelmäßiger Code, der zu einem mittelmäßigen Produkt führt. Kahneman merkt an, dass Wiederholung und Feedbackschleifen Fähigkeiten von System Zwei zu Eins verschieben können. Ist es also möglich, Entwicklern beizubringen, instinktiv besseren Code zu schreiben?
Techniken zum Schutz von System Zwei
Wenn es darum geht, all dies für die Effizienz von Entwicklern zu nutzen, sollten Sie zunächst wissen, dass System Zwei Ihr mächtigstes Werkzeug als Entwickler ist, aber auch das anfälligste. Aus diesem Grund muss es vor ständigen Ablenkungen geschützt werden, und es gibt viele Möglichkeiten, dies zu tun.
Zeitmanagement ist hier der Schlüssel. Systeme wie die Pomodoro-Technik, bei der man sich 25 Minuten lang konzentriert und dann eine 5-minütige Pause einlegt, können zwar effektiv sein, aber sie können auch nach hinten losgehen, wenn die intensive Arbeitssitzung genau dann unterbrochen wird, wenn man kurz davor ist, in den Flow zu kommen. Deshalb sollten Sie 25 Minuten als Minimum betrachten und erst dann weitermachen, wenn Sie in der richtigen Stimmung sind.
Abgesehen davon ist das Stapeln von Aufgaben auch eine großartige Technik, die System Two-Mechanismen schützen kann, da sie hilft, Kontextwechsel zu vermeiden. Entwickler können sogar verschiedene KI-basierte Tools verwenden, um ihren Zeitplan um Fokus-Sitzungen zu erweitern und gleichzeitig Raum für Meetings zu lassen - eine Win-Win-Situation. Der nächste Punkt auf der Liste ist der Schutz des mentalen Treibstoffs.
Die einzige Möglichkeit, das System vollständig zurückzusetzen, ist der Ruhezustand. Es gibt jedoch noch ein paar andere Techniken, die nützlich sein können. So kann es zum Beispiel helfen, Kaffee zu trinken und sich ein paar Minuten hinzulegen, bis der Kaffee seine Wirkung entfaltet. Darüber hinaus gibt es Dinge wie Achtsamkeit und Meditation. Das klingt nach Hippie-Kram, aber die Wissenschaft ist auf ihrer Seite.
Entwickler sollten dies tun, um die Praxis und die Effizienz zu verbessern
In erster Linie liegt all dem der Grundsatz zugrunde, dass qualitativ hochwertige Ergebnisse aus System Zwei kommen, d. h. der Zustand, in dem sich die Entwickler befinden müssen, wenn sie bessere Ergebnisse erzielen wollen. In Anbetracht dessen sollten einige wichtige Dinge ausprobiert werden:
- Guarding System Zwei Zeiten durch den Einsatz von Tools, die Deep-Focus-Slots planen und sich automatisch an die Verfügbarkeit anpassen, sowie durch Zeitblockierungsmethoden, um länger im Fluss zu bleiben.
- Einsatz von Automatisierung und KI zur Verringerung der kognitiven Belastung durch Zuweisung von sich wiederholenden Aufgaben an Automatisierungs- und KI-Tools, da dies Zeit spart und hilft, Kontextwechsel zu vermeiden.
- Die Zusammenfassung ähnlicher Aufgaben kann auch dazu beitragen, einen Kontextwechsel zu vermeiden, was den geistigen Treibstoff schont und die Konzentration aufrechterhält.
- Tanken Sie neue Energie mit Hilfe von Schlaf- und Achtsamkeitstechniken, denn diese können Ihre kognitiven Ressourcen schützen, so dass Sie länger im System Zwei bleiben können.
- Wenn etwas nicht in Ihr Fachgebiet fällt und zu viel Zeit in Anspruch nimmt, delegieren Sie es, damit Experten bessere und sicherere Lösungen entwickeln können. sichere Lösungen während Sie sich auf die Kernaktivitäten konzentrieren, die das Unternehmenswachstum fördern.
Abschließende Überlegungen
Daniel Kahneman hat "Thinking, Fast and Slow" zwar nicht für Entwickler geschrieben, aber die in dem Buch enthaltenen Erkenntnisse sind genau das, was Software-Teams am meisten brauchen. Die harte Realität ist, dass man funktionale Ergebnisse erhält, wenn man auf Autopilot programmiert. Aber am Ende verpasst man saubere und skalierbare Lösungen, die sich unter der Oberfläche verbergen.
Letzten Endes hat das Schreiben von großartigem Code nicht viel mit Talent oder Können zu tun. Es geht darum, die richtige Einstellung zu haben, die Einstellung von System Zwei. Heute ist es ein Wettbewerbsvorteil, zu erkennen, wann man in System Eins abrutscht, und seinen Arbeitsablauf so zu gestalten, dass man länger in System Zwei bleibt.
Wenn Sie also das nächste Mal programmieren, halten Sie inne und fragen Sie sich, ob Sie schnell oder intelligent programmieren!
