7 Wege zum Top-Entwickler

Was hat Life of Pi mit gutem Programmieren zu tun? Der klassiche Weg zum guten Programmieren mit etwas Mathematik und viel Informatik führt nicht unbedingt zu tollen Entwicklern - denn die Interaktion mit Menschen und deren Werken bleibt dabei auf der Strecke. Folge mir also auf eine Tour über 7 Wege, die dich zum guten Entwickler machen. Ein Weg führt dich vielleicht in die Badi, ein anderer auf ein Rettungsboot im Ozean. Aber einige Wege sind schon ziemlich anstrengend, denn wir bleiben nicht auf den gewohnten Bahnen des Entwicklers.

Die Grundlage der IT Entwicklung ist die Umsetzung von Ideen in eine Struktur, die von einer Maschine verstanden wird. Und von anderen Menschen, denn man arbeitet selten alleine! Die Struktur kann in einer Programmiersprache ausgedrückt sein, aber auch als Ablauf in einem Tool, als Konfiguration, etc.

Zwischen den besten und schlechtesten Entwicklern gibt es immense Unterschiede  – der Faktor 10 wird viel genannt, u.a. auch bei Brooks (siehe unten). Falls du deine Performance verbessern willst, gibt es viele Wege (grundsätzlich macht Übung den Meister). Ich stelle 7 dieser Wege vor, die sich für mich bewährt haben. Man kann sie in beliebiger Reihenfolge beschreiten und immer wieder neu kombinieren.

Wege verlaufen im Sand

1. Schreiben

Nach vielen Jahren Schule ist mancher froh, keine Aufsätze mehr schreiben zu müssen, sondern Codes.

Trotzdem: Schreiben ist strukturiertes Denken. Wer nicht schreiben kann, kann nicht vernünftig programmieren.  Schreibe also zuerst die Dokumentation (dann hast du’s hinter dir), dann die Tests,  dann die Kommentare, dann den Code. Und lass jemanden deine Texte lesen.

Übrigens: Bevor ich jemanden anstelle, lass ich die Person fast immer einen Text schreiben.  Das ergänzt das mündliche Interview sehr effektiv.

2. Lesen

Gut schreiben lernt man durch lesen. Lies guten Code in deiner bevorzugten Sprache.  Was gelingt dem Autor gut, was könntest du besser machen?

Lies aber auch Bücher. Gute Manuals sind rar – aber es gibt einige ICT Klassiker, von denen man heute noch viel lernen kann. Es muss ja nicht gleich Knuth‘s The Art of Computer Programming sein:

  • W. Richard Stevens: TCP/IP Illustrated – du lernst die Grundlagen der wichtigsten Protokolle überhaupt, und auch die geniale Darstellung mit Messungen.
  • Andrew S. Tanenbaum: Operating Systems: Design and Implementation – Du lernst, was ein Betriebssystem tun muss und wie es funktioniert, sowie Abstraktion von Grund auf!
  • Fred Brooks: The Mythical Man-Month: Essays on Software Engineering. Vieles hat sich seit 1975 verändert – aber erschreckend vieles gilt heute noch genau so! Dieses dünne Buch gibt allen heutigen Prozess-Gurus und Projektleitern Respekt vor den Leistungen in der Vorzeit der ICT und zeigt, dass der Mensch der bestimmende Faktor bleibt.
  • Beautiful Code: 33 konkrete Beispiele von Code und Systemen, von deren Autoren erklärt.

Wenn du genug von ICT hast, lässt sich Schreiben auch durch Lesen von Literatur verbessern: Mein Vorschlag, statt als Film: Life of Pi / Schiffbruch mit Tiger, von Yann Martel, ein Meisterwerk der Erzählkunst und Struktur.

3. Kenne deine Umgebung

Architekturen mit mehreren Schichten können zur Horror-Story werden, wenn die Entwickler die Aufgaben, Stärken, Schwächen, Performance-Charakteristiken der Schichten nicht kennen. Die Schichten bekommen Aufgaben, die in andere Schichten gehören; das Rad wird neu erfunden, die wundervollen Abstraktionen der Architektur zerfallen und bald herrscht Kleinkrieg zwischen den Schichten.

Daraus gibt’s eine Lehre für den Architekten und eine für den Entwickler:

  • Passe die Architektur dem Entwicklungs- und dem zukünftigen Unterhalts-Team an. Wenn’s du für dein Team nicht einfach genug hinkriegst, brauchst du einen anderes Team oder das Team einen anderen Architekten.
  • Lerne deine Umgebung kennen: Benimm dich nicht wie eine Tourist, sondern wie ein guter Taxifahrer, der die wichtigen Strassen auswendig kennt und weiss, wie man die kleinsten Gässchen findet. Und sei dir immer bewusst, wo du bist und warum du gerade dort bist.

4. Lebe deinen Code

Egal, in welcher Sprache – es gibt Daten und Aktionen auf den Daten. In modernen objekt-basierten Sprachen ist dies schön mit Objekten und Methoden dargestellt. Fühle dich in diese ein – versuche, ein Programm nicht als Zeilen von Codes, sondern als Objekte und deren Interaktionen zu sehen.  Hilfreich sind auch Zeichnungen von Objekten, Strukturen, Interaktionen.

Bei dynamischen Sprachen (wie Python, Ruby) ist dies leichter, aber das ist grossteils auch Geschmack, Gewohnheit und Übung.

Du kennst die Resultate deines Codes – es wird dir leicht fallen, Tests dafür  zu schreiben. Aber vielleicht kennst du den Code zu gut – und passt (unbewusst) deine Tests dem Code an. Versuche deshalb, die Tests zuerst zu schreiben und den Code nach und nach „einzufüllen“ (Test-Driven Development) .

5. Einen Schritt zurück

This is a small but “complete” desert

Wenn dein Code einigermassen funktioniert, druck ihn aus, setz dich in eine ruhige Ecke ohne Computer (z.B. in eine Badi) und lies deinen Code aufmerksam und kritisch.  Warum ausdrucken: Es lassen sich schneller grosse Code-Stücke überblicken. Und du kannst Änderungen nicht grad eintippen und testen – sondern musst sie zuerst mal im Kopf durchgehen.

Das schnelle Eintippen lässt dein Langzeit-Gedächtnis nicht richtig arbeiten – du wirst dich nicht erinnern, wo du ein ähnliches Problem vielleicht schon mal gelöst hast oder eine Lösung finden könntest. Versuche immer, auf das  ganze System und die ganze Umgebung zu achten.

Wie ein geschriebener Text gelingt ein Programm selten auf Anhieb optimal – es nach einigen Tagen nochmals zu lesen hilft, die Struktur zu verbessern und die Abläufe zu verinnerlichen – denn du wirst ja vermutlich lange Zeit für deinen Code verantwortlich sein.

6. Zeige deinen Code

Als ich vor langer Zeit 30 Zeilen Code meinem ersten Chef zeigte, hatte ich schwere 15 Minuten. Ich kannte meinen Code danach nicht mehr. Die Hälfte war ganz verschwunden (kein Code – kein Bug!) und der Rest viel abstrakter formuliert. Heute erkenne ich zumindest, wenn meine Lösung gut ist, oder wenn sie noch stark verbessert werden kann.

Zeige auch deine Tests – falsche Annahmen lassen sich so schnell entdecken.

7. Kenne das Problem

Das Wichtigste zuletzt: Welches Problem löst du? Welche Lösung erwartest du? Wenn du dein Projekt als erstes dokumentiert hast, und Tests bereits geschrieben und diese rumgezeigt hast, kennst du hoffentlich das Anwendungsgebiet. Je mehr du darüber weisst, desto besser.

Programmierer, die Unsinn programmieren, nur weil es in einer Spezifikation steht (die ja auch von Menschen geschrieben wurde), sind nicht effektiv einsetzbar. Also, wenn im Pastarezept (Spezifikation) etwas von einem Esslöffel Salz pro Deziliter Wasser steht – abklären, ob das nicht falsch ist. Und wenn mit einem Finanzinstrument ein Verlust von 10 Milliarden Franken droht, bitte abklären!

Sieben Wege

Die sieben Wege  sind nicht leicht und brauchen Zeit – einen Teil der 10‘000 Stunden, die dich zum Experten machen (aus meinem Beitrag Zahlen schätzen).

Viele dieser Wege verbessern die Struktur deines Codes und schaffen eine gewisse Abstraktion. Wie man am besten abstraktes Denken lernt, ist mir jedoch nicht klar. Ich habe den Eindruck, dass die Tiefe des Abstraktionsvermögens einer der wesentlichen Unterschiede zwischen Absolventen von Universitäten einerseits und von Berufsausbildungen, Weiterbildungen und Fachhochschulen anderseits ist (immer mit individuellen Ausnahmen). Kann dies daran liegen, dass die an der Uni forschenden Professoren die Studenten mit unklaren Fragestellungen und Aufgaben manchmal ganz schön alleine lassen und die Studenten dabei viel mehr lernen als bei didaktisch gut aufbereitetem Stoff?

Wer widerspricht und hat andere Erklärungen?