Blog
Michael Bykovski
Ich habe innerhalb der 15 Jahre bei klein- und mittelständischen Unternehmen gearbeitet, jedoch hatte ich Kunden die von klein- und mittelständischen Unternehmen bis Konzernen reichen. Dabei habe ich interne Applikationen, Shops, Auswertungs- und Automatisierungs-Applikationen, Microservices, Services, Webapplikationen, Sensor und Mechanik gestützte Software und sonstige Applikationen entwickelt.
Folgende Technologien habe ich produktiv eingesetzt: REST, SOAP, GraphQL, Vue, React, Angular, jQuery, Shopsysteme, Webdesign, Data Science Tools, Ansible, Gitlab (CI), SSH, Kubernetes, Go, Java, PHP, C, Groovy, Python, JavaScript, NodeJS, Firefox, Chrome, Internet Explorer, Symfony, Puppeteer, Selenium, Github, Next.JS, Django, NestJS, numpy, pandas, Python Celery, Clickhouse, Postgres, MariaDB, MongoDB, Kafka, SAFe, Agile, Scrum, Kanban, Tensorflow, Keras und viel viel mehr.
Als Abschluss habe ich einen Master in Informatik und arbeite nebenbei an der Hochschule Rhein-Main als Dozent, wo ich das Fach Webengineering anbiete.
Bei der Umsetzung dieser Applikationen hatte ich während der 15 Jahre mit über 100 Teams und über 500 Menschen zu tun, wobei ich überwiegend positive aber auch negative Erfahrungen sammeln konnte.
Nach den 15 Jahren Softwareentwicklung gibt es in meinem Beruf immer wieder neue Herausforderungen, denen ich noch nicht gewachsen bin. Sicherlich gibt es viele Dinge, die ich im Handumdrehen implementieren kann, wofür viele andere Entwickler und Entwicklerinnen Wochen bräuchten. Doch, je mehr ich sehe und je mehr Erfahrung ich sammle, desto mehr verstehe ich, dass es verschiedene Blickwinkel, Ebenen und Schwierigkeitsgrade gibt, die man einfach noch nicht erkundet hat.
Der Fakt ist der, dass man als erfahrener Entwickler oder Entwicklerin Respekt vor der Sache und seinen Kolleginnen und Kollegen behalten sollte. Professionalität zeichnet sich dadurch aus, dass selbst triviale Probleme nicht unterschätzt werden sollten und Raum für andere Entwickler und Entwicklerinnen eingeräumt werden muss, damit diese auch die gleiche Erfahrung genießen können.
Das ist ein leidiges Thema, wo ich fairerweise sagen muss, dass ich in der Vergangenheit auch nicht so konsequent war.
Mittlerweile schreibe ich, zumindest im Backend immer Tests. Unit-Tests sind ein Muss und für jeden Endpunkt gibt es mindestens einen Integration-Test, der zumindest den „Happy Path“ testet.
Die Ausrede: „Wir haben keine Zeit dafür“ gilt hier nicht. Du musst dich eher fragen: „Wenn wir das jetzt nicht machen, werden wir dafür Zeit in der Zukunft haben und vor allem, werden wir Zeit für die ganzen Bugs haben, die dadurch entstehen werden?“
Die Antwort ist ganz klar: Nein. Daher investiert die Zeit, ein gutes Testsetup zu implementieren, das ist heutzutage viel einfacher und gängiger als noch vor 10 Jahren. Tut es!
In der Welt der Softwareentwicklung treten Softwareentwicklungsteams sehr häufig auf. Es passiert recht selten, dass eine Softwareentwicklerin oder ein Softwareentwickler den ganzen Laden schmeißt.
In den letzten 15 Jahren habe ich gelernt, dass die Verteilung von Verantwortung innerhalb eines Teams dazu führt, dass das Team versucht an einem Strang zu ziehen. Dadurch entsteht eine drei Musketiere Attitüde: „Einer für alle, alle für einen“.
Fatal ist es, wenn es eine Person im Team gibt, die für 90% des Codes verantwortlich und der Rest immer darauf angewiesen ist. Allein aus wirtschaftlicher Sicht ist das zu risikobehaftet und man sollte dafür sorgen, dass sich die Verantwortung auf alle Mitglieder verteilt.
Aus meiner Sicht kann ich nur sagen, dass es für einen Softwareentwickler viel angenehmer ist, in einem Team zu arbeiten, in dem sich alle aufeinander verlassen können. Wo auch selbst bei Fluktuation nicht die Angst besteht, dass danach nichts mehr läuft, sondern die Verantwortung einfach neu verteilt werden musst.
Das war mal in einer E-Mail Signatur einer meiner hoch geschätzten Professoren – und wie recht er damit hatte.
Während meiner Studienzeit gab es extrem viele Buzzwords und viele Softwareentwicklerinnen und Softwareentwickler, darunter ich auch, vielen darauf rein. React, Vue, Angular war zu der Zeit (2013-2018) groß im kommen und viele versuchten sich darin. Jedoch wäre es damals viel schlauer gewesen JavaScript an sich zu lernen, die Probleme und den Nutzen zu verstehen und anschließend zu Libraries und Frameworks zu gehen.
Genauso auch Erscheinungen wie „Blockchains“ sind nichts anderes als verkettete Listen, die durch das Hashing eine schwer veränderbare verkettete Liste darstellen. Kafka kann das auch, sogar fast schon besser und effizienter.
Versucht daher nicht in Frameworks, Libraries und Applikationen zu denken, denkt in Konzepten, Problemstellungen und formalen Lösungen. Dann werdet ihr die Facetten von aufgeblähten Systemen erkennen und diese eventuell durch schlanke und kluge Systeme ersetzen können.
Dependency Injection ist mein Freund. Lange kannte ich DI (Dependency Injection) und habe es abgetan als einen lästigen Zusatz in diversen Frameworks. Mittlerweile baue ich keine Backend-Applikation mehr ohne DI.
Die Möglichkeit den Code durch DI lose zu koppeln, ein Interface als Dependency in einer Klasse zu erwarten, aber eine beliebige Implementierung dieses Interfaces hinein zu geben, macht die Software zur „Soft“Ware: Einfach änderbar.
Mittlerweile entwickle ich für jedes Interface, was ich als Dependency irgendwo reingebe eine konkrete Implementierung und eine Fake-Implementierung, einfach um jedes einzelne Modul in meiner Applikation faken zu können und so einfacher zu testen – manuell oder automatisiert.
Kompliziert ist eine Armbanduhr. Man kann sie planen, zeichnen, messen, fühlen und sich konkret vorstellen. Wenn ich eine Uhr geplant habe, kann ich sie immer wieder bauen und jede weitere Uhr wird gleich sein.
Komplexität ist nicht planbar, schwer zu erklären, schwer vorstellbar und von Fall zu Fall unterschiedlich. Komplexität ist das, was passiert, wenn Menschen ins Spiel kommen.
Sobald ich mit Menschen zusammenarbeite und etwas plane, befinden wir uns in einer komplexen Welt, mit Gefühlen, Hierarchien, Kulturen und weiteres.
Sobald ich mit Software arbeite, befinden wir uns in der komplizierten Welt. Software ist klar definiert, es gibt Code und die Software macht genau das, was der Code sagt und nichts anderes. Durchaus gibt es auch unerwartete Effekte, die außen auf die Software einwirken, aber die Software selbst ist kompliziert.
Nun bauen wir ja keine Software für Software, sondern Software für Menschen. Daher müssen wir bei dem Übergang von der komplexen Welt in die komplizierte jonglieren, genauso wie zurück. Und das ist die Kunst einer Softwareentwicklerin und eines Softwareentwicklers das gut hinzukriegen.
Die Frage, wie kriegt man das nun hin, kann ich leider schwer beantworten. Ich würde sagen, es ist eine Mischung aus Erfahrung, Offenheit, Ehrlichkeit, Geduld, Disziplin und das Streben nach Gutem.
Dabei hat mich sogar erst letztens ein guter Freund ertappt. Manchmal drückt man sich vor einem komplizierten bis komplexen Problem, indem man auf die Recherche geht und schaut, ob das Problem schon vor einem gelöst wurde.
Nichtsdestotrotz dürfen wir aber nicht vergessen, dass es nur ganz selten die eine Lösung für ein Problem gibt. Manchmal macht auch eine Recherche Sinn, vor allem, um zu schauen, ob es schon eine Best-Practice Lösung für ein Problem gibt, jedoch ist die beste Art damit umzugehen ein tatsächliches Hands-On, denn es geht schließlich am Ende darum Code in einer Datei stehen zu haben.
Innerhalb eines Projektes gibt es viele Meetings, Diskussionen, Ideen und Entscheidungen. Sensibilisiert eure Projektmitglieder und Stakeholder dahingehend, dass jede Entscheidung und Idee auf die Goldwaage gelegt und ernst genommen wird. Wenn die Stakeholderin sagt: „Das Feature XY müsste man mal verbessern“, dann erstellt direkt mit ihr zusammen ein Ticket im Ticketsystem, schätzt es und versucht es in den nächsten Sprint einzuplanen.
So wird der Mehrwert eurer Arbeit deutlich, da nun für jede Änderung die Sichtbarkeit und Nachvollziehbarkeit eurer Arbeit gesehen wird. Macht auf gar keinen Fall irgendwelche Ad-Hoc Änderungen, ohne das in irgendeiner Weise sichtbar zu machen.
Das schließt etwas an den Punkt 8 an. Disziplin ist das A und O in der Softwareentwicklung. Ob man diszipliniert ist und stetig Tests schreibt oder für jede Idee/Entscheidung ein Ticket erstellt oder immer den Code besser verlässt, als man ihn vorgefunden hat – durch Disziplin bleibt man am Ball.
Der Vorteil von Disziplin ist es, berechenbarer im Softwareteam zu werden. Wenn jedes Teammitglied seiner eigenen Disziplin folgt (positive Disziplin vorausgesetzt) erleichtert es den Umgang miteinander, da nun Kommunikation und Verhalten mehr vorhersagbarer werden (Stichwort Komplexität).
Am Anfang meiner Karriere als Jungspund habe ich gedacht, dass mein Code niemanden etwas angeht. Was für ein Irrtum das wohl war…
Wie soll man als Softwareentwickler oder Softwareentwicklerin besser werden, wenn der Code nicht geteilt, diskutiert und verbessert wird? Das ist doch letztendlich das, was Open Source Software auch ausmacht. Darauf bauen fast alle Systeme heutzutage auf (Linux, Nginx etc.), nämlich das Code niemanden gehört und jeder darin so lang herumschrauben darf, bis das beste Ergebnis herauskommt.
Schlussendlich geht es ja auch darum dem Kunden ein Produkt zu bieten. Und wenn ihr euch in ein Auto setzt, wollt ihr auch, dass alles getestet ist und das Lenkrad nicht mal eben abfällt. Genauso sollten wir Software betrachten.
Disziplin ist gut, sie birgt eine gewisse Vorhersagbarkeit des Verhaltens und der Kommunikation. Nichtsdestotrotz bin ich der Meinung, das ohne Mut und Risiko kein Treiber für Innovationen entsteht. Manchmal ist es auch wichtig, neue Ideen zu wagen und Risiken einzugehen.
An der Börse sagt man sich: „Je höher das Risiko, desto höher der Gewinn“ und so ist es auch in der echten Welt. Sicherlich ist es auch Erfahrungssache, welche Risiken man lieber eingehen sollte und welche nicht, doch möchte man vorankommen, muss man welche eingehen – ganz klar.
Es gibt viele Dinge im Leben, die einen stören oder die man hasst. Damit diese negative Emotion nicht auf das Gemüt schlägt, habt ihr drei Optionen.
Fangt an die Sache zu lieben, findet etwas, wo ihr gefallen daran habt.
Fangt an der Sache aus dem Weg zu gehen, macht stattdessen was anderes.
Fang an die Sache zu ändern, sodass ihr es lieben oder verlassen könnt.
Das gute alte Pfadfinderregel gilt nicht nur für deine Umwelt, sondern auch für deinen Code. Versuche stetig den Code sauberer zu verlassen, als du ihn vorgefunden hast. Dies auch wieder mit einer gewissen Disziplin angehen.
Das ist für dich gut, weil du dich immer weiter verbessern wirst und für dein Team, weil du dich verbesserst und der Code einfacher lesbarer wird.
Als ich damals immer mehr die Softwareentwicklung entdeckte, dachte ich, dass ich immer in einem stillen Kämmerchen hocken und an Code rumbasteln werde. Softwareentwicklung ist aber viel mehr als das, es ist: Gestalten, Mitdenken, Verantwortung übernehmen, Disziplin bewahren, mit Menschen umgehen, Emotionen verarbeiten, komplizierte Probleme verstehen, in einem komplexen Umfeld zurechtzukommen, mit der aktuellsten Technik mitzuhalten, zu diskutieren und argumentieren, seine Probleme verständlich erklären und präsentieren, die Wahrheit sagen und vieles vieles mehr.
Das ist etwas, was ich meinen Studenten und allen weiteren Personen sage, die sich in die Softwareentwicklung wagen. Komplexität hin oder her, schlussendlich geht es darum Code in einer Datei abzuspeichern und auszuführen. Und wenn das nicht sitzt, wie soll man dann die ganzen anderen Probleme in der komplexen Welt bewältigt werden?
In meiner Laufbahn saß ich fast täglich am Computer und habe programmiert. Natürlich las diverse Bücher und Blogbeiträge, nahm an Konferenzen teil, schaute Youtube Videos, aber das alles hat mich noch lange nicht so weit gebracht, wie tatsächlich Software programmieren.
Wenn ihr bis hierhin gekommen seid, dann bedanke ich mich erst einmal bei allen, die mir auf meinem Weg zu Seite standen und mit mir großartige Projekte umgesetzt haben.
