Hol dir einen Kaffee, wähl‘ entspannende Musik, und nimm dir ein bisschen Zeit für die erste Folge unserer neuen Hüb-Serie. Diesmal berichtet Veljko Zrnić über die wertvollen Erfahrungen, die er als Lead Engineer bei Zühlke erworben hat.
Herzlich willkommen auf dem Hüb – einem Ort, an dem Fachleute großzügig ihre Expertise und ihr Wissen weitergeben. Wir informieren über die Branche, gestalten deren Zukunft mit und halten dich über alle wichtigen Trends auf dem Laufenden.
Wie funktioniert die Arbeit in einer großen Softwareentwicklungsabteilung? Warum lohnt es sich, mit neuen Technologien Schritt zu halten? Wie wichtig ist die persönliche Weiterentwicklung in diesem Berufsfeld?
Hol dir einen Kaffee, wähl‘ entspannende Musik, und nimm dir ein bisschen Zeit für die erste Folge unserer neuen Hüb-Serie. Diesmal berichtet Veljko Zrnić über die wertvollen Erfahrungen, die er als Lead Engineer bei Zühlke erworben hat.
Ich arbeite seit etwa fünfzehn Jahren in der Softwareentwicklung. Das Interesse und die Leidenschaft für IT zeigt sich meistens schon früh. Bei mir war das in der Schule mit den ersten Computern und Visual Basic. Mein erstes Projekt war eine Sternenhimmel-Simulation. Darauf war ich sehr stolz. Von da an ging es weiter – C++, Pascal ... Was mich am meisten angezogen hat, waren die Freiheit und Kreativität, das Gefühl, dass man etwas erschafft, das den Anwendern hilft, entweder indem es unterhaltsam ist oder nützlich.
Ich glaube, im Kern hat sich die Arbeit des Softwareentwicklers nicht verändert, solange ich dabei bin. Man braucht ein allgemeines Talent zum Programmieren, egal, woran man arbeitet. Die Begabung braucht man, um die Grundlagen zu meistern. Alles andere ist eine Frage der Präferenz, ob Java, .NET, DevOps-Werkzeuge oder was auch immer. Die Tools haben sich weiterentwickelt, neue Sprachen sind entstanden, aber die allgemeine Fähigkeit der Programmierer, sie sinnvoll zu nutzen, ist immer noch dieselbe.
Das ist eine Persönlichkeitsfrage. Will man in ein paar Jahren ein richtiger Spezialist für bestimmte Gebiete sein oder sich lieber in allem ein bisschen auskennen? Beides hat Vor- und Nachteile, und die sollte man sich schon bewusstmachen. Wenn man spezialisiert ist, muss man sich darüber im Klaren sein, dass sich die Technologien rasant weiterentwickeln, und man muss mit der Spezialisierung immer am Ball bleiben. Denk nur mal daran, wie nodeJS vor 5 Jahren aussah und was es heute ist. Wer lieber Generalist ist, kann bei der Arbeit schon manchmal auf seltsame Dinge stoßen, wenn das Wissen für die feinen Details der jeweiligen Technologie dann doch nicht ausreicht.
Aber es gibt natürlich keine scharfe Abgrenzung zwischen den beiden Herangehensweisen. Für mich finde ich eine Mischung am besten – sich auf eine Lösung zu spezialisieren, aber immer interessiert zu sein und zu versuchen, die Dinge auch aus einem anderen Blickwinkel zu betrachten, mal ein anderes Tool, eine andere Sprache zu verwenden, und sei es nur für kurze Zeit. So hat man einen besseren Überblick, wenn es um Anwendungen und um APIs seht und um alles dazwischen. Man muss die Komfortzone ab und zu mal verlassen, um Raum für die persönliche Weiterentwicklung und neue Ideen zu schaffen.
Wenn man mit der Arbeit an einem Projekt beginnt, muss man sich voll und ganz darauf konzentrieren. Man arbeitet am Tag acht Stunden daran, und wenn man wie ich eine Familie hat, bleibt nicht viel Zeit für zusätzliche Lektüre und Recherche. Wenn ich Zeit habe, lese ich die Nachrichten über die aktuellen Trends in der Branche, habe aber keine Gelegenheit, selbst neue Dinge auszuprobieren. Die Weiterbildung findet im Wesentlichen statt, während man Probleme des Projekts löst. Je mehr Probleme – desto mehr Erfahrung sammelt man. Mal überspitzt gesagt … Man sollte daher Problemen nicht aus dem Weg gehen, sondern sein Bestes geben, um sie zu lösen.
Die Situation ändert sich schnell, wenn man in großen Teams arbeitet. Organisatorische Dinge wie Aufgabendelegation, Arbeitskontext und individuelle Verantwortlichkeiten sind wichtig. Am allerwichtigsten ist die Kommunikation; wenn sie nicht gut funktioniert, leidet das Projekt darunter. Durch Teammitglieder, die nicht gut kooperieren, geht wertvolle Zeit verloren.
Wenn du beispielsweise von zu Hause aus arbeitest, kann die Korrespondenz mit anderen Teammitgliedern zu Missverständnissen führen. Etwas, was als Spaß gemeint war, kann z. B. falsch verstanden werden und jemand ist beleidigt. Es braucht Zeit, bis die Teammitglieder sich kennen, bis man weiß, wie die anderen „ticken“ und wie man ihre Kommentare einzuordnen hat.
Ich habe gute Kommunikation aus meinen Fehlern gelernt. Auf keinen Fall sollte man aber vermeiden zu kommunizieren oder Fragen zu stellen. Stell‘ immer Fragen, denn so findest du Lösungen – auch wenn das Feedback negativ ist. Immerhin weißt du es dann beim nächsten Mal besser.
Ich arbeite derzeit an einem großen und dynamischen Projekt mit 50 Mitgliedern in sechs verschiedenen Teams. Das sind eine Menge Leute für ein Produkt, was die Sache komplex macht. Wir arbeiten seit drei Jahren mit dieser Kapazität daran, und es baut auf einem Vorläuferprojekt auf, das sechs Jahre gedauert hat.
Wie schwierig hier Änderungen sind, kann ein Beispiel verdeutlichen – die Einführung einer Messaginglösung. Viele Entwickler, mich eingeschlossen, würden liebend gerne Änderungen in der Kommunikationsschicht vornehmen, um bestimmte hartnäckige Probleme zu lösen. Aber solche Änderungen macht man nur in den frühen Phasen eines Projekts. Auch wenn man auf den ersten Blick eine Menge Probleme lösen könnte, würde man sich viele neue einhandeln, umso mehr mit einem Altsystem.
An Design-Changes darf man nie überstürzt herangehen, weil man dabei immer Kompromisse eingeht.
Unsere Entscheidungen werden von einem Architekturteam getroffen. Wir haben aus jedem Team eine Person, die für die Architektur und den zugewiesenen Kontext verantwortlich ist. Alle Architekten kommen einmal pro Woche zusammen und diskutieren, wie sich jeder Kontext in das Gesamtprojekt einfügt. Ich finde diese Vorgehensweise hervorragend. Was ich mir nur wünschen würde, wäre eine explizitere Aufforderung an die Entwickler, Insights und Ideen vorzuschlagen, eine Einladung zur regelmäßigen Beteiligung. Die besten Ideen kommen oft von unerwarteter Seite, deshalb sollte man die Tür immer offen halten.
Was das Produkt angeht, so muss man an die Anwender denken, die es benutzen werden. Du kannst die tollsten Funktionen der Welt einbauen – wenn sie nicht auf die Bedürfnisse des Anwenders abgestimmt sind, hat es keinen echten Wert.
Im Hinblick auf Funktionalität und Problemlösung, musst du aus der Perspektive des Anwenders denken. Software hat die schlechte Angewohnheit, nicht immer wie erwartet zu funktionieren, und die Anwender haben das irgendwie hingenommen. Wenn man sich statt der Technologie mal eine Tür vorstellt, wäre es für die Benutzer aber nicht in Ordnung, wenn sie sich nicht ganz öffnen ließe oder von Zeit zu Zeit überhaupt nicht. Wir müssen Software verlässlich machen, so wie es für die meisten anderen Dinge gilt. Dieser Perspektivenwechsel braucht aber Zeit.
Bei der servicebasierten Entwicklung geht es dagegen nicht um Perfektion. Hier wird man mit Problemen konfrontiert, die man so schnell wie möglich lösen muss, und dann macht man weiter. Manche möchten gerne von der produktbasierten auf die servicebasierte Entwicklung umsteigen, weil die Arbeit dynamischer ist. Andere konzentrieren sich lieber voll und ganz auf eine Sache. Man kann nicht sagen, dass das eine oder andere besser ist – das ist eine Frage der persönlichen Vorlieben.
Das ist keine Frage. Man geht immer mit den neuen Technologien, weil die anderen schneller veralten. Mit neuen Technologien können wir moderne Lösungen für moderne Probleme finden.
Zurzeit beschäftige ich mich mit privaten und öffentlichen Cloud-Technologien und -Anbietern (GCP, AWS, Azure). Ich finde ihren Problemlösungsansatz interessant, und dass sie einem die Erstellung einer Lösungsarchitektur so einfach machen, ist von großem Nutzen. Man bekommt ein kompliziertes Setup sehr schnell zum Laufen – Messaging, Warteschlangen, dynamische Infrastruktur, automatische Skalierung, was immer du willst. Alle Cloud-Anbieter bringen dich ans Ziel, es steht aber jeweils eine etwas andere Philosophie dahinter. Es gibt kein Patentrezept, man muss den für die Problemstellung am besten geeigneten Anbieter finden. Es ist nicht mehr die Frage, ob die Cloud primäres Ziel für die Entwicklung und das Hosting von Lösungen wird, das ist nur noch eine Frage der Zeit.
Was wir tun müssen, ist, uns darauf einzustellen, dass wir bei der Entwicklung von Lösungen die beste Wahl treffen. Alle Anbieter setzen auf den Lock-in-Effekt – wenn du einmal drin bist, kommst du wahrscheinlich nie wieder raus und kannst auch nicht ohne Weiteres zu einem anderen Anbieter wechseln. Man darf auch nicht vergessen, dass die Cloud sogar teurer sein kann als Inhouse-Lösungen – man muss sie schon richtig nutzen, damit sich das Geld lohnt.
Andererseits glaube ich, dass die KI in Zukunft immer mehr Anwendung findet. Die Frage ist, wie die Bildungseinrichtungen auf diese Veränderungen reagieren werden, denn man braucht hierfür Leute mit ganz anderen Kompetenzprofilen. Man braucht Leute mit einem Talent für das Verstehen von Daten ebenso wie für das Programmieren. Der Bereich wird in Zukunft noch stärker in den Vordergrund rücken. Der Personalmangel ist schon jetzt an den Stellenanzeigen abzulesen und an den angebotenen Gehältern.
Ich beobachte, dass Berufseinsteiger tendenziell zu wenig Interesse an beruflicher Weiterbildung zeigt. Sie tun oft nur das Nötigste und betrachten alles andere als Überstunden oder als „optional“, statt als Chance. Ich kann nur nochmal betonen, dass man nur an Aufgaben wächst, die außerhalb der Komfortzone liegen: Erledige deine Aufgabe, dann denk darüber nach, wie du sie hättest besser machen können, und dann mache sie besser. Wer so vorgeht, tut sich hervor und wird mit der Zeit als Entwickler besser. Und man tut das nicht dem Arbeitgeber zuliebe, sondern im eigenen Interesse.
Man braucht aber auch eine Umgebung, in der man sich weiterentwickeln und neue Dinge ausprobieren kann. Mein Rat ist: Wenn du dich weiterentwickeln willst, tu Dinge, die du bisher noch nie getan hast. So lernt das Gehirn, so kommst du voran.
Was auch wichtig ist und neben den fachlichen Fähigkeiten oft vergessen wird, ist der Aufbau von Soft Skills – was nützen einem die tollsten Fachkenntnisse, wenn man als Teamplayer nicht funktioniert? Viel Zeit wird in der Teamarbeit damit zugebracht, Revisionen durchzuführen, anderen zu helfen oder sich selbst von anderen helfen zu lassen usw. Das darf man nicht außer Acht lassen, wenn man als Softwareentwickler Karriere machen will.
Wir wollen eine Reihe von Challenges vorbereiten, bei denen Kolleginnen und Kollegen Aufgaben übernehmen, die sie aus ihrer Komfortzone herauslocken sollen.
Hierfür arbeiten mehrere Entwickler an einer Plattform, die durch individuelle Aufgaben oder Gruppenaufgaben zur Eigeninitiative und Weiterbildung anregt. Durch kurze Präsentationen und Teamarbeit ermöglichen wir so das persönliche Weiterkommen und den Erfahrungsaustausch. Das ist nur ein kleiner Teaser; ich möchte noch nicht zu viel verraten. Wichtig ist, dass man durch den Prozess der Lernanstrengung das Gefühl hat, etwas erreicht zu haben.
Ich finde, dass Zühlke der richtige Ort dafür ist, denn die Leute hier geben sich nicht einfach mit dem Status quo zufrieden. Besondere Skills und kontinuierliche Weiterbildung sind immer interessant; der Prozess macht Freude und bietet Bestätigung.
Veljko Zrnic ist .NET Architect und seit Mai 2018 bei Zühlke. Er hat einen B.Sc in Software Engineering. Zu seinen Kernkompetenzen gehören die Entwicklung von .NET-Desktop- und Webanwendungen, die Modellierung von Datenbanken und auch Java-Entwicklung. Er arbeitete hauptsächlich für den Bund, Banken und im Gesundheitswesen. Seine Leidenschaft ist es, effiziente Lösungen mit optimaler User Experience zu liefern.
