Robert C. Martin – The Clean Coder (unvollständig)

Professionalität

Ich übernehme selbst die Verantwortung, dass mein Code:

  • keinen Schaden anrichtet
  • funktioniert (für alles Tests Schreiben)
  • leicht zu ändern ist (Flexible Struktur)

Investiere jede Woche 20 Stunden für meine berufliche Weiterbildung, diese 20 Stunden sollten möglichst viel Spaß machen.

Sollte die Standards der vergangenen 50 Jahre kennen (z. B. Design Patterns, Design-Prinzipien, Methoden, Disziplinen, Artefakte) Buch Seite 49.

Je nachdem was ich programmiere, sollte ich mich mit der Materie auseinandersetzen, so dass ich die fachlichen Anforderungen hinterfragen kann.

Programmieren ist ein schöpferischer Akt, weil wir aus dem nichts Ordnung ins Chaos bringen. Somit ist das Programmieren ein Akt der höchsten Arroganz. Profis wissen, dass sie Arrogant sind.

Nein Sagen

Mach es oder lass es. Es gibt kein Versuchen.

Yoda

Wenn das Produkt zur Fertigstellung 2 Wochen braucht, dann kann ich es nicht in 1 Woche Schaffen, auch nicht unter starken druck, vom Chef höchst Persönlich. Weil der Profi weiß, wie viel mehr Arbeit man mit fehlerhafter Software hat.

Ich kann natürlich auch am Wochenende Arbeiten, wenn die Familie nichts dagegen hat, jedoch muss ich dann in der Woche mein Wochenende nehmen, weil meine Kreativität eine Pause braucht um sich zu regenerieren.

Wenn ich für ein Produkt länger als erwartet brauche, weil unvorhersehbare dinge geschehen, dann sage ich so früh wie möglich Bescheid.

Ein intaktes Team findet Wege, um Ja zu sagen, auch wenn Entwickler und Manager miteinander verhandeln werden. Der Weg um ein Ja zu bekommen geht nur dann auf, wenn wir keine Angst haben vor ein Nein.

Profis sind oft Helden, aber nicht, weil sie es darauf anlegen. Profis werden Helden, wenn die ein Auftrag gut, rechtzeitig und im budgetiertem Rahmen erledigen.

Wir alle müssen realisieren, dass es nicht der Lösung unserer Probleme dient, wenn wir bereitwillig unsere professionelle Disziplin über Bord werfen. Auf diese Weise schafft man überhaupt erst Probleme.

Ja Sagen

Sagen.Meinen. Machen.

Roy Osherove

Ein Commitment, also eine verbindliche Aussage besteht aus 3 Teilen:

  1. Sie sagen, dass sie es machen werden.
  2. Sie meinen es.
  3. Sie machen es dann auch tatsächlich.

Präzise Aussagen treffen!

So erkenne ich mangelnde Selbstverpflichtung in der Sprache:

  • sollte
  • müsste
  • hoffe
  • wünsche
  • wir können
  • versuche

Nur über die dinge Aussagen treffen die in meiner Hand liegen, das sind mehr als gedacht. Sobald ich mich auf jemand anderen verlasse, muss ich das in der Schätzung angeben und mit beachten und die Kommunikation muss gefühlt übertrieben werden.

Dann werde ich als Programmierer ernst genommen und mein Wort bedeutet was, das ist schon sehr viel Wert.

Also zusammen gefasst, ich muss nicht zu allem Ja sagen, allerdings lege ich mich richtig ins zeug, um kreative Wege zu finden, damit ein Ja möglich wird.

Programmieren

Programmieren ist eine intellektuell herausfordernde und anstrengende Aktivität. […] Der Grund dafür ist, dass man beim Programmieren mit mehreren, einander widersprechenden Faktoren gleichzeitig jonglieren muss.

Mein Code muss:

  • Funktionieren
  • das Problem/den Fehler lösen
  • gut ins vorhandene System passen
  • von anderen Programmierern lesbar sein

Ich programmiere nie, wenn meine Gedanken mit etwas anderem beschäftigt sind, weil ich so unglaublich viele Fehler machen werde oder einfach zu kompliziert Programmiere. Einfach gesagt muss ich den Code nochmal neu schreiben oder komplett bearbeiten.

Den sogenannten „Flow-Zustand“ werde ich vermeiden, denn da überlege ich nicht bewusst und programmiere nur so vor mich hin, in einem leichten meditativen Zustand. TDD ist hier die perfekte Lösung.

Wenn es zu Schreibblockaden kommt, dann sollte ich schnell herausfinden, was die Ursachen dafür sind, z. B. Schlafmangel und dann gegen Maßnahmen ergreifen.

Input = Output

Wenn mir die Kreativität fehlt, dann muss ich mir einfach für neuen kreativen Input sorgen.

Die Zeit zum Debuggen gehört in die Zeit Kalkulation!

Ich werde mein Projekt verspätet abgeben, der Trick ist frühzeitiges Erkennen und Transparenz.

Sich zu beeilen ist nicht möglich, denn ich kann mich nicht dazu zwingen schneller zu programmieren, das geht nicht, ganz zu schweigen von den vielen Fehlern, die einem dann extra viel Zeit kosten werden.

Ich mache nur Überstunden wenn:

  • ich es mir persönlich leisten kann
  • es nur einen kurzen Zeitraum beträgt (1-2 Wochen)
  • mein Chef einen Notfallplan hat, falls die Überstunden nicht reichen

Programmieren ist schwer. […] beginnen Sie zu erkennen, dass die Art, wie Sie diese if- und while-Anweisungen kombinieren, von zentraler Bedeutung sind.

Es ist ganz normal sich Hilfe zu holen und selber Hilfe anzubieten, manchmal sogar notwendig.

Test Driven Development (TDD)

Gehört zu den Typischen Agilen Methoden und kann als Testgetriebene Entwicklung versanden werden, wobei immer erst die Tests geschrieben werden und dann erst den Code.

TDD funktioniert einfach sehr gut, da gibt es nichts zu bestreiten.

Löst folgende Probleme:

  • Wie kann ich wissen das mein gesamter Code funktioniert?
  • Wie kann ich Testen das mein Code auch nach meiner Änderung funktioniert?
  • Wie kann ich nach einer Änderung Testen, wenn ich keine Unit Tests habe die automatisiert loslaufen?

3 Gesetze der TDD

  • Erst dann Code schreiben, wenn vorher der Test fehlschlägt.
  • Schreibe den Test nur minimal weiter, gerade so das er scheitert (nicht kompilieren).
  • Gerade so viel Code schreiben, dass der Test bestanden ist.

Diese 3 Gesetze sind dann ein Zyklus, der ca. alle 30 Sekunden wieder holt wird, dadurch wird der Code perfekt von den Tests abgedeckt.

Vorteile

Gewissheit

Sobald alle Test bestanden sind, kannst ich mir sicher sein das meine Änderung nichts schon vorhandenes Kaputt gemacht hat.

Injektionsrate für Defekte

Diese Rate ist sehr gering und hilf so für missionskritische Anwendungen (Medizin, Strom, Finanzen, usw…)

Courage

Ich kann schlechten Code sofort Fixen, ohne angst haben zu müssen, dass ich damit etwas anderes kaputt mache somit verbessert sich die Codebasis idealerweise kontinuierlich.

Der Code wird zu Lehm.

Dokumentation

Sobald ich Bibliotheken verwende, die ich nicht geschrieben habe, dann gucke ich mir in der Doku zuallererst die Codebeispiele an. Warum? Weil der Code nicht Lügen kann.

Wenn ich die 3 Gesetzt der TDD befolge dann gelten meine Tests als Dokumentation, die exakt beschreiben, wie man mit dem Code umzugehen hat.

Zudem ist die TDD Dokumentation unzweideutig, allumfassend und in einer Sprache geschrieben die der Nutzer versteht.

Design

Wenn ich TDD befolge, dann schreibe ich zuerst den Test der Funktion und das Zwingt mich im Vorfeld ein gutes Design zu benutzen.

Tests die ich später Schreibe können mein Code nicht im geringsten so gut abdecken wie die Tests, die ich im Vorfeld schreibe.

Die Proffesionelle Option

Das Fazit kann nur lauten, TDD selbst zu nutzen.

Es handelt sich um eine Disziplin, die Gewissheit, Courage, Defektreduktion, Dokumentation und Design verbessert.

Bei all den Vorteilen ist es unprofessionell sie nicht einzusetzen.

Was TDD nicht ist

Es ist keine Zauberformel, mit der ich nur sehr guten Code schreiben kann, dem ist nicht so.

Praktizieren und Üben

Alle Profis verbessern sich in ihrer Kunst, indem sie Übungen durchführen, um ihr eigenes Geschick zu verbessern.

Hintergrund übers Üben

Programmierer üben für gewöhnlich leider nicht, weil es für die Anfangszeit so nicht notwendig war, weil alles noch sehr lange dauerte und somit an Finetuning noch nicht zu denken war.

22 Nullen

Die heutige Rechenpower der PCs ist im Vergleich zu den frühen Tagen des Programmierens ist um mehr als 6,4 x 10²² gestiegen, eine Zahl, die unvorstellbar ist.

Es ist jedoch erstaunlich, dass wir genau mit denselben mitteln Code schreiben wie am Anfang (z. B. if-Anweisungen).

Durchlaufzeiten

1960ern musste man noch 1 bis 2 Tage Warten, um ein Kompilierungsresultat zu bekommen, 1970 musste man noch 1 Stunde warten, das ging bis in die 1990er so. Heute sind es nur noch Minuten.

Das heißt aber nicht, nur weil ich jetzt nicht mehr auf ein Ergebnis warten muss, dass ich es einfach schnell runterprogramieren kann.

Alles, was man schnell machen will, muss man üben.

Beim Programmieren hängt die Geschwindigkeit von der Übung und der Praxis ab und dabei wähle ich immer wieder aus einem Repertoire von Problem und passenden Lösungen aus, bis ich diese wie automatisch kann.

Kata

Das kommt das dem Kampfsport und ist ein genau festgelegte Bewegungsabfolge um den Kampf auf einer Seite zu Simulieren. Das Ziel ist es die Bewegung so gut zu können das man diese in Kampf automatisch ausführen kann, wenn man sie braucht.

Übertragen auf das Programmieren, simulierst du die Lösung eines Programmier Problems. Die Lösung ist dir bereits bekannt, es geht darum Bewegungen und die Entscheidungen während des Programmieren zu üben.

Waza

Ist ähnlich wie das Kata nur zu zweit. Der eine Programmierer schreibt einen Unit Test und der andere schreibt den Code um diesen zu bestehen, dann werden die Rollen getauscht.

Randori

Ist ähnlich wie das Waza nur mit sehr viel mehr Leuten und er Bildschirm wird an die Wand Projektiert, dammit alle sehen können wie der Code funktioniert.

Die eigene Erfahrung ausbauen

Programmierer sind oft gezwungen sehr einseitig zu Arbeiten, das schadet die Mentalität und den Lebenslauf außerdem ist das von nachteil, wenn die Branche wieder einmal komplett verändert wird.

Open Source

Die gibt es wie Sand am Meer und wahrscheinlich gibt es keinen besseren Weg, um das eigene Repertoire zu erweitern, als tatsächlich an etwas zu Arbeiten, dass für jemanden anderes wichtig ist.

Etnisch handeln

Professionelle Programmierer üben in ihrer Freizeit.

Es liegt jedoch bei mir in welcher Sprache ich mich übe, es sohlte jedoch eine andere seil als auf Arbeit.

Schlussfolgerung

Alles Profis über auf die ein oder andere weise, weil Sie ihren job best möglich erledigen wollen. Sie über in ihrer Freizeit, weil Sie wissen das es in ihrer Verantwortung liegt sich weiter zu entwickeln.

Üben ist das, was Sie tun, wenn Sie nicht dafür bezahlt werden. Das machen Sie, damit Sie bezahlt werden, und zwar gut!

Akzeptanztests

Ein professioneller Entwickler muss in seiner Rolle sowohl kommunizieren als auch programmieren.

Anforderungen kommunizieren

Die Kommunikation von Anforderungen sind in der Praxis extrem schwierig und der Prozess ist sehr fehleranfällig.

Kunden merken dann was Sie eigentlich brauchen, wenn Sie die Funktionalität des fertigen Programms testen und abnehmen.

Verfrühte Präzisierung

Die vom Business wollen immer vorher exakt wissen, was sie kriegen, bevor sie ein Projekt autorisieren. Entwickler wollen genau wissen, was von ihnen bei Ablieferung erwartet wird, bevor sie eine Kalkulation des Projekts abgeben.

Das Prinzip der Ungewissheit

Der Auftraggeber (AG) benötigt Prototypen die ihm Vorgeführt werden, um noch einige Informationen zu bekommen die sich dann auf die Anforderungen auswirken, d. h. ich werde den AG ziemlich oft mit einbeziehen.

Angt vorm Einschätzen

Beim abschätzen der Entwicklungsarbeit ist keine Präzision erforderlich, weil das Prinzip der Ungewissheit nahe zu unmöglich macht, weil die Anforderungen sich ändern können, und weil eine Schätzung eine deutliche Streuung aufweist.

Profi Programmierer wissen, dass diese Schätzwerte nur Schätzwerte sind und fertigen Wahrscheinlichkeitsverteilungs Diagramm an.

Späte Mehrdeutigkeit

Die Lösung für eine vorzeitige Präzisierung ist, sie möglichst lange hinauszuschieben. Professionelle Entwickler arbeiten eine Anforderung erst dann weiter aus, kurz bevor sie sie direkt entwickeln.

Jetzt kann es jedoch dennoch zu einem Problem führen: die späte Mehrdeutigkeit.

Eine Mehrdeutigkeit in einem Anforderungsdokument steht für einen Konflikt bei den Stakeholdern.

Tom DeMarco

Akzeptanztests

Die Definition of Done

Professionelle Entwickler haben eine einzige „Definition of Done“. Done bedeutet done, also fertig und abgeschossen. Das bedeutet: Der gesamte Code ist geschrieben, hat alle Tests bestanden, und die Qualitätssicherung sowie die Stakeholder haben ihn akzeptiert. Also alles „fertig“.

Kommunikation

Der Zweck der Akzeptanztests ist Kommunikation, Klarheit und Präzision.

Es müssen alle Parteien miteinander Sprechen damit jeder weiß was erstellt wird.

Automatisierung

Akzeptanztests sollten immer automatisiert werden.

Zusätzliche Arbeit

Das Schreiben solcher Tests gehört einfach zu der Arbeit, das System näher zu spezifizieren.

Also betrachten Sie diese Tests nicht als zusätzliche Arbeit, sondern als riesiges Einsparpotenzial für Zeit und Geld.

Wer schreibt die Akzeptanztests und wann

Idealerweise würden Stakeholder und Qualitätssicherung gemeinsam die Tests Schreiben, das sieht jedoch in der praktischen Umsetzung anders aus.

In der Praxis werden die Akzeptanztests von Business-Analysten (BA), Qualitätssicherung (QS) und Entwicklern geschrieben, dabei schreiben die BA meistens die „Standardfälle“ als Test wobei die QS meistens für „Sonderfälle“ die Tests schreibt.

Passive Aggression

Tja, das ist halt das Testergebnis, also mache ich das auch so.

Solche passiven Aggressionen sagt ein Profi einfach nicht, wie im obigen Zitat zu sehen ist.

Akzeptanz- und Unit-Tests

Unit-Tests werden von Programmierer für Programmierer geschrieben.

Unit-Tests sind die formalen Designdokumente auf niedrigster Ebene.

Akzeptanztests werden vom Business fürs Business geschrieben (auch wenn Sie als Entwickler möglicherweise daran hängenbleiben, sie zu schreiben).

Akzeptanztests sind formale Anforderungsdokumente die angaben wie sich das System aus Sicht des Business verhalten soll.

Units- und Akzeptanztests sind in erster Linie Dokumente und in zweiter Linie Tests.

GUIs und andere KOMPLIKATIONEN

GUIs sind laufend im wandel und veränder sich dadurch sehr schnell.

Der Trick besteht darin, das System so zu gestalten, dass man die GUIs wie APIs behandelt […]. Das hört sich vielleicht eigenartig an, aber es ist wirklich einfach nur gutes Design.

Hier wäre z. B. das „Single Responsibility Principle“ (SRP) eine gute Vorgehensweise für GUIs.

Diesem Prinzip zufolge sollte man jene Dinge separieren, die sich aus unterschiedlichen Gründen ändern können, und sie mit solchen Dingen gruppieren, die sich aus dem gleichen Gründen ändern.

Diese Tests sollten also z. B. den Button über eine eindeutige ID auswählen anstatt der Position des Buttons.

GUIs sollten immer von der Business-Regeln getrennt werden, somit reichtes theoretisch wenn man die darunter liegende API testet.

Andauernde Integration

Jedes Projekt sollte mehrmals täglich alle Tests ausführen und zusätzlich noch wenn jemand etwas neues Commitet, dass macht man am besten mit CI-Systemen (z. B. Jenkins).

So ballt ein CI Test fehlschlägt, dann hilft sofort das ganze Team diesen Fehlgeschlagenen Test wieder zu bestehen, das hat immer die höchste Priorität.

Schlussfolgerung

Kommunikation über Details ist schwierig. Das gilt vor allem für Programmierer und Stakeholder […].

Leider passiert es zu häufig, dass man davon ausgeht, man versteht sich gegenseitig und plötzlich haben beide Parteien eine andere Vorstellung voneinander.

Die einzige Möglichkeit diese Kommunikationsfehler zu vermeiden besteht darin automatische Akzeptanztests zu schreiben.

Teststrategien

Jedes Entwicklungsteam braucht eine Teststrategie.

Idealerweise wird ein mal im Monat eine „Bug-Jagt“ veranstaltet, dort gab es einen Ansporn, um das System zum Scheitern zu bringen, z. B. für die meisten Bugs ein Abendessen zu zweit oder für den Gravierendsten Bug eine sehr schöne Wochenendreise.

Für die QS sollte nichts übrig bleiben

Das Ziel des Entwicklungsteams ist es für die QS keine Fehler übrig zu lassen.

Wenn die QS dann aber wirklich mal ein Fehler findet, sollten Maßnahmen getroffen werden, das dieser Fehler Type zukünftig nicht mehr auftreten kann.

Die QS gehört zum team

Die QS und das Entwicklerteam sind keine Kontrahenten, sondern arbeiten gemeinsam an die Qualität des Systems.

Die QS schreibt zusammen mit dem Business die Spezifikationen des Systems und überprüft wie sich das System aktuell anhand von Explorativen Tests verhält.

Die Pyramide der Testautomatisierung

Profi Entwickler nutzen TDD, Profi Entwicklerteams nutzen Akzeptanztest, um das System zu spezifizieren und um Rückschritte zu vermeiden.

Units-Tests

Diese Tests werden von Programmierern für Programmierer in der Programmsprache des Systems geschrieben. Diese Tests sollen das System auf unterster Ebene spezifizieren.

Hierbei ist zu beachten das die Tests wirklich das Verhalten des Codes Testen und die Abdeckung sollte in jeden Fall immer über 90 % sein besser bei 100 %.

Komponententests

Testet eine Komponente z. B. ein teil der Businesslogik und überprüft, ob der Input zum Output passt. Dabei ist es wichtig das, dass Business diese Tests selbst liest und interpretieren kann.

Diese Tests decken eher die Standardfälle und sehr offensichtlichen Grentz- und Ausnahmefällen ab.

Integrationstests

Diese Test sind nur bei größeren Systemen sinnvoll, die aus vielen Komponenten bestehen.

Wie in der Abbildung unter zu sehen ist, wir eine Gruppe von Komponenten zusammen gestellt und dann getestet, wie gut gut diese miteinander kommunizieren.

Es handelt sich um „Verdrahtungstests“, die gewährleisten sollen, dass die Komponenten richtig miteinander verbunden sind und klar miteinander Kommunizieren können.

Systemtests

Die ganzen Automatisierten Teste werden gegen das gesamte System durchgeführt, es ist also ein ultimativer Integrationstest.

Diese Systemtests decken etwa 10% der Systeme ab, weil sie nur dafür sorgen müssen das die Systemkonstruktion noch korrekt ist.

Manuelle explorative Tests

Diese Tests, die nicht gescriptet und nicht Automatisiert werden, werden vom Programmierer selbst geschrieben um das System auf unerwartet verhalten zu untersuchen.

Wenn man für diese Art Test einen Testplan schriebt, untergräbt man seinen Zweck.

Das Ziel liegt nicht in der Abdeckung. […] Es geht vielmehr darum herauszufinden, ob sich das System bei der Bedienung durch Menschen gut verhält und wir wollen kreativ so viele Macken wie möglich finden.

Schlussfolgerung

TDD ist eine sehr leistungsfähige Disziplin und Akzeptanztests sind ein wertvoller Weg, um Anforderungen zu formulieren und durchzusetzen.

Die Entwickler setzten sich zusammen mit der QS zusammen um wirklich gute Tests zu schreiben, so dass die QS kein fehl verhalten mehr finden kann.

Die Automatisierten Test sollten so häufig wie möglich laufen, um sicherzustellen das dass System dauerhaft sauber bleibt.

Zeitmanagement

Meetings

Kosten ca. 150€ pro person jede Stunde, sie sind also sehr teuer.

Somit leisten sie aktiv Widerstand gegen Meetings, die keinen direkten oder wesentlichen Vorteil bringen.

Absagen

Es ist unprofessionell bei jede Einladung zu Meetings anzunehmen.

Ich sage sofort ab wenn meine Anwesenheit nicht erforderlich ist.

Sich ausklinken

Wenn das Meeting langweilig wird, verschwinde ich.

Noch einmal: Sie verantworten selbst, Ihre Zeit gut zu verwalten. Wenn Sie merken, dass Sie in einem Meeting Ihre Zeit verschwenden, müssen Sie einen Weg finden, dieses Meeting auf höfliche Weise zu verlassen.

Tagesordnung und Ziel

Jedes Meeting sollte eine Agenda mit Zeitrahmen für jedes Thema haben außerdem, ein festgelegtes Ziel.

Höflich nach diesen angaben Fragen, sofern ich keine klare Rückmeldung erhalte, sage ich das Meeting ab.

Stand-up-Meetings

Hier werden reihum drei Fragen beantwortet:

  1. Was habe ich gestern gemacht?
  2. Was werde ich heute machen?
  3. Was behinder mich bei meiner Arbeit?

Für jede Antwort stehen maximal 20 Sekunden bereit.

Planungstreffen zur Iteration

Diese Meetings sind sehr schwierig gut umzusetzen.

In diesem Meeting werden die Backlog-Items ausgewählt für die nächste Iteration, dabei ist für jedes Item der Business Wert bekannt und die dafür benötigte Zeit, in top Unternehmen sind sogar schon die Akzeptanz- und Komponententests geschrieben zumindest skizziert.

Jedes Item wird kurz, 5 bis 10 Minuten, diskutiert.

Meine Faustregel lautet, dass das Meeting nicht länger als 5% der Gesamtzeit der Iteration dauert.

Bei 40 Stunden Gesamtzeit darf die Planung also maximal nur 2 Stunden dauern.

Retrospektive und Demo der Iteration

Diese Meeting werden immer mit Stakeholder am Ende jeder Iteration gehalten, dabei wird diskutiert was gut läuft und was nächstes mal besser läuft.

Diese Meetings am besten 45 min vor Feierabend planen (damit sie nicht in die länge gezogen werden), die 45 min teilen sich auf in 25 min, für die Retrospective und 20 min für die Demo der neuen Features.

Auseinandersetzungen und Meinungsverschiedenheiten

Jede Debatte, die nicht in fünf Minuten beigelegt werden kann, kann nicht durch Debatten gelöst werden.

Kent Beck

Warum ist das so?

Weil hier keine klaren Argumente (Daten, Fakten, Beweise) gegenüber gestellt werden.

Wie gelange ich zu diesen Daten, Fakten, Beweise?

Ich führe Experimente durch oder Simuliere die Situation.

Es ist klug, sich über den Zeitrahmen und auch die Kriterien abzustimmen, um festlegen zu können, wann man den gewählten Pfad wieder verlässt.

Wenn ein Streit wirklich beigelegt werden muss, fordern Sie alle Argumentierenden auf, dem Team ihren Fall in fünf oder weniger Minuten zu präsentieren. Dann lassen Sie das Team abstimmen.

Fokus Manna

Da das Programmieren Intellektuelle Fähigkeiten beansprucht, verbrauchen wir im Gegenzug Fokus und Konzentration.

Fokus ist eine sehr seltene Ressource und wenn diese aufgebraucht ist sollten wir uns einer un fokussierte Arbeit annehmen so lange bis unser Fokus wieder „aufgeladen“ ist.

Meetings verbrauchen viel Fokus Manna, Sorgen auch.

Schlaf

Diesen Punkt kann ich gar nicht genug betonen.

Den Schlaf managen, um sicher zu stellen das ich genau so viel Schlaf bekomme wie ich es gerade brauche.

Koffein

Aber seien Sie vorsichtig: Koffein lässt den Fokus auch gewissermaßen „flattern“.

Zu viel Koffein schickt Ihren Fokus in sehr eigenartige Richtungen.

Dabei ist zu beachten das der Koffeinkonsum und dessen Toleranz sehr individuell sind.

Die Akkus aufladen

Aus eigener Erfahrung kann ich sagen, wenn das Manna erst einmal verschwunden ist, kann man den Fokus nicht mehr erzwingen.

Ist der Fokus erstmal weg, dann kann ich noch weiter Code Schreiben, jedoch muss dieser sehr wahrscheinlich noch mal überarbeite werden.

Es ist also viel besser sich 30 Minuten oder 1 Stunde zum „Ent-Fokusierung“ zu nehmen.

Ich kann den Fokus auch durch „Ent-Fokussierung“ wieder aufladen. (Meditieren, Power Nap, Podcast hören, Zeitung lesen, …)

Muskelfokus

Es scheint paradox, jedoch hilft es enorm Sport zu treiben, denn bei dieser Tätigkeit lädt der „mentale Fokus“ wieder auf.

Input vs Output

Software zu schreiben, ist eine kreative Übung. Ich habe festgestellt, dass ich am kreativsten bin, wenn ich mich mit der Kreativität anderer beschäftige. Also lese ich eine Menge Science Fiction.

Zeitfenster und Tomaten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.