arrow arrow--cut calendar callback check chevron chevron--large cross cross--large download filter kununu linkedin magnifier mail marker menu minus Flieger phone play plus quote share

The Zen of Programming

Javaland 2023

Ich habe drei Tage lang meine grauen Zellen auf der Javaland 2023 strapaziert und ich bin noch immer von den ganzen Eindrücken überwältigt. Wenn du auch auf der Konferenz warst, hast du bestimmt auch eine/n CI-ler*in gesehen, denn wir waren überall vertreten, sogar als Diamond Sponsor und mit unserem eigenen Stand.

"Java? Interessiert mich nicht." *Tab closed*
HALT STOP!

Cologne Intelligence Team am Stand bei der Javaland 2023

Wer denkt, die Javaland sei nur für Java-Nerds interessant, der täuscht sich gewaltig! Das Java-Ökosystem umfasst so viel mehr. Also BLEIB gefälligst hier und lies weiter! Denn die Konferenz bot nicht nur Technologie, Innovationen und Best Practices. Es ging auch um den Menschen - von Glück und Stressmanagement bis hin zu Mobbing. Viele inspirierende Talks rundeten das Programm ab. Aber genug der allgemeinen Eindrücke. Lass uns tiefer eintauchen! Für diesen Blogartikel habe ich einen Vortrag ausgewählt, den ich besonders empfehlenswert finde, und möchte diesen im Folgenden ausführlicher erläutern. Zudem werde ich alle weiteren interessanten Vorträge, die ich besucht habe, am Schluss kurz auflisten. Falls Bedarf besteht, können diese auf der Website von Javaland im Nachhinein angesehen werden, da sämtliche Vorträge aufgezeichnet wurden und somit jederzeit zugänglich sind (https://shop.doag.org/shop/prd.453.javaland-2023-on-demand/).

Gregor: "Danke ChatGPT für diese tolle Intro. Kannst du den Rest auch noch machen?"
ChatGPT: "Kein Ding, here we go."

The Zen of Programming

Speaker: Sander Hoogendoorn

In diesem Talk teilt Sander Weisheiten, die er in den letzten 40 Jahren gesammelt hat oder die sich für ihn als Muster herauskristallisiert haben. Im Leben eines Programmierers wird es wohl nie eine Zeit geben, in der er sagen würde, er könne mit dem Lernen aufhören. Dabei geht es nicht nur darum, neue Features zu lernen, sondern auch darum, in dem, was man bereits kann, besser zu werden. Das heißt, Dinge so oft zu tun, dass sie in das Muscle Memory kommen. Auf diese Art und Weise erlernte Fähigkeiten lassen sich sogar in anderen Tätigkeiten einsetzen oder übertragen. Dieses Prinzip, oftmals bekannt aus dem Kampfsport, lässt sich auch aufs Programmieren übertragen. Ziel ist es, einen Zustand zu erreichen, den Sanders als "The Zen of Programming" bezeichnet. Er definiert diesen folgendermaßen: 

A state of calm attentiveness in which one's actions are guided by intuition rather than by conscious effort - you become one with the code lost in the rhythm with the tasks at hand.

Sander Hoogendoorn, Javaland 2023

Falls du Programmierer*in bist, kennst du diesen Zustand vielleicht sogar schon? Hast du beim Programmieren schon einmal auf die Uhr geschaut und plötzlich war es zwei Uhr nachts?

How Does Learning Work? Abb. aus Sander Hoogendoorns Vortrag bei der Javaland 2023
Grafik 1 (Sander Hoogendoorn: "The Zen of Programming")

"How Does Learning Work?"

Lernen ist nichts Lineares. Oft ist es so, dass man schlagartig besser wird. Irgendwann hat man auch das Gefühl, dass man stagniert. Für das Besserwerden ist es extrem wichtig, Experimente zu wagen, neue Ideen auszuprobieren und kreativ zu sein. Im ersten Moment wird man vielleicht schlechter bzw. unproduktiver, aber oftmals erlangt man dadurch neue Erkenntnisse oder Wissen und macht somit einen Sprung nach vorne (siehe Grafik).

Grafik 2 zu Sander Hoogendoorns Vortrag auf der Javaland 2023
Grafik 2 (Sander Hoogendoorn: "The Zen of Programming")

"Learn to Unlearn"

Genauso wichtig wie zu lernen ist es, Dinge, die nicht funktionieren oder schlecht sind, zu identifizieren und im wahrsten Sinne des Wortes zu “verlernen”. Grafik 2 fasst diesen Prozess gut zusammen. Im Laufe eines Programmiererlebens lernt man viele Dinge und versucht sie alle irgendwie einzusetzen. Aber je mehr man lernt, desto mehr merkt man, wann man bestimmte Dinge verwenden sollte oder dass man bestimmte Dinge vielleicht gar nicht verwenden sollte und so landet man vermeintlich wieder beim Ausgangszustand mit "simple code", der aber viel besser ist als der einfache Code, den man am Anfang geschrieben hat. Ich würde mich nicht als super erfahrenen Programmierer beschreiben, ich programmiere vielleicht erst seit 13 Jahren aktiv. Aber ich kann dieses Phänomen bestätigen.

"You Are Never There"

Man sollte sich auch generell davon verabschieden, dass man irgendwann an einen Punkt kommt, an dem man alles weiß oder nichts mehr dazulernen kann, dieser wird nämlich niemals kommen, gerade in unserem Bereich.

There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns - the ones we don't know we don't know.

Sander Hoogendoorn, Javaland 2023

Mit dem Thema "Schätzen" hat sich vermutlich jede/r Programmierer*in schon beschäftigen müssen. Klassischerweise in Form von Zeit und heutzutage vielleicht in Form von Komplexität. Dass Software allerdings nicht am Ende eines Fließbandes herunterpurzelt wie beispielsweise in einer Autofabrik, wird oftmals vergessen. Denn in der Regel ist jedes Problem oder jede Herausforderung anders. Die "known knowns" kann man schätzen, die "known unknowns" auch, aber was ist mit den "unknown unknowns"? Und genau da liegt das Problem: Wie sollen wir als Programmierer*innen einen Aufwand schätzen, von dem wir nicht einmal wissen, dass er existiert? Manchmal wünsche ich mir, dass all der Aufwand, der in die Messung der Produktivität gesteckt wird, in andere Dinge investiert würde.

Grafik 3 Teilnehmerblitzlicht Javaland 2023
Grafik 3 (Sander Hoogendoorn: "The Zen of Programming")

"Programming Does Not Fit Well in Timeboxes"

Programmieren passt nicht gut in einen Acht-Stunden-Tag, der am Stück ausgeführt wird. Leider ist das jedoch die Realität der Arbeitsgesellschaft. Meetings, die über den Tag verteilt sind, sind hierbei der Haupt-Zeitkiller. Nach einem Meeting ist man nicht sofort wieder produktiv; es braucht Zeit, bis man sich in das Thema, an dem man dran war, gedanklich wieder eingearbeitet hat. Aus eigener Erfahrung würde ich sogar noch weiter gehen und sagen, dass die Produktivität sogar schon vor dem Meeting abnimmt.

Ich glaube, jede/r Programmierer*in kennt die Tage, an denen man kaum was geschafft hat. Dann schaut man am Ende des Tages in seinen Kalender, sieht fünf auf den Tag verteilte Meetings und wurde zwischendurch noch mehrmals per Teams angeschrieben. Da ist es kein Wunder, dass man fast nicht zum eigentlichen Arbeiten kommt. 

Hinzu kommt noch, dass Code manchmal Zeit braucht. Sander beschreibt damit ein Phänomen, das mir auch schon häufig aufgefallen ist: Manchmal muss man Code einfach mal liegen lassen und später nochmal wiederkommen, um einen frischen Blick darauf zu werfen. Wie oft ist dir schon eine gute Idee zu einem Problem gekommen, während du in der Bahn gesessen hast, gekocht hast oder spazieren warst? Oftmals sieht man die Dinge dann aus einer ganz anderen Perspektive und hat vielleicht direkt eine gute Lösung parat. 

Viele Unterbrechungen zum Beispiel in Form von Meetings, Zeitdruck und mehrere Themen auf einmal sind oftmals also ein Problem. Sander gibt hier allerdings keine konkrete Lösung vor.

Meine Lösung wäre:

  • Für Meetings feste Zeitblöcke definieren
  • Entwickler*innen nicht mit vielen Themen auf einmal überladen
  • Zeitdruck herausnehmen (nicht mehr schätzen und wenn, dann deutliche Puffer einbauen wegen der "unknown unknowns")

"Always Travel Light"

Beschränke den Arbeitsaufwand auf ein Minimum. Denn der sicherste und leicht verständlichste Code ist der, den man gar nicht erst schreibt.

Developers are drawn to complexity like moths are to a flame, often with the same result.

Sander Hoogendoorn, Javaland 2023

Dieses Zitat bringt es auf den Punkt, und hier habe ich mich schon oft selbst erwischt. Oft versucht man, viele Eventualitäten direkt innerhalb des Codes mitzudenken. Die Ursache dieses Phänomens liegt hier nicht nur beim Programmierer, sondern auch an der Tatsache, dass Anforderungen oft relativ offen definiert sind und sich Leute ungern festlegen wollen oder können. Folgende Gedanken sollten Warnsignale für uns sein:

  • "Das könnten wir in Zukunft brauchen."
  • "Letztendlich werden wir das brauchen."
  • "Wenn ich meinen Code jetzt generischer schreibe, werden wir später davon profitieren."
  • "Was ist, wenn wir diese Datenbank zu einem bestimmten Zeitpunkt durch eine andere ersetzen wollen?"

Den letzten Punkt kennt wahrscheinlich jede/r Programmierer*in. Wir alle haben bestimmt schon mal ein ORM genutzt und uns auch mit Tücken und Problemen herumgeschlagen, die man auch mit einem kurzen SQL-Statement hätte abfrühstücken können. Aber wie oft hat jemand von uns schon mal die zugrunde liegende Datenbank-Engine gewechselt? Wenn du also das nächste Mal ChatGPT fragst, wie man XYZ mit Hibernate löst, denk einmal drüber nach, ob es den Aufwand wirklich wert ist.

"Solve the right Challenges"

Sander formuliert es in seinem Vortrag so:

Scalability. The #1 problem people don't actually have but still solve.

Sander Hoogendoorn, Javaland 2023

Ich gebe mal ein Beispiel: Heutzutage setzt fast jedes Unternehmen auf eine Microservice-Architektur. Doch welche Probleme löst solch eine Architektur denn eigentlich?

  • Skalierbarkeit
  • Flexibilität
  • Widerstandsfähigkeit
  • Agilität
  • Heterogenität der Technologie (das muss nicht unbedingt etwas Gutes sein, denn wenn man viele unterschiedliche Technologien verwendet, dann braucht man auch Entwickler*innen, die diese beherrschen)

Vergleichen wir diese Liste mal mit einem modularisierten Monolithen:

  • Flexibilität
  • Widerstandsfähigkeit
  • Agilität

Wenn man den Punkt Heterogenität der Technologie mal außen vor lässt, verliert man lediglich die Skalierbarkeit, wobei man einen Monolithen auch skalieren kann, nur eben halt als Ganzes. Und bei einem gut modularisierten Monolithen kann man bei Bedarf auch einzelne Module relativ leicht raustrennen und in Microservices umwandeln. Denn welche zusätzlichen Probleme führt eine Microservice-Architektur ein?

  • Komplexität verteilter Systeme (Service-Erkennung, Netzwerklatenz und Fehlertoleranz)
  • Erhöhte betriebliche Komplexität
  • Erhöhte Fehleranfälligkeit bei der Datenverwaltung (Konsistenz)
  • Erhöhte Komplexität der Tests (End-to-End)
  • Mögliche erhöhte Kosten (z.B.: eine JVM pro Microservice)

"Never Be Afraid to Ask the "Newcomer Questions"

Viele Leute haben Angst diese Fragen zu stellen:

  • "Warum schreiben wir den Code so, wie wir ihn schreiben?"
  • "Wieso nutzen wir Technologie XYZ, um Problem XYZ zu lösen?"

Erlaubt euch stets, solche Fragen zu stellen und dadurch über Dinge zu reflektieren. Auf diese Weise erhalten alle ein besseres Verständnis für den Code und die Lösungen, und es werden frühzeitig Probleme aufgedeckt, die man sonst ewig mit sich herumschleppt und die nur noch größer werden.

Das war gerade einmal die Hälfte des Talks von Sanders. Er zeigt auch einige Best Practices mit Codebeispielen und geht ins Detail. Das würde jedoch den Rahmen dieses Artikels sprengen. Schaut euch gerne seinen Talk an, es lohnt sich. Ich hoffe, ich konnte euch zum Nachdenken anregen und ihr konntet das eine oder andere Thema für euch mitnehmen. Vielleicht sieht man sich ja das nächste Mal auf der Javaland 2024.

Zum Schluss noch eine Liste von Talks, die ich empfehlen kann:

From k9s to OpenTelemetry: A guide to observability for your (Java) apps in K8s
Speaker: Matthias Haeussler

To InstantOn and Beyond: Java at Lightspeed!
Speaker: Grace Jansen

Alles Wichtige über Softwarearchitektur in 40 Minuten
Speaker: Stefan Zörner

Develper Journey oder wie man Platform Engineering besser beschreiben könnte
Speaker: Daniel Kocot

Als Entwickler glücklich(er) sein: Was können wir selbst dafür tun?
Speaker: Christian Seifert

Project Loom - Einfachere Nebenläufigkeit in Java
Speaker: Michael Hunger

Introduction and pitfalls of Java's new concurrency model
Speaker: David Vlijmincx

Löscht Eure Unit-Tests
Speaker: Arne Limburg

Managing Testing Data
Speaker: Elias Nogueira