Re: The Flow Zone

[Ralf Westphal]

In der Beschreibung des Prinzips sprechen wir zwar von Flow, aber eher im landläufigen Sinn. Da kann man sagen, man sei "im Flow gewesen" oder etwas sei flüssig von der Hand gegangen, ohne gleich den "meditativen Zustand" zu meinen, den Csikszentmihalyi erstmals für die Psychologie beschrieben hat: http://de.wikipedia.org/wiki/Flow_(Psychologie).

Im Deutschen ist "flüssig von der Hand gehen" oder "die Arbeit fließt" auch ein älterer Ausdruck als Csikszentmihalyis Flow.

Um Verwirrung zu vermeiden, hätten wir vielleicht besser eine deutsche Formulierung benutzen sollen.

Letztlich geht es bei PoLA nur darum zu vermeiden, mentale Stolpersteine zu vermeiden, die den Arbeitsfluss ins Stocken bringen. Wer 100m Sprint läuft, möchte keinen Bällen ausweichen müssen, die plötzlich auf die Laufstrecke rollen.

Überraschungen (vor allem negative im Sinne von Unverständlichkeiten und Unüblichkeiten) sind solche Stolpersteine.

Bei den Tugenden steht PoLA deshalb unter "5. Halte Versprechen ein" (http://clean-code-developer.de/Tugenden.ashx). Das bedeutet: Flüssiges Arbeiten kann nur entstehen, wenn Vertrauen da ist. Vertrauen braucht Gemeinsames, Absprachen, Verlässlichkeit.

Wer in Vokabular oder Struktur sich dann jenseits dieses Vertrauensbereichs bewegt, der erzeugt Reibung.

Zu Robert C. Martin: Martin spricht von Csikszentmihalyis Flow. Wenn er ihn als hinderlich für die Softwareentwicklung empfindet, dann ist das seine persönliche Sichtweise. Aus dem Abschnitt wird mir nicht klar, was sein Problem damit ist - und sogar für so wichtig zu erwähnen hält, dass er es in sein Buch aufnimmt. Übertragbare Erfahrung, gar eine Fundierung in Theorie oder allgemeinerer Praxis fehlt.

Aus meiner Sicht ist dieser "echte" Flow kein Thema, das wir derzeit länger in Entwicklerkreisen erörtern müssten. Ich sehe einfach nur, dass er bei vielen entstehen könnte. Es fehlen schlicht die Bedingungen. Es gibt viel zu viele Störungen, die von außen eingreifen oder selbstgemacht sind.

Deshalb würd ich eher sagen: Wer mal in den Zustand kommt, sollte ihn genießen. Er kann für die Motivation viel mehr bringen, als er dem Code abträglich ist. (Wenn denn überhaupt der Code dadurch Schaden leiden sollte.)

Am Donnerstag, 3. Januar 2013 13:11:16 UTC+1 schrieb Leif Battermann:

Hallo,

was hier: http://www.clean-code-developer.de/Principle-of-Least-Astonishment.ashx im ersten Absatz über den "Flow" gesagt wird, soll wohl eine Motivation für das POLA sein. Dies kann ich auch soweit gut nachvollziehen. Allerdings zeichnet Robert C. Martin ein ganz anders Bild von "Flow" in dem Buch "The Clean Coder" in Kapitel 4, S. 62.

Ich finde das ganz interessant, da die beiden Ansichten so konträr sind. Klar ist das ein schwieriges Thema, welches man nicht immer schwarz-weiß betrachten kann. Ich denke, dass es viele verschiedene Möglichkeiten gibt, damit umzugehen. Und es ist schwer etwas allgemein gültiges dazu zu verfassen. Was meint ihr dazu?

[Leif Battermann]

Ich finde es gut, dass du die beiden Definitionen von Flow differenzierst. Wie gesagt, im Zusammenhang mit dem PoLA macht die Erklärung meines Erachtens auch sehr viel Sinn.

Damit hätten wir dann ja diesen Aspekt schon einmal von Robert C. Martins Ausführungen zu dem Thema getrennt und der vermeintlich Widerspruch ist aufgehoben.

Zu Martins Beschreibung kann ich sagen, dass sie für mich durchaus auch Sinn macht. Ich habe ähnliches schon an mir selbst beobachtet. Neben einigen positiven Auswirkungen gibt es mit Sicherheit auch ein paar negative. Was mir selbst schon passiert ist, ist z.B.: 

- Vergessen zu Essen -> Gesundheit / Wohlbefinden leidet

- Wenig Schlaf -> siehe oben

- Nicht lösen können -> Man fährt sich in Problemen und Details fest

- Man möchte nicht herausgerissen werden -> Vermeidung von objektiver Betrachtungsweise, dadurch unsauberes Design

- KISS wird verletzt

- Es wird etwas implementiert, wofür es keine Anforderung gibt

und so weiter. Trotzdem möchte ich diese Momente des Flows nicht missen.

Irgendwie ist "Flow" so etwas wie kanalisierte Konzentration. Dies kann gut aber auch schlecht sein, wenn kanalisiert bedeutet, dass man es nicht schafft, "nach links und rechts zu schauen".

Ich denke, da kann man nun lange diskutieren und verschiedener Ansicht sein, aber Fakt ist, dass der meditative Flow nicht unproblematisch ist. Ich kann Martins Ausführung gut verstehen und finde es gut und interessant, dass er diese in sein Buch aufgenommen hat.

Man kann hier mal wieder die Analogie zum Künstler oder zu den Martial Arts nehmen, finde ich. Ist es nicht so, dass mit zunehmender Expertise und Mastery immer verantwortungsvoller und gezielter mit dem Flow umgegangen werden kann? Ein Programmieranfänger wird sich nicht so gerne "aus dem Flow reißen lassen", um sich um vermeintlich lästige Design Prinzipien zu kümmern. Ein Erfahrener Programmierer hingegen hat diese schon längst verinnerlicht und kann auch "in der Flow Zone" eine objektive Beurteilung des Designs machen und dieses anpassen.

Mich würde mal interessieren, wie andere das mit dem meditativen Flow sehen?

Ich selber finde es, wie gesagt, ambivalent.