Consultant Tagebuch 2: Selbstbeschäftigung

Wer wissen will, wie das Leben eines Informatik-Consultants, also eines „Beraters“, aussieht, ist hier richtig.

Hier gehts zum Consultant Tagebuch 1: das verpatzte Interview

Seit dem verpatzten Java Interview hat sich einiges getan. Ich habe das gesamte Wochenende Java Basics gebüffelt – Quasi back to the roots.

Also nein wirklich, das kann mein Stolz nicht auf sich beruhen lassen, dass ich mich als Java Entwickler betitle, aber nicht weiss, wieviele Collections intern erstellt bei einem Stream erstellt werden, wenn man 5 Verarbeitungsschritte macht (Antwort: Pro Schritt wird eine neue Collection erstellt). Oder warum HashSet’s so enorm viel schneller sind als ArrayLists (Antwort: Weil man bei HashSet zuerst das Objekt mittels Methode hashCode() aus Object hasht und erst dann quasi in er richtigen von unzähligen Schubladen mittels equals() nachschaut, welches Objekt man sucht. Das ist auch der Grund, warum hashCode() und equals() so eng verknüpft sind… Puh!).

Was ich mich aber auch gefragt habe ist folgendes: Was wäre, wenn diese eine Person, der Java Enthusiast, der einige Mensch auf Erden ist, der mir jemals in meinem ganzen Leben diese Java fragen stellen wird? Müsste ich dann jetzt die Antworten auf diese Fragen tatsächlich lernen?

Wie auch immer, jetzt habe ich diese Themen in meinem Gehirn wieder aufgefrischt, fühle mich besser, und könnte im Notfall immer noch ein Selbstversuch starten, ob Frauen im Ausgang heiss werden, wenn man ihnen in langen Erläuterungen den Unterschied zwischen ArrayList und LinkedList erklärt (Spoiler: Ja, sie werden heiss!!!).

Rein ins kalte Nass!

Das alles ist jetzt schon gar nicht mehr wichtig. (Sehr ihr? So schnell wechseln in meinem Leben die Themen, und da soll ich mir all die Dinge noch merken können…)

Momentan helfe ich meinem neu gefundenen Arbeitskollegen an einer Offerte – Nennen wir ihn König Arthur. Dabei geht es um ein ziemlich grosses Projekt, nennen wir es Projekt Hasenstall. Ja, ich weiss, in meinem letzten Tagebucheintrag habe ich geschrieben, dass ich ein Projekt suche. Dabei hatte ich aber immer Projekt Hasenstall als „Backup Projekt„.

Aber vielleicht beginne ich von Anfang an. Als ich bei meiner neuen Firma angefangen habe, war ich zuerst einmal zwei Wochen auf der Ersatzbank, da Projekt Hasenstall noch nicht bereit war für meine unerschöpfliche Weisheit. Dann endlich habe ich von König Arthur die Nachricht erhalten, dass ich ins Büro kommen kann, um am Projekt mitzuhelfen.

Und schon wurde ich mitten ins kalte Wasser geschmissen!

Auf der Ersatzbank hatte ich es gemütlich – Ich war zuhause und habe mir Tutorials über Blockchain reingezogen. Und plötzlich sass ich in einem Meeting nach dem anderen mit unglaublich vielen Leuten die mit sehr vielen Fachausdrücken um sich warfen!

Und dabei hat meine neue Firma eine ganz eigene Meeting-Kultur (dazu mal in einem späteren Tagebucheintrag mehr). Immerhin habe ich gut ausgeschaut in meinem hübschen Anzug, den ich mir für die neue Stelle extra gekauft hatte.

Bei meinem dritten Meeting waren bereits etwa 20 Kollegen dabei von allen möglichen Disziplinen (Strategie-Menschen, Architekten, Projektleiter etc.). König Arthur sass neben mir, und so haben wir zwei Stunden damit verbracht, herauszufinden, was die werten Kollegen so diskutieren. Für König Arthur ist das alles auch noch relativ neu, er ist wie ich ein Java Entwickler, der sich jetzt in der neuen Rolle als Enterprise Architekt wiederfindet.

Wir haben alles versucht, um der Lage Herr zu werden, aber ich sage Ihnen eines, geehrter Leser. Wenn Sie es nicht kennen, können Sie es sich nicht vorstellen, wieviele Fremdwörter in solch kurzer Zeit hören kann!

Erschwerend dazu kommt, dass meistens mehrere der anwesenden Personen gleichzeitig geredet haben. Und die Person neben mir hat ständig zu allem Fragen gestellt. Der Oberarchitekt hat dann auf einem Flip-Chart die Zielarchitektur der gewünschten Software Lösung skizziert und beschriftet, aber leider konnte ich seine Schrift nicht entziffern, was die Sache nicht gerade einfacher machte. So habe ich verzweifelt versucht, die wichtigsten Aussagen in einem Protokoll zu sammeln, während wir gleichzeitig eine Audioaufnahme des Geschehens machten, welche König Arthur nach dem Meeting nochmals durchhört hat.

Natürlich war das gesamte Meeting auf Englisch, und die geschätzten Kollegen, welche Englisch als Muttersprache sprechen, sind dabei besonders schwer zu verstehen, da sie meistens sehr schnell sprechen. Eine echte Herausforderung!

Vielleicht kann ich Ihnen folgendermassen klar machen, wie chaotisch das ganze Meeting war: Bei meiner Anstellung in die Firma hatte ich ein zweistündiges Telefoninterview über Software Architektur mit einem mir damals unbekannten Kollegen namens Deryck Whibley. Vor diesem Riesenmeeting habe ich in der Teilnehmerliste gesehen, dass Deryck auch an dem Meeting teilnehmen wird – also habe ich mich schon gefreut, ihn kennenzulernen. Leider habe ich ihn während des Meetings nicht gesehen (gut wie gesagt, 98% aller Leute kannte ich noch nicht). Deshalb ging ich zum Oberarchitekten und sagte ihm „Schade, dass Deryck nicht gekommen ist, ich hätte ihm gerne die Hand geschüttelt!“

Und was war die Antwort vom Oberarchitekten? „Deryck war die erste Hälfte des Meetings hier! Er sass gleich neben mir!“

Wie sich also herausstellte, sass Deryck, den ich so gerne mal gesehen hätte, nur zwei Meter von mir entfernt und ist dann aber in der Hälfte des Meetings aufgestanden und gegangen (völlig normal in meiner Firma). Zuerst hat es bei mir nicht geklickt, aber plötzlich erinnerte ich mich: Da war so ein Mann, der den anderen ständig Fragen gestellt hat… Das war Deryck!!! Oje… Anhang des Profilbildes im System habe ich ihn mir ganz anders vorgestellt…

So ging es dann die nächsten Tage weiter: Meeting über Meeting mit immer wieder wechselnden Teilnehmern. Was ich aber zugeben muss: Ich habe in diesen wenigen Tagen unglaublich viel gelernt – Zum einen über Unternehmensarchitektur, zum andern auch über das ganze Thema Finanzen. Und während man zu Beginn glaubt, ein Meeting erinnert an einen Stall voller aufgescheuchter Hühner, erkennt man nach einigen Meetings bereits, dass durchaus eine Ordnung dahinter zu finden ist…. (oder auch nicht…?)

Aber eigentlich wollte ich nicht über Meetings schreiben, sondern über Offerten.

Wie funktioniert eine Offerte in einem kleinem Unternehmen?

Die letzten zwei Jahre, die ich in einem kleinen Unternehmen gearbeitet hatte, gab es auch ab und an eine Offerte zu bearbeiten. Das funktioniert jeweils so: Irgendeine Firma, nehmen wir zum Beispiel die Deutsche Bahn, hat irgendeine gute Idee, die sie gerne umsetzen möchte. Sie möchte zum Beispiel durch Gesichtserkennung im Handy den Gemütszustand des Kunden mittels Machine Learning herausfinden. Macht der Kunde einen zufriedenen Eindruck, schlägt die Deutsche Bahn-App eher Züge vor, die wahrscheinlich überfüllt sein werden. Falls der Kunde einen Lätsch 😡 macht, schickt man ihn eher auf einen leeren Zug in den Randzeiten. Und sieht der Kunde hungrig aus, schickt man ihn in den Speisewagen. Dort wäre dann auch König Arthur ständig anzutreffen 🙂

Die Deutsche Bahn sammelt also alle Anforderungen zu dieser neuen Funktion möglichst genau in einem Dokument und veröffentlicht dieses.

Nun können beliebige Firmen die Offerte nehmen, studieren, und dazu einen Lösungsvorschlag abgeben, natürlich mit einem Vorschlag, wie viel Aufwand Lösung braucht und wieviel die Deutsche Bahn dafür zahlen muss. Die Deutsche Bahn sammelt dann alle Vorschläge der Firmen und entscheidet sich anschliessend nicht für heimische deutsche Entwickler sondern für die um einige hundert Euros günstigeren Konkurrenten aus Polen. 😉

Wie auch immer, wichtig bei dieser ganzen Offertensache ist: Der Aufwand für den Lösungsvorschlag wird dabei nicht bezahlt! Erst wenn die Deutsche Bahn sich für eine Firma entscheidet hat, bekommt diese Firma Geld und alle anderen Teilnehmer gehen leer aus.

Hatte in der kleinen Firma also ein Mitarbeiter ein bis zwei Wochen Zeit, bekam er die Möglichkeit, eine möglichst gute Lösung auf das Problem der offerierenden Firma zu finden und diese zu beschreiben.

Wie aber sieht das bei einem grösseren Projekt aus?

Eine Offerte in einem grossen Unternehmen

Grundsätzlich funktioniert eine Offerte genau gleich. Gut, Blogeintrag fertig, bis zum nächsten Mal! ❤

Nein, eine Offerte funktioniert zwar prinzipiell gleich, aber in völlig anderen Dimensionen, welche erst einmal beherrscht werden müssen. Nehmen wir an, die Deutsche Bahn will keine App erstellen, sondern ihre gesamte IT-Infrastruktur erneuern, quasi Deutsche Bahn 2. Die alte IT-Infrastruktur soll nicht weiter verwendet werden, stattdessen baut man alles neu, mit dem neuesten Technologiestack (Ein Stack zeigt auf, welche Technologien für ein Informatikproblem beziehungsweise deren Lösung verwendet werden. Welches Betriebssystem, welche Programme etc.).

Ja, da wird es natürlich interessant. Können Sie sich vorstellen, wieviel eine Deutsche Bahn 2 kostet? Nein? Ich auch nicht!

Nein, das benötigt zuerst einmal jede Menge Strategieleute, die sich mit dem Geschäftsfall oder Business Case auseinandersetzen.

Und was ist mit den Geschäftsprozessen? Die werden ja wahrscheinlich auch ändern, oder? Dann benötigt es Spezialisten, welche die heutigen Prozesse analysieren und die neue Lösung, die sogenannte Business Architektur konzipieren können.

Und irgendwo muss das neue System ja auch laufen, richtig? Wieviele Server muss man kaufen, damit die neue Software darauf laufen kann? Oder lässt man alles in der Cloud laufen? Aber in welcher Cloud? Und was sind das überhaupt Programme? Wir benötigen eine Technologie Architektur! (Und die sollte sich möglichst nicht zu weit von der Business Architektur entfernen – Leichter gesagt als getan!)

König Arthur’s Schlachtzug ins ungewisse Land

Und genau in dieser schönen Situation befinden König Arthur und ich uns jetzt. Bereits an meinem zweiten Arbeitstag im Büro habe ich nämlich erfahren, dass ich mit König Arthur zusammen die Technologie Architektur für dieses grosse Projekt konzipieren darf.

Das wirklich wirklich schöne ist, dass man in so einem riesigen Unternehmen niemals alleine ist. Und die Mitarbeiter sind wirklich enorm hilfsbereit und auch motiviert, dieses Projekt über die Bühne zu bringen!

Und was man machen muss, das wird uns auch schnell erklärt: Man braucht eine Übersicht über die heutige IT-Infrastruktur. Nicht im Detail, sondern aus grosser Höhe, ein Big Picture von den heutigen Prozessen, welche Applikationen dahinter stehen und wie diese miteinander Arbeiten. Zusätzlich muss man herausfinden, welche Daten die Deutsche Bahn wo gespeichert hat und welche man davon wiederverwenden oder migrieren kann (Stichwort: Make or Buy von Software).

Das Problem, ähm ich meine die Herausforderung ist aber: König Arthur und ich haben keinen Zugriff auf die Deutsche Bahn! Wir haben zwar bereits eine Handvoll Mitarbeiter welche dort stationiert sind, der Grossteil des Projekts befindet sich aber noch in den heimischen Büros und hat keine Möglichkeit, entweder mit den Deutsche Bahn-Mitarbeitern zu sprechen oder deren Dokumente zu inspizieren. Klingt spassig? Ist es auch!

Es ist quasi ein wenig wie das Huhn-Ei Problem: Wir möchten gerne zu der Deutschen Bahn, um deren Prozesse zu studieren, damit wir ihnen eine möglichst gute Lösung für ihr Problem anbieten können. Gleichzeitig sind wir aber in der Offertenphase und die Deutsche Bahn hat noch keinen Vertrag unterschrieben, was uns daran hindert, zu ihnen zu gehen und das aktuelle System zu studieren.

Selbstbeschäftigung

Eine unmögliche Aufgabe? Nein, tatsächlich können wir uns sehr gut selber beschäftigen, indem wir alle Artefakte soweit vorbereiten, wie wir es können. Ich denke aber, das sollte ich auch in einem eigenen Tagebucheintrag beschreiben, was es heisst, eine Technologie Architektur zu konzipieren.

Sehen Sie, dieser Blogeintrag ist ist typisch für ein Projekt dieser Grössenordnung. Ich wollte gar nicht soviel über Offerten oder Meetings schreiben! Da denkt man, man schreibt kurz, wie man in einem Projekt am effektivsten voranschreitet, merkt aber dann, dass man noch zuerst A und B und C braucht, bevor man sich mit seinem D selbst beschäftigen kann.

Nichtsdestotrotz muss man aber immer optimistisch bleiben und dran glauben, dass am Ende des Regenbogens ein Topf voll Gold steht, auch wenn anfangs das Gefühl hat, die aufgescheuten Hühner werden den Weg dorthin niemals finden. Ich persönlich bin sehr gespannt, wie sich das Projekt weiterentwickeln wird.

Und wenn Sie jemand fragt, woher Sie wissen, dass die Deutsche Bahn ihre IT-Infrastruktur erneuern will und dass das Projekt firmenintern Projekt Hasenstall genannt wird – Das haben Sie nicht von mir!

(PS bezüglich Huhn-Ei-Problem: Das Ei war zuerst da, ist ja logisch! )

Hier gehts zum Consultant Tagebuch 3: Der Verrat an König Arthur

Werbeanzeigen

Consultant Tagebuch 1: Das verpatzte Interview

Wer wissen will, wie das Leben eines Informatik-Consultants, also eines „Beraters“, aussieht, ist hier richtig.

Im Februar 2019 habe ich meinen neuen Job als IT-Consultant angetreten.

Bisher war ich immer als interner Mitarbeiter angestellt gewesen. Heisst: Ich hatte einen Arbeitgeber und dort war ich in einem Team stationiert und blieb dann jeweils auch über mehrere Jahre am gleichen Ort.

Als Consultant ändert sich das nun folgendermassen: Ich bin ebenfalls bei einer Firma angestellt, arbeite aber bei anderen Firmen als externer Mitarbeiter. Diese Firmen sind also unsere Kunden, und sorgen mit ihren Zahlungen für die Leute für das Einkommen meiner Firma. Ich werde diese Firmen darum ab sofort auch immer als Kunden bezeichnen. Das Kredo heisst also, dass man grundsätzlich immer beim Kunden sein wird, da man sonst quasi ein Kostenfaktor für die eigene Firma ist.

Obwohl ich noch nicht lange dabei bin, habe ich in meiner Firma bereits sehr viele nette Leute kennengelernt. Und das ist auch genau die Kernkompetenz meiner Firma. Wenn Kunden entweder etwas risikoreiches bauen wollen oder einfach sonst nicht genügend Leute haben, können sie zu meiner Firma gehen und diese sagt dann Nicht genügend Projektleiter? Hier, nimm eine Handvoll! oder „Du brauchst Business Analysten? Keine Sorge, ich hole zwei Mitarbeiter aus Zürich, drei aus Deutschland und einen aus Basel, sie werden für Dich ein Jahr lang arbeiten.“

Echt faszinierend, nicht? Man arbeitet also immer projektbasiert für eine vordefinierte Zeit, das Projekt kann aber grundsätzlich auch jederzeit entweder verlänger oder abgebrochen werden. Und die IT-Projekte beziehungsweise die Themen sind topmodern, da findet man alles von Blockchain über Cloud über Big Data über Künstliche Intelligenz. Das hat für mich auch den Reiz ausgemacht, überhaupt die Stelle anzutreten. Diese Abwechslung oder die Spannung, welches Projekt als nächstes ansteht.

Natürlich kann man selbst nicht immer auswählen, welches Projekt man gerne hätte. Grundsätzlich wird natürlich so smart wie möglich eine Übereinstimmung von Mitarbeiterfähigkeiten und nachgefragten Fähigkeiten gemacht. Wenn ich also die letzten 6 Jahre Java programmiert habe, macht es wohl durchaus Sinn, dass ich bei einem Kunden lande, der einen Java Programmierer benötigt.

Immer natürlich vorausgesetzt, dass ich gerade frei und nicht schon vergeben bin. Denn etwas, was mir jetzt schon aufgefallen ist, ist der Mangel an Programmierern. Man liest es ja immer wieder mal im Internet, und ich fühle das tatsächlich: Programmierer sind zur Zeit echte Mangelware!

Jetzt ist es nicht so, dass meine Firma nur Programmierer einstellt, eher im Gegenteil: Sehr viele Mitarbeiter bewegen sich im Consultantbereich auf der Businessseite statt auf der… hmm nein, technische Seite kann ich nicht sagen, es geht ja schon immer um die Digitalisierung. Zum Beispiel gehen die Strategie-Berater zu Kunden um mit ihnen eine Strategie zu entwickeln, wie sie ihr unternehmen im heutigen digitalen Zeitalter vorwärts bringen.

Ich will einfach deutlich machen: Es existieren Unmengen von anderer Disziplinen als nur der Softwareentwickler. Hier eine kleine Auswahl: Projektleiter, Business Analyst, Testing, Business Process Engineering, Portfolio Management, Controlling, Architekt, Release Train Engineer beziehungsweise Agile Spezialist/Agilist/Scrum Master, Security Manager… ihr seht worauf ich hinauswill.

Wer also immer noch nicht weiss, was er mal werden will, der könnte an dieser Stelle anfangen zu denken „Hmm…. vielleicht probier ich doch nochmal dieses Java Hello World aus, das vor fünf Jahren nicht geklappt hat…

Was ist jetzt mit dem Interview?

Okay okay, genug geschwatzt. Kommen wir zum Thema. Wie geschrieben, ist man also grundsätzlich bei einer Firma angestellt und arbeitet aber ebenso grundsätzlich bei Kunden. Ich bin momentan dabei, mein erstes Projekt zu finden – beziehungsweise die Leute/Projekte finden mich, da es effektiv zu wenige Programmierer gibt.

So wurde ich also zu einem Kundeninterview eingeladen.

Nur mal so zum Thema Kundeninterview: Das war für mich als interner ebenfalls neu. Ich meine, ich hatte ja bereits ein Anstellungsgespräch bei meiner Firma und diese Firma weiss von meinem Lebenslauf, was ich kann. Dennoch wollen Kunden jeweils noch ein Interview mit dir. Das kann wohl verschiedene Gründe haben (Also ich spekuliere nur, ich weiss die echten Gründe nicht): Zuerst mal schaust du als Kunde, ob der dir geschickte Mitarbeiter tatsächlich dem entspricht, was auf dem Lebenslauf steht. Dazu kommen aber noch unzählige andere Faktoren: Wie verhält sich das Gegenüber? Gibt er mir die Hand? Verstehen wir uns auf menschlicher Ebene? Verspricht er mir das blaue vom Himmel, kann aber dann keines der Versprechen halten? Und so weiter, ich denke, ihr versteht, was ich meine. Es muss halt passen, immerhin möchte man die folgenden Monate eng miteinander zusammenarbeiten (und bezahlt auch eine Menge dafür).

Das Interview kann auch nur per Telefon stattfinden. Da wird der Punkt mit dem Händeschütteln natürlich ein wenig schwierig zu prüfen, aber immerhin die Ausdrucksweise oder ob man des Englischen tatsächlich mächtig ist wird dabei schnell klar. In diesem Fall war ich aber vor Ort und durfte meinem Schicksal in die Augen sehen.

Natürlich muss man an dieser Stelle sagen, dass Programmierer nicht immer die redseligsten Menschen sind. Oder halt, ich muss es noch anders ausdrücken: Menschen sind nun einmal unglaublich divers. Jede Person ist einzigartig, auch wenn man oftmals meint, man gehe in der Masse von Menschen unter. Aber ja, Programmierer im Speziellen sind nicht immer die typischen Plaudertaschen, obwohl sich dieses Bild in den letzten Jahren auch gewandelt hat. Und ich denke, nach einigen Jahren in meiner Firma werde ich das auch gut im Griff haben, denn sagen wir mal… nun… ähm, ich kann nicht behaupten, dass in meiner Firma wenig geredet wird… 😉

Vorbereitung für die Katz

Wie auch immer, ich wollte mich also vorbereiten auf das Interview und wurde von mehreren Kollegen, die bei diesem Kunden schon einmal waren, mit Ratschlägen beschenkt. Der Tenor war: Der Kunde stellt viele SQL- oder Daten-relevante Fragen, also bereite dich darauf vor. Also habe ich meine SQL Fähigkeiten aufgefrischt, den INNER und OUTER JOIN nochmals studiert, das Entity-Relationship-Model angeschaut, Venn-Diagramme repetiert und so weiter.

Ja verdammt, nichts davon ist am Interview gekommen.

Ja gut, im Nachhinein ist man immer schlauer. Ich meine, immerhin wurde ich als Java Entwickler an das Interview geschickt (aber das wurde nicht gross propagiert oder so), weshalb ich dachte, vielleicht ist dem Kunden einfach wichtig, dass die Mitarbeiter wissen, wie man mit Daten umgeht.

Universitätsfragen par excellence

Da ging ich also in den Meetingraum mit dem Interviewer des Kunden, oder nennen wir ihn mal liebevoll Java Enthusiast. Und kaum haben wir 5 Minuten über meinen Werdegang gesprochen, ging es los.

Hier eine kleine Auswahl der gestellten Fragen:

  • Was sind die Neuerungen von Java 8?
  • Was sind Lambdas?
  • Wie funktionieren Lambdas intern?
  • Was sind Streams?
  • Wie funktionieren Streams intern?
  • Wenn man einen Stream mit x Operationen hat, wieviele Collections werden dann intern erstellt?
  • Welche drei Collectiontypen gibt es in Java?
  • Wie funktionieren sie intern?
  • Was ist die Big-O-Notation dieser Collections?

Man hat gemerkt, dass der liebe Java Enthusiast ein Mann des Faches war und die Details dieser Sprache liebte. Ich denke, er ist sehr auf Performanz getrimmt und hat sich schon lange Zeit mit diesem Thema beschäftigt: Welche Liste ist schneller für welchen Anwendungsfall? Wie funktionieren die Java Methoden intern?

Ich gebe zu, das klingt alles nach Fragen, deren Antworten ein Java Programmierer kennen sollte.

Aber stellen wir uns mal kurz vor, dass der zu Interviewende nicht die letzten fünf Jahre damit verbracht hat, jede existierende Java Methode zu überprüfen, wie sie intern funktioniert. Stellen wir uns vor, dieser Mensch hat die letzten vier Jahre im Informatikstudium verbracht und sich jedes Semester mit 6 verschiedenen Fächern rumgeschlagen, als Abschlussarbeit Machine Learning mit Python gelernt hat, dazu noch 70% gearbeitet, und in dieser Zeit noch zwei Kinder gezeugt. Und dann stellen wir uns vor, dass dieser Person die letzten drei Wochen Blockchain und Kotlin angeschaut hat, statt sich zu fragen, wie viele Collections innerhalt eines Streams erzeugt werden. Und dann stellen wir und zum Schluss noch vor, dass diese Person die erste Woche im neuen Job ist und bereits mehrmals mehr als 9 Stunden im Büro an irgendwelchen Meetings war – Und sich für das Interview mit SQL vorbereitet hat.

Ja, das scheint keine optimale Kombination zu sein, um diese Fragen zu beantworten, richtig? Genauso ist es dann auch herausgekommen. Wobei ich sagen muss, dass ich viele Dinge, die der Java Enthusiast mich gefragt hat, theoretisch gewusst hätte beziehungsweise schon einmal wusste.

Big-O-Notation hatten wir zum Beispiel im IT-Studium, aber denken Sie, das ist mir dann spontan eingefallen? Oder was mir ein wenig schwer gefallen ist: Als kleine Übung musste ich an der Tafel eine Methode programmieren, welche sagt, ob eine Zahl eine Primzahl ist oder nicht (habe ich zuerst noch falsch verstanden, das Interview war auf Englisch). Was haben wir doch damals, vor vier Jahren, im Studium unzählige Male von hinten und nach vorne studiert, wie eine Primzahl genau ist, wie man herausfindet, ob eine Zahl prim ist, welche Algorithmen existieren etc!

Ja, auf jeden Fall habe ich mich am Ende des Interviews hundsmiserabel gefühlt. Was war Java nochmals? Eine Insel? Nein, es gibt doch auch eine Programmiersprache namens Java, nicht?

Nicht unterkriegen lassen trotz Ego am Boden

Ich fühle mich tatsächlich schlecht, weil ich die Antworten auf seine Fragen eigentlich wusste, sie aber nicht wiedergeben konnte oder sie einfach nicht aktiv in meinem Gehirn-Memory waren. Ich bin sehr gewissenhaft, darum werde ich die Antworten auf seine Fragen zu Hause nochmals genau studieren (das muss ich jetzt schreiben).

Aber es ist genau wie im Studium: Schlussendlich gibt es ein riesiges Spektrum von Fragen, welche das Gegenüber stellen könnte, und man kann studenlang genau das Thema lernen, nur um am Ende festzustellen, dass der Dozent genau die Frage stellt, bei denen man dachte „Ach nö, das kommt garantiert nicht!“

Ein Punkt, den man einfach auch an der heutigen unglaublich riesigen IT-Landschaft muss: Es ist einfach nicht mehr so wie früher, wo man eine Programmiersprache lernen konnte, und dann hatte man für Jahre ausgesorgt. Zum einen gibt es in Java selber unglaublich viele Veränderungen wie etwa Spring 5, Spring Boot 2, Jakarte EE und so weiter.

Zum anderen gibt es einfach auch tausend (sehr interessante) Themen sonst in der Informatik: Jegliche andere Programmiersprache, Docker/Kubernetes/Container, Cloud Computing, Blockchain, Künstliche Intelligenz, JavaScript welches auch eine eigene Welt in sich ist, dann noch dies und das und jenes. Wirklich extrem, wie sich Informatik entwickelt hat.

Aufgepasst! Schwerere Interviews in anderen Ländern

Der Java Enthusiast, der mir die Fragen stellte, war ein Engländer. Ich habe ihm während des Interviews klar gesagt, dass ich viele Dinge nicht wüsste und dass mich auch noch niemand solch technische Fragen über Java gestellt hat. Ich habe ihm ganz konkret gesagt: Das war das schwerste Interview überhaupt! (Und die Tatsache, dass ich in meiner neuen Firma einen Anzug trage, hat auch nicht zum Erfolg geführt, verdammt!)

Der Java Enthusiast hat mir dann auch klar gesagt, dass er in vielen Ländern an Interviews war und dort solche Fragen eher der Standard als die Ausnahme sind (man nennt diese technischen Fragen auch Google Style Fragen, da Google berühmt ist für schwere Fragen/Interviews). Es wird erwartet, das ein Java Entwickler sich tief und lange mit der Sprache auseinandergesetzt hat und die Internas kennt – Was ich bis zu einem gewissen Grad auch gut finde.

Dann wiederum denke ich auch, dass ich aus lerntechnischer Sicht nicht jede Java Methode auswendig aufsagen kann, besonders da ich mich von den Themen, an denen ich arbeiten kann, eher breit aufstelle als tief, und er aber offensichtlich einen wirklich tiefen Java Taucher gesucht hat.

Der Java Enthusiast hat dann auch gemeint, er wäre sehr erstaunt gewesen, als er in der Schweiz an ein Interview ging und keine einzige dieser Fragen gestellt bekam. Da müssen wir Entwickler aufpassen, dass wir von unseren ausländischen Kollegen nicht abgehängt werden! (Jeder weiss für sich selber, ob er sich angesprochen fühlen sollte)

Auf jeden Fall habe ich mich nach dem Interview echt schlecht gefühlt. Darum habe ich auch, sobald ich das Interview verlassen hatte, bis zum Einschlafen vor mich hingesagt: „Du bist ein guter Java Entwickler! Du bist ein guter Java Entwickler! Du bist ein guter Java Entwickler!…

Nein, Scherz 🙂

Alles in Ordnung

Ich kann Java programmieren und ich musste bis jetzt auch in keinem Interview solche Fragen beantworten. Ich bin aber auch so interessiert und offen, dass ich die Antworten nachlesen und mich beim nächsten Mal besser vorbereiten werden. Aber ja, im Nachhinein ist man halt wirklich immer schlauer! Plus muss ich auch anmerken, dass man, wenn man als Java Entwickler arbeitet und im Flow ist, solche Fragen/Antworten ohne Probleme innerhalb weniger Minute googled oder auf Stackoverflow liest. Ich habe in meinem Job als Java Entwickler schon tausende „Abklärungen“ gemacht, wie etwas genau funktioniert, aber mittlerweile alles wieder vergessen (ja ich weiss, Sie sind jetzt empört).

Ich könnte natürlich auch einfach die Schuld auf meine Kinder schieben. Ja nein, die sind echt nervig, nein, ich wollte eigentlich jeden Abend der letzten zwei Jahre eine Java Methode inwendig studieren, aber wegen dieser Blagen kommt man ja zu gar nichts mehr!

Nein, ich mache nur Scherze 😉

Ja das war meine erste Erfahrung mit einem Kundeninterview als Consultant. Werde ich jemals einen Kunden finden, der waghalsig genug ist, mich in ein Projekt zu lassen? Seien Sie dabei wenn es wieder heisst: Marcel, der fröhliche Consultant, sucht ein Projekt!

Hier geht es zum Consultant Tagebuch 2: Selbstbeschäftigung

Was ist die Corda Blockchain?

Achtung: Corda ist momentan brandheiss! Wäre Corda eine heisse Suppe, wären momentan viele Menschen bereit, sich die Zunge zu verbrennen, um mehr Informationen darüber zu erhalten oder entsprechende Projekte umzusetzen.

Corda ist eine Open Source Blockchain Plattform basierend auf der Distributed Ledger Technology (DLT). Corda gehört zur dritten Blockchain Welle.

Eine private Blockchain

Weiss eigentlich mittlerweile jeder, was eine Blockchain ist? Falls nicht, bitte kurz die Einführung dazu lesen.

Corda ist eine Weiterentwicklung der ursprünglichen Blockchain für Bitcoins. Der Grundgedanke ist aber geblieben: In einem Netzwerk hat es verschiedene Teilnehmer (Englisch: peers oder nodes oder participants) und jeder Teilnehmer hat eine Buchhaltung über die getätigten Transaktionen. (Ich mag das Wort Buchhaltung mehr als Hauptbuch, obwohl das eigentlich treffender wäre für das englische Wort ledger. Schlussendlich könnte man auch Datenbank sagen, das ist schlussendlich nicht so relevant für das Verständnis).

Im Gegensatz zur Bitcoin Blockchain hat aber jeder Teilnehmer seine eigene Buchhaltung!

Es gilt nicht mehr das Prinzip, dass alle Transaktionen öffentlich sind und im gesamten Netz verteilt werden. Teilnehmer A kann Teilnehmer B Geld schicken, und nur diese beiden Nodes kennen dann diese Transaktionen.

Und besonders im Businessbereich, etwa bei Banken, ist die Privatsphäre das oberste Gut. Und Corda verspricht, diese Privatsphäre zu gewähren und zu schützen.

Zusammenarbeit mit Industriepartnern

Der grosse Vorteil von Corda: Es wurde von Grund auf für das Business konzipiert. Die dafür zuständige Firma R3 steht dazu im Kontakt mit über 200 Mitgliedern der Industrie, darunter Banken oder Wirtschaftsverbände.

Das Ziel von Corda ist es, komplexe Finanztransaktionen durchführen zu können. Der Austausch von Bitcoin zwischen A und B ist aus finanztechnischer Sicht nämlich eine einfache Transaktion. In einer Bank oder einer Versicherung müssen hunderte weitere Finanzinstrumente umgesetzt werden können.

Und wo werden die umgesetzt? Natürlich in Code, und dafür gibt es uns Programmierer 🙂

Die Programmierlogik wird dabei in sogenannte CorDapps gepflanzt.

Obwohl Corda von der traditionellen Blockchain inspiriert wurde, gibt es darin keine Kryptowährung. Corda geht noch viel weiter: Das Ziel ist es, jedes beliebige Finanzinstrument definieren und verwenden zu können.

Double Spending Problem wird durch Notare verhindert

Ein grosses Problem bei Blockchain Netzwerken ist das Double Spending Problem. In Corda sind die Lösung dazu sogeannte Notare. Dabei handelt es sich um einen weiteren Teilnehmer im Corda Blockchain Netzwerk – Dieser Teilnehmer kann aber mehrere Notare beinhalten.

Notare haben das Ziel, zu prüfen, dass bereits ausgegebenes Geld nicht noch einmal ausgegeben wird. Das wird technisch relativ einfach implementiert: Alle Transaktionen beziehungsweise jeder Geldbetrag wird in einer Liste gespeichert. Wenn der Geldbetrag schon einmal ausgegeben wurde, kann er nicht noch einmal ausgegeben werden.

Ja gut, das ist jetzt vielleicht ein bisschen arg fest vereinfacht erklärt (obwohl es natürlich Sinn macht). Für technische Details mache ich eventuell mal einen eigenen Blogeintrag.

Ein kleiner technischer Einblick in Corda

In Corda gibt es besonders drei technische Objekte, die von zentraler Relevanz sind:

  • States (welche in Transaktionen verwendet werden)
  • Contracts
  • Flows

Ein State ist dabei quasi ein Snapshot von einem beliebigen Objekt – etwa eines Kontos. Eine Transaktion ist dann die Überführung von einem Zustand (Input State) zu einem anderen (Output State). Wenn Person A also 100 Dollar an B zahlen will, wird eine Transaktion erstellt, bei der Person A im Input State 100 Dollar besitzt und im Output State diese an Person B übergeben werden.

Technisch isch ein State einfach eine Java… ähm ne warte, eine Kotlin Klasse mit Attributen, Gettern und Settern. Es können aber beliebige Attribute definiert werden, und genauso können beliebige finanzielle Produkte in Code erstellt werden.

Ein Contract beinhaltet Prüfungen, die eine Transaktion bestehen muss, damit diese valid ist. Wenn Person A 100 Dollar an Person B geben will, kann eine solche Prüfung etwa sein „Hat Person A 100 Dollar auf dem Konto?“ oder auch „Hat Person A überhaupt ein Konto bei uns?„. Die Prüfungen können beliebig eincodiert werden.

Ein Flow beschreibt den gesamten Transaktionsfluss. Wenn Person A Geld an Person B schicken will, muss Person A beziehungweise sein Node in der Blockchain eine Transaktion erzeugen und diese mit dem entsprechenden Contract prüfen lassen. Dann schickt Person A die Transaktion an Person B/Node B und B prüft die Transaktion ebenfalls. Erst wenn beide Teilnehmer die Transaktion erfolgreich validieren, wird diese ausgeführt und committed. Dieser Prozess wird in Corda als Flow implementiert.

Das folgende Bild verdeutlicht das Konzept des Flows. Generell muss ich sagen, dass das Lehrmaterial ausgezeichent ist (siehe Kapitel „Corda lernen“ unten) und mit vielen Bildern/Videos unterstützt wird.

Beispiel eines Flows

Das Bild kommt von dieser URL: https://docs.corda.net/key-concepts-flows.html

Kryptografische Highlights

Aus Sicht eines Kryptografens werden nicht allzu verrückte Techniken eingesetzt.

Ein wichtiger Teil sind Hashfunktionen. Sie wissen schon, dass sind diese Dinger, wo man irgendetwas reinquetschen kann und heraus kommt ein einzigartier Hash wie etwa der folgende:
7e716d0e702df0505fc72e2b89467910

Es wird so ziemlich alles verhasht, was man sich vorstellen kann. Die Transaktionen in der Buchführung eines Nodes werden natürlich auch miteinander verlinkt und unveränderbar (immutable) gemacht, ganz dem Konzept von Blockchains. Jede Transaktion erhält dann den Hash der vorhergehenden Transaktion – und nicht die Transaktion selber.

Das zweite grosse Konzept sind digitale Signaturen – Genau wie in anderen Blockchains. Wenn Person A Geld an Person B schicken will, muss A seine Transaktion signieren, damit B prüfen kann, dass die Transaktion wirklich von A kommt. Genauso wird B die Transaktion signieren, wenn diese erfolgreich validiert werden konnte.

Corda lernen

Corda ist in Kotlin geschrieben. Wer also Corda lernen möchte, der hat damit gleichzeitig eine schöne Motivation, um Kotlin zu lernen.

Ansonsten empfehlen ich jedem, der Corda lernen möchte, folgendes:

Für alle Personen empfehle ich das wirklich gut gemachte Webinar von R3, welches die Corda Konzepte erläutert:
https://r3.lessonly.com/path/5150-corda-key-concepts

Natürlich ist auch die offizielle Homepage und Referenz sehr empfehlenswert:
https://docs.corda.net/index.html

Auf der Corda Homepage kann ein Zertifikation über Corda erworben werden: https://www.corda.net/develop/index.html

Und Entwicklern, die ihre eigenen CorDapps entwickeln dürfen, sei das Bootcamp auf Youtube empfohlen:

Der Link mit der gesamten Playlist ist folgender:
https://www.youtube.com/playlist?list=PLi1PppB3-YrVq5Qy_RM9Qidq0eh-nL11N

Corda auf Stackoverflow (corda tag):
https://stackoverflow.com/questions/tagged/corda