Hol Dir einen Kaffee, mach Dir entspannende Musik an, und begleite uns zur neunten Folge von The Hüb. Diesmal teilt Đorđe Madić die wertvollen Erfahrungen, die er als Tech Lead bei Zühlke gesammelt hat.
„Willkommen bei The Hüb – einem Ort, an dem unsere Fachleute ihre ehrlichen Meinungen, Ideen und Erfahrungen sowie ihr Wissen zur Branche, ihrer Zukunft und wichtigen Trends weitergeben.“
Wie wird man Tech Lead? Was sind die Folgen schlechter Softwaretests? Welche Werte sind in IT-Unternehmen wichtig?
Hol Dir einen Kaffee, mach Dir entspannende Musik an, und begleite uns zur neunten Folge von The Hüb. Diesmal teilt Đorđe Madić die wertvollen Erfahrungen, die er als Tech Lead bei Zühlke gesammelt hat.
Ich bin neulich über ein Zitat gestolpert, das meine Erfahrungen als Tech Lead recht gut beschreibt. Das Buch „Fundamentals of Software Architecture“ von Mark Richards und Neal Ford zitiert Ralph Johnson, einen Software Architect und Autor diverser Bücher über Softwarearchitektur: „Bei der Architektur geht es um das Wesentliche ... was auch immer das sein mag.“
Das kann man auf die Aufgabe des Tech Lead übertragen.
„Tech Leads kümmern sich um das Wesentliche ... was auch immer das sein mag.“
Was will ich damit sagen? Also, ich habe mich mit den geschäftlichen Notwendigkeiten und mit dem Zustand unserer Systemarchitektur befasst – also Analysen durchgeführt, die auf die Zukunft ausgerichtet sind: Was erwartet uns morgen? Welche Auswirkungen hat das für uns?
Aber es geht nicht nur um rein technische Prozesse, sondern auch um Teamführung – einfach ausgedrückt, die Optimierung der Teamarbeit: Wie soll die Arbeit verteilt werden? Was hat die höchste Priorität usw.
Teach Lead wird man nicht über Nacht. Ich hatte am Anfang viel mit technischen Aspekten zu tun und bekam so nach und nach einen breiteren Überblick über die technische Seite des Jobs. Zu der eigentlichen Programmierarbeit kamen alle anderen Aufgaben, durch die ich die Zusammenhänge, die Gesamtperspektive kennengelernt habe. Daraus entstand ein Verantwortungsgefühl, vor allem im Hinblick auf den Teamerfolg. Was dadurch sicherlich angestoßen wurde, ist eine noch engere Zusammenarbeit mit den anderen in meinem Team. Ich programmierte weniger selbst und las dafür mehr Code. Außerdem führte ich immer mehr Gespräche mit anderen Kolleginnen und Kollegen im Unternehmen. Das Aufgabenspektrum war sehr ausgewogen; da war nichts, was ich vermisst hätte.
Was sich eindeutig geändert hatte war: viel mehr Umgang mit Menschen und weniger Programmierarbeit – wobei die Arbeit mit Menschen die größere Herausforderung ist.
Ich war schon immer ein großer Fan von Softwaretests. Warum? Sie geben mir das Selbstbewusstsein, den Code umzuschreiben, und meinem Team die Möglichkeit zur Softwareverteilung in kürzeren Abständen.
Bei der ständigen Arbeit mit automatisierten Tests, sind mir aber ein paar interessante Dinge aufgefallen:
Tests sind leicht einzubauen, aber schwer wieder zu entfernen.
Mein Team hatte schon des Öfteren die Gelegenheit, eine Codebasis zu übernehmen. Das heißt meist eine neue Business Domain, einen neuen Tech-Stack, neue Stakeholder.
Aber das Herausnehmen eines Tests – selbst eines offensichtlich schlechten – verursacht oft ein Gefühl der Unsicherheit: vielleicht gibt es den Test ja aus einem guten Grund – den wir nur nicht verstehen.
Tests sind manchmal zu schlau.
Wenn das Ergebnis ist, dass sich der Code nicht ändert, dürfen Tests im Grunde nicht anschlagen. Sie tun es aber trotzdem häufig, und die Behebung solcher Fehler ist ein Produktivitätskiller. Was hier fehlt, ist das richtige Abstraktionsniveau. Teilst Du manchmal Deinen Bildschirm, um Modultests für Deine neue Methode zu schreiben – Code links, Test rechts? Das kann dazu führen, dass Du Tests schreibst, die zu schlau sind.
Nur echte Daten sind gute Daten.
Wie oft arbeitest Du in Deinen Tests mit selbst erstellten, fiktiven Testdaten? Sehen die wirklich so aus, wie echte Produktionsdaten?
Wenn die Testdaten nicht realistisch sind – welchen Wert hat dann der Testbericht?
Fehler werden erst relativ spät bei der Integration entdeckt – das macht sie besonders teuer.
Falsch positive Ergebnisse gibt es immer dann, wenn die hypothetischen Testdaten in dieser Form in der Produktion nie vorkommen.
Realistische Testdaten helfen mir außerdem, die Business Domain hinter dem Code zu verstehen, vor allem bei großen Codebasen.
Consumer-Driven Contracts (CDC) setzen eine entsprechende Ausbildung voraus.
Als Engineers sind wir es gewohnt, Funktionstests zu schreiben. CDC-Tests haben aber einen anderen Zweck und erfordern im Design eine andere Herangehensweise. Ohne gezielte Weiterbildung auf diesem Gebiet sehen die CDC-Tests dann eher aus wie unbeholfene funktionale Integrationstests.
Immer sachlich bleiben.
Nimm nichts persönlich. Das macht unsere Arbeit insgesamt nur schwieriger. Sei bedacht und versuche bei anderen, deren Beweggründe nachzuvollziehen. Konzentriere Dich auf das eigentliche Problem. Halte eigene Emotionen aus der Arbeit raus.
Geh von Zeit zu Zeit „back to basics“.
Das ist die Ausgangsbasis, von der aus Du alles erreichen kannst. Wenn Du beispielsweise lange mit einem bestimmten Framework gearbeitet hast, ruf Dir die Grundlagen von JavaScript noch einmal in Erinnerung. Mach Dich mit ihnen vertraut, denn Du brauchst sie, um anspruchsvollere Tasks, Framework, Library usw. zu verstehen.
Sei Du selbst.
Wenn du in der Sache souverän bist, entspann sich und sei einfach Du selbst.
Natürlichkeit kommt im Kollegen- und Kundenkreis sympathisch rüber. Sei wie Du bist, bleib entspannt. So trägst Du auch zu einer ungezwungenen Arbeitsatmosphäre bei, und das ist gut für das Team. Vielleicht ist es Dir peinlich, dass Du mal was nicht weißt, dabei ist das gar nicht schlimm. Wir alle haben noch Wissenslücken oder in einem bestimmten Moment nicht alles abrufbar.
Was man wirklich lernen muss, ist die Kultur des „offenen Feedbacks“.
Daran muss man arbeiten und sich gewöhnen – also konstruktives Feedback im Kollegenkreis und von Fremden anzunehmen und auch selbst zu geben. Ich habe hierzu auch eine Weiterbildung gemacht. Durch Übung und den Austausch mit anderen wird das einfacher. Trotzdem wird es auch immer mal schwierige Situationen geben, gerade wenn es um kritisches Feedback geht.
Du musst daher Deine Intentionen klar darlegen und dafür sorgen, dass weder Du selbst noch Dein Gegenüber die Kritik emotional aufnimmt.
Mit das Wichtigste, das ich über Feedback gelernt habe, ist, dass es schnell gehen muss. Wenn wir zügig eine Rückmeldung erhalten, hat das großen Einfluss auf den Erfolg unserer Arbeit, unseres Teams und des ganzen Unternehmens.
Deshalb solltest Du, sobald Dein Team eine qualitativ hochwertige Arbeit abgeliefert hat, einen Feedbackprozess mit dem Kunden in Gang setzen. Oft ist ein Meeting zu diesem Zweck – sei es persönlich oder über Skype – ein guter Weg, um zu erfahren, ob der Kunde mit dem Prozess zufrieden war und ob es bei zukünftigen Projekten Verbesserungspotenzial gibt.
Đorđe arbeitet seit November 2016 bei Zühlke. Die meiste Erfahrungen hat er in Unternehmensprojekten im Bereich Telekommunikation, wo er als Full-Stack Software Engineer und Technical Team Lead tätig ist. Darüber hinaus ist er Career Coach bei Zühlke.
