Was der Dunning Kruger Effekt mit Freelancer Profilen im Allgemeinen und einer Projektabsage im Besonderen zu tun hat

Beim Lesen des – sehr unterhaltsamen und inspirierenden – Buches Fokus! von Hermann Scherer wurde ich einmal mehr an den Dunning Kruger Effekt und die Implikationen die sich daraus ergeben erinnert. Zusammen mit einer unglücklichen Absage bei der Projektaquise ergab sich dieser kleine Artikel.

Als Dunning Kruger Effekt bezeichnet man umgangssprachlich die Tatsache, dass Inkompetenz häufig zu größerer Selbstsicherheit führt als Kompetenz. Ist eine Person besonders kompetent erkennt sie in dem entsprechenden Fachgebiet sowohl Chancen als auch potenielle Probleme.

„Wenn jemand inkompetent ist, dann kann er nicht wissen, dass er inkompetent ist. […] Die Fähigkeiten, die man braucht, um eine richtige Lösung zu finden, [sind] genau jene Fähigkeiten, die man braucht, um eine Lösung als richtig zu erkennen.“

– David Dunning

Aus meiner Sicht ist das ein Grund warum sich Freelancer v.a. die kompetenten oft unter Wert verkaufen. Wenn ich mein eigenes Profil anschaue, habe ich im Lauf der Zeit viele Tools und Skills aufgenommen, die ich anfangs nicht erwähnenswert fand. Als „Techie“ neigt man dazu, nur die Fähigkeiten aufzuzählen die man selbst als „Besonders“ oder „Schwierig“ ansieht. Am besten sollte man über 5 Jahre ausschließlich in einem bestimmten Gebiet gearbeitet haben um sie im Profil hervorzuheben  – so habe ich zumindest zu Beginn meiner Freelancer Laufbahn mein Profil aufgebaut. Das ist natürlich Quatsch – oft ist sogar die Fähigkeit sich schnell in neue Technologien einzuarbeiten wichtiger als welche man gerade beherrscht oder zu beherrschen glaubt 😊

Vor kurzem hatte ich einen ähnlichen Effekt bei einer Projektbewerbung, bei der ich leider bereits vor dem Telefoninterview aussortiert wurde. In meinem Profil habe ich bei einem Projekt wieder einmal einen Skill (JSF) nur unzureichend „angeteasert“. Er stand einfach nur in der Spalte mit den entsprechenden Skills für ein Projekt das mit Unterbrechungen mehrere Jahre lief. Irgendwie vergas ich zu erwähnen, dass ich das entsprechende Projekt ohne Übergabe durch den/die ursprünglichen Programmierer übernehmen musste und den Quellcode komplett selbst analysieren „durfte“. Netterweise war die Systemumgebung nur in einer Variante (Produktivsystem) undokumentiert vorhanden – d.h. der erste Schritt war diese „nachzubauen“ und einen vernünftigen, automatisierten Deployment-Vorgang (SVN / Git, maven usw) zu erstellen. Ganz klein war die Software ebenfalls nicht, sie umfasste zum damaligen Zeitpunkt > 50.000 Zeilen selbst vom Kunden geschriebenen Code.

Das dabei etwas mehr als das durchschnittliche Know-How hängen bleibt ist eigentlich klar – das Feedback war aber nur „JSF in zu wenigen Projekten, wir haben keine Zeit mit dem Kandidaten zu reden“. Schade für mich, und evtl. auch schade für den Kunden, wer weiß.

Ich nehme daraus wieder einmal mit, im Zweifelsfall etwas mehr zu trommeln. Dass ich mich überschätzt hatte ist mir bisher bei keiner Projektaquise passiert. Ich denke mal, da bin ich nicht der einzige Freelancer dem es so geht. Und vielleicht gibt der Artikel dem einen oder anderen Newcomer den Anstoß genau zu kommunizieren, welche Skills man besitzt und geg. auch wie intensiv diese im Projekt eingesetzt wurden. Ich hätte mir ein entsprechendes Feedback v.a. zu Beginn meiner Freiberuflerlaufbahn gewünscht. Es wäre schade, wenn sich gerade die fähigen Freiberufler nicht durchsetzen würden.

Ist staging unverzichtbar?

Vor allem wenn ich mit Abteilungen/Firmen arbeite, die aus der Subversion Welt kommen, höre ich oft die Frage, warum brauchen wir denn staging? Develop und Master ist ja prinzipiell klar, aber staging? Können wir uns das nicht sparen, dann müssen wir ja noch häufiger mergen.

Meistens hole ich dann kurz aus und lege nochmal dar wie typischerweise die Branches mit den Systemen korrelieren:

Releasezyklus über die Systeme (Entwickler/Local, QA / Testserver und Produktivsystem)

Da sich in develop die aktuelle Entwicklungsversion befindet, ist dieser die Basis für die Standard-Entwicklungen – üblicherweise werden von develop Feature Branches erzeugt. Nach Implementierung des Features wird zurückgemerged.

Sind alle Features eines Releases implementiert, bzw. zum festgelegten Termin, wird develop nach staging gemerged. Jetzt liegt das aktuell zu testende Release auf dem Staging Server. Wärenddessen wird in develop natürlich bereits an den nächsten Tickets für ein zukünftiges Release gearbeitet.

Wird jetzt beim Test auf dem Staging Server ein Fehler gefunden, muss dieser korrigiert werden, ohne dass Änderungen aus dem develop Branch auf den Testserver kommen. Also muss ausgehend von staging gearbeitet werden. Diese Änderungen müssen natürlich zurück in develop gemerged werden.

Theoretisch kann zum selben Zeitpunkt ein schwerwiegender Fehler auf dem Produktivsystem auftreten. Dieser soll sofort korrigiert werden – es steht ein sogenannter Hotfix an. Dafür wird vom Master Branch ausgehend entwickelt.

Zu diesem Zeitpunkt haben wir in allen 3 Hauptbranches unterschiedliche Stände, die sauber getrennt sind. Durch zurückmergen bzw. cherrypicken nach Fertigstellung wird sichergestellt, dass zukünftig keine der Neuentwicklungen / Bugfixes verloren geht.

Entwicklungsmodell für Features und Hotfixes, sowie den korrespondierenden Cherrypicks (unterbrochene Linie)

Hat man bisher nur Erfahrung mit Subversion o.ä. dann wird man begeistert sein, wie einfach das Handling von Merges und Cherrypicks in git von der Hand geht.

Oft sehe ich im Projektalltag auch, dass die Verwendung eines staging Branches durch eine entsprechende Vorgehensweise vermieden wird. Das geht häufig gut, solange nur 1 Person für ein Projekt verantwortlich ist – wird diese aber mal zum falschen Zeitpunkt krank, wird das „System“ für die Vertretung leicht zum Albtraum. Nämlich dann, wenn nicht klar ist, welcher Stand in welchem Branch gehalten wird und evtl. ein Fall wie oben geschildert eintritt. Im Idealfall ist das Vorgehen standardisiert, dann ist der Zustand in den Haupt-Branches immer eindeutig definiert und von jedem Team-Mitglied leicht nachvollziehbar.

Aus meiner Sicht ist die Nutzung von develop, master UND staging heutzutage Pflicht, damit vernünftige Tests der Releases möglich sind.

Codereview oder nicht? Wie Unternehmen von Freiberuflern profitieren können

Als Freiberufler in Kundenprojekten befindet man sich ja in den unterschiedlichsten Unternehmen. Von Leading Edge Technologie und den (gerade) angesagtesten Vorgehensweisen bis hin zu Software und Abteilungen die über viele Jahre „gewachsen“ sind. Letzteren fehlen dann häufig auch Impulse von Außen. Gepaart mit hohem Arbeitsdruck sinkt oft die Qualität bzw. man hastet von Release zu Release und von Bugfix zu Bugfix ohne die eigene Vorgehensweise von Zeit zu Zeit zu analysieren.

Für diese Unternehmen sind dann „eigentlich“ Freiberufler eine Riesenchance. Sie bringen Impulse von Außen, kennen meist aktuelle Technologien und haben diese auch schon im Einsatz gehabt. So ähnlich ging es mir in einem meiner letzten Projekte, schon nach kurzer Zeit war klar, dass die Codequalität vorsichtig ausgedrückt stark zu wünschen übrig lässt. An diesem Punkt werden dann Kommunikationsskills wichtig 🙂 Mit wem rede ich wann am besten darüber? Ansprechen sollte ich es, denn sonst ist ja auch meine Expertise in Frage gestellt bzw. man könnte davon ausgehen, dass ich mit dem Vorgehen und dem Ergebnis einverstanden bin.

Da ich sehr pragmatisch und überhaupt nicht dogmatisch bin, konnte ich in den folgenden Wochen das Thema Codequalität und Möglichkeiten zur Verbesserung sowohl mit Mitarbeitern als auch Abteilungsleitern besprechen. Prinzipiell war man auch sehr aufgeschlossen, und hat sich alle Vorschläge angehört und diskutiert.

Ein Quickwin wäre aus meiner Sicht gewesen, im bereits vorhandenen Gitlab die Merge Requests zu verwenden und ein Codereview durch die Key Developer zu verlangen. Erstmal „nur“ mit der Anweisung, dass es ein Codereview für alle Änderungen, die mehr als 1-2 Zeilen umfassen, geben soll. Der Zeitaufwand wäre minimal, aber der Nutzen sehr groß, da damit zumindest die ganz schlimmen Katastrophen (cut&paste Programmierung, Module die mehrfach in nur geringer aber nicht unwichtiger Abwandlung existieren,…) einfach eliminiert werden könnten.

Da kommt dann natürlich sofort das Argument auf: Dafür haben wir keine Zeit, wir sind jetzt schon mehr als ausgelastet. Deshalb haben wir ja auch dich engagiert.

Leider half dann auch meine Erläuterung, dass es schon kurzfristig Zeit sparen wird, wenn nur noch sinnvoller Code committed wird,… nichts.

Interessant war dann, dass nachdem ich ein 2. Mal vom gleichen Kunden engagiert wurde, auf einmal ein sehr restriktives Regelwerk für Merge Requests und Codereviews im Einsatz war. Inkl. zus. Tools wie crucible usw. Manche Dinge lernt man nur durch den eigenen Schmerz 🙂

Machen das nicht alle so? Shortcuts für die wichtigsten git Befehle erstellen

Wieder einmal ist mir aufgefallen, dass es wohl je nach Mensch einen unterschiedlichen Grad an persönlicher Faulheit gibt 🙂 Ich selbst bin zugegebenermaßen dann sehr faul, wenn es um stupide und sich wiederholende Tätigkeiten geht. Da schwindet meine Motivation dermaßen, dass ich meist sehr schnell eine Möglichkeit finde, diese Aufgaben so weit wie möglich zu automatisieren oder zu vereinfachen.

Eine solche Tätigkeit ist der Umgang mit dem Sourcecode Verwaltungsoftware – bei mir meist git. V.a. in einem agilen Umfeld (heute wird ja meist mit Scrum o.ä.) gearbeitet, wird häufig committed, gepushed oder mal die History angesehen. Da ich gerne an der Shell arbeite, gibt es in meiner .bashrc neben diversen anderen Shortcuts eine ganze Reihe an Git Befehlen die ich häufig verwende:

  • alias gs=’git status‘
  • alias gc=’git checkout‘
  • alias gl=’git log –stat‘
  • alias gd=’git diff‘
  • ….

Auch in meiner Tätigkeit als Git Trainer zeige ich in meinen Git Schulungen immer gerne solche kleinen Tipps, die dann in Summe den Arbeitsalltag deutlich beschleunigen. Das kann ich jedem nur empfehlen, zumindest, wenn nicht mit einem graphischen Tool gearbeitet wird. Wobei aus meiner Sicht, für viele Aufgaben die gitbash o.ä. sogar schneller zu bedienen ist und einen höheren Grad an Kontrolle als die meisten Tools bietet. V.a. dann wenn man sie auf die oben beschriebene Art an die persönlichen Vorlieben anpasst.

 

Debugging – machen das nicht alle so?

Als ich in meinem aktuellen Projekt einen Fehler nicht beheben konnte und mir leider auch die Rechte fehlten um auf das entsprechende Apache Logfile zuzugreifen war ich nach einer kurzen Diskussion, wie man das Problem angeht, verwundert. Ich dachte ja, das alle Entwickler so etwas ähnlich angehen:

  1. Versuchen Zugriff auf alle Logfiles zu bekommen und sinnvolle Logmeldungen einbauen bzw. einen Debugger zu nutzen –
    Das hat in diesem Fall ja leider nicht geklappt 🙁
  2. Dann eben „Old-School“ Debugging:
    1. Ich suche mir eine Stelle vermutlich nahe genug am Fehler liegt, aber noch erreicht wird sollte das Programm sich , wie in diesem Fall, mit einem HTTP 500 Fehler verabschieden
    2. Je nach Programmiersprache ein exit, throw Exception, die um einen 500er Fehler auszulösen. Und eine irgendwie hilfreiche Ausgabe zu erzeugen
    3. Je nachdem ob die Stelle erreicht wird die meine Debugzeile sinnvoll vor oder zurückschieben
    4. Als ich dann die Stelle eingegrenzt hatte, konnte ich die Ursache recht schnell mit der Ausgabe einiger Variablen feststellen und beheben.
  3. Eine weitere Methode die ich gerne anwende, wenn kein vernünftiges Debugging Tool verfügbar ist bzw. um die Fehlerstelle schnell und einfach einzugrenzen:
    1. Großzügig Sourcecode (ca. die Hälfte, wie bei einer Binärsuche 🙂 ) entfernen und testen, ob der Fehler noch auftritt.
    2. Falls ja, mehr Sourcecode entfernen
    3. Falls nein, etwas weniger bzw einen Teil des entfernten Codes wiederherstellen

Mit den beiden Methoden komme ich meist recht schnell zum Ziel, wenn es keine „normale“ Debugging Möglichkeit gibt.

git log im svn style

Nachdem in einer Schulung die Frage gestellt wurde und ich die git History selbst gerne so anzeigen lassen:

Für alle die gerne die git log ähnlich wie svn log -v inkl. der geänderten Dateien ansehen möchten, ist das der richtige Befehl

  • git log –stat