Verzweifelt saß er vor dem Kotlin Code und versuchte mir das Konzept von Coroutines zu erklären, das er selber noch nicht richtig verstanden hatte.
“Ich weiß nicht, wo diese ganzen Threads entstehen. Das sollte eigentlich nicht passieren. Genau dafür sind Coroutines ja schließlich da …“
„Kennt sich denn niemand bei euch damit aus?”
“Der Autor von dieser Software ist mittlerweile gegangen. Ich werde auf die zwei Java-Experten verwiesen. Aber das sind Java-Experten, keine Kotlin-Experten.”
Ich grübelte an diesem Problem herum. Ein typischer Fall. Man hat wichtige Konzepte – in diesem Fall die einer Programmiersprache – nicht verstanden, um die wirkliche Ursache für die Probleme im System zu verstehen. Geschweige denn lösen zu können. Und der Autor des Systems hatte sie wohl auch nicht verstanden. Wenn man doch jemanden kennen würde, der einem diese Konzepte erklären könnte.
Manchmal hat man so jemanden in seinem Netzwerk, aber den bezahlt die Firma nicht. Dass heißt, Hilfe aus dieser Richtung kann höchstens Impulse setzen. Ich fragte den frustrierten Programmierer: „Such doch mal nach Namen von Leuten, die sich wirklich mit dem Thema auskennen.“
Es war ein kurzer Weg. Auf der Seite des Herstellers von Kotlin wurde der Teamleiter Roman Elizarov erwähnt. Ein Blick in Youtube brachte eine Reihe seiner Vorträge zum Vorschein, die die Konzepte, Goes und No-Goes erklärten. Und drei Stunden später wussten wir, wo in der Architektur der Software grundlegende Fehler waren.
Was habe ich daraus gelernt?
- Es ist wichtig, die Grundkonzepte der Tools zu verstehen, die wir benutzen.
- Es lohnt sich, nach Blogs, Artikeln und Videos von den Leuten zu suchen, die die Tool durchdrungen haben, vielleicht sogar entwickelt haben.
- Und man kann, wenn man dann immer noch nicht weiter kommt, direkten Kontakt aufnehmen.
- Für eine Firma würde es sich unter Umständen sogar lohnen, ein paar Beratungsstunden zu kaufen, wenn das schnell und unkompliziert möglich ist.