Boehrsi.de - Blog

Man lernt nicht aus. Ein Satz den man oft hört und der tatsächlich auch meistens der Wahrheit entspricht. An dieser Stelle möchte ich ein paar Punkte, die ich aus dem letzten Jahr mitgenommen habe, mit euch teilen. Diese betreffen mich dabei meist persönlich und könnten entsprechend nicht auf euch zutreffen, aber ich glaub das eine oder andere ist vielleicht auch allgemein ein häufigeres Problem.
Eine Sache ist für mich das Nein sagen, welches ich gerne zu oft und zu schnell tue. Vor allem wenn von extern Anfragen oder Ideen kommen, egal ob zu konkreten Implementierungen oder aber zu neuen Frameworks, bin ich schnell in einer Abwehrhaltung. Generell bin ich zwar weiterhin der Meinung, dass es besser ist erst Nein zu sagen und später doch noch eine Lösung für ein Problem zu finden, als andersherum, aber hin und wieder sollte man ein paar mehr Gedanken investieren, bevor man vorschnell antwortet. An dieser Schwäche meinerseits versuche ich in 2021 weiter zu arbeiten.

Ich lasse mich gerne von neuen Techniken, Programmiersprachen und Frameworks mitreißen, frei nach dem “neu ist immer besser” Prinzip. Doch wie gut ist das eingesetzte wirklich und ab wann kann ich mir eine Meinung darüber erlauben, ob Framework X auch produktiv von mir eingesetzt werden kann?
Genau diese Frage versuche ich mir seit einiger Zeit direkter zu stellen und eventuelle Hypes zu ignorieren. Erst nach der einen oder anderen darüber geschlafenen Nacht versuche ich mir dann ein Bild zu machen. Klappt natürlich nicht immer, manchmal überkommt es einen und manchmal ist ja auch alles Gold was glänzt.
Meistens hat aber auch neue Technik ihre Nachteile, eine Programmiersprache passt vielleicht einfach nicht zum eigenen Einsatzgebiet und hin und wieder ist der eine zusätzliche Gedanke den man sich mit etwas Abstand macht genau der richtige und führt zu einer guten Entscheidung. Denn zumindest ich persönlich habe für mich gemerkt, dass ich auf diese Art vielleicht etwas länger brauche, um die Basis meiner Projekte zu finden, aber dafür ist sie solide und auf Wissen aufgebaut und nicht auf Hype und coolen Animationen.
Damit will ich übrigens nicht sagen, dass man sich nicht mehr für Dinge begeistern darf oder soll, aber es ist halt etwas anderes einen kleinen 2-3 Stunden Test mit etwas Neuem durchzuführen oder ein Projekt über Monate damit aufbauen zu müssen. Insofern versuche ich mir die Freude über gute Software und das sich produktiv fühlen zu erhalten, aber nachgelagert eine Priese differenzierte Gedanken darüber zu streuen.
Wie geht es euch in diesem Bereich, lasst ihr euch vielleicht manchmal auch etwas zu schnell mitreißen, wenn es darum geht den neuen heißen Scheiß zu nutzen?

Software kann in sehr unterschiedlichen qualitativen Zuständen sein. Manchmal startet man bei Null und kann alles frisch und gut entwickeln, mal übernimmt man eine betagte Legacy Software und manchmal findet man eine gut dokumentierte und gepflegte Software zum weiterentwickeln vor.
Sowohl in privaten, wie auch in professionellen oder Open Source Projekten findet man diese verschiedenen Typen und diverse Abstufungen von selbigen, zum guten und zum schlechten. Ich war bis dato meist an frischen Projekten beteiligt, wo ich die Architektur mit definierte und die Konzepte tiefgehend Verstand. Bereits laufende Projekte betreute ich ebenfalls, meist aber nicht extrem tiefgehend oder aber die Projekte waren durchaus gut strukturiert und verständlich.
Mit diesen Ansätzen und den entsprechenden Aufgaben konnte ich gut umgehen, doch aktuell stehe vor einer neuen Herausforderung, die meiner Meinung nach eine Erwähnung wert ist. Denn als Entwickler wird man über selbige früher oder später stolpern und man sollte auch mit dieser umgehen können.
Es geht um Software die gewachsen ist, über lange Zeit und vielleicht nicht die Liebe und Zuneigung erfahren hat die sie sollte. Software die einen manchmal mit der Stirn runzeln lässt und manchmal möchte man das Keyboard liebevoll in viele kleine Teile zerschmettern.

Als Softwareentwickler hat man viele Wege um ans Ziel zu kommen und auch die Art und Weise wie man selbige Wege beschreitet ist vielschichtig. Ich persönlich bin ein Freund davon erst einen Plan zu machen und selbigen später auszuführen. Anpassungen an selbigem sind natürlich an der Tagesordnung, aber blind drauflos programmieren ist nicht so mein Fall. Dies gilt vor allem wenn ich an größeren und komplexeren Projekte arbeite. Denn in selbigen ergeben sich bei spontanen Änderungen gerne Seiteneffekte, welche bekanntlich ungern gesehen sind.
Doch so schön es ist diese Idee für den generellen Ablauf zu haben, manchmal sollte man sich daran erinnern die eigenen Ansätze auch konsequent zu verflogen. Denn sind wir nicht alle manchmal wie eine Feder im Wind? Vor allem wenn es darum geht etwas Neues zu machen, vielleicht sogar in einer neuen Sprache, mit einem neuen Framework oder etwas anderes motivierendes steht an. So passierte es mir beim Umbau / Ausbau einer alten Library aus einem Projekt und damit verbunden der Umstellung von Java auf Kotlin.

Dokumentationen sind wichtig und man sollte sie vor allem in professionellen Projekten mit größeren Teams sehr gut pflegen. Diesen oder einen ähnlichen Satz hört man als Entwickler häufiger und das mit Recht. Denn wie soll jemand neues Wissen wie ein Tool funktioniert oder wie man einen Release Build der App anstößt ohne etwas Dokumentation.
Also auch wenn Dokumentationen schreiben vielleicht nicht die dankbarste Aufgabe ist, in diesem Bereich der Softwareentwicklung ist ein gewisses Bewusstsein für derartige Dinge vorhanden.
Doch wie sieht es mit privaten Projekten aus, die man nebenbei baut und vielleicht als Prototyp liegen lässt? Hier gibt es meistens keine Dokumentation, keine weiteren Hilfen oder ähnliches. Dabei ist es egal ob das kleine Projekt ein Prototyp bleibt oder ob etwas aktiv Genutztes draus wird.

Es ist lange her das ich etwas auf meinem Youtube Kanal hochgeladen habe, aber es wurde mal wieder Zeit. Denn ich zocke bekanntlich mit einigen Freunden diverse Spiele und darunter auch Rainbow Six Siege. Hier sind wir als Team schon einige Jahre dabei, wenn auch nur Just for Fun.
In diesem Rahmen habe ich ein kleines Community Video erstellt, welches nun auf Youtube verfügbar ist. Ihr findet es direkt in dieser News, im unteren Teil oder aber über die Related Links. Es ist kein extrem umfangreiches Editing vorgenommen worden, allerdings wurde schon etwas Aufwand in Timing und Schnitt gesteckt, insofern hoffe ich es gefällt.

• Boehrsi.de Community plays Rainbow Six Siege #1 open_in_new

Ein LAN-Wochenende liegt hinter mir, ein Event welches viele vielleicht für überflüssig halten, in Zeit von Gigabit Internet und Voice Servern, aber ich bin da absolut anderer Meinung. Vor allem für erwachsene Spieler, die sich um ihr Leben, ihre Arbeit, die Familie und all die anderen Dinge kümmern müssen, ist dies die Chance ein Wochenende lang wieder Kind zu sein. Wichtig ist dabei vor allem das Miteinander in der Gruppe, obgleich natürlich auch gezockt wird.
Aus diesem Grund versuchen wir einmal im Jahr eine kleine LAN unter Freunden zu veranstalten. Dort zocken wir unsere aktuellen Favoriten, neue kleine Fun-Games und natürlich die Klassiker. Es wird alles bunt gemischt, garniert mit sehr viel Trash-Talk und ungesundem Essen und vielleicht dem einen oder anderen Bier, schon hat man eine perfekte Mischung.
Es ist die Chance den Alltag für ein Wochenende zu den Akten zu legen, unkompliziert Spaß zu haben und dabei ordentlich zu zocken. Mal gewinnt man, mal verliert man, aber lachen kann man immer. Man merkt allerdings auch dass die benötigte Regenerationszeit nach einer LAN immer länger wird und ohne einen freien Montag bei mir wenig geht.
In diesem Kontext kann ich jedem der das Konzept LAN kennt und mag nur empfehlen derartige Traditionen zu erhalten, sie sind es definitiv wert. Falls ihr euch übrigens fragt was wir gezockt haben: Rainbow Six Siege, Counter Strike GO, Warcraft 3, Command and Conquer, Pummel Party, Escape from Tarkov und Rocket League waren unter anderem dabei.

Über die letzten eineinhalb Jahre habe ich mein erstes professionelles Projekt geleitet und heute möchte ein kleines Fazit ziehen. Vielleicht ist für den einen oder anderen ein hilfreicher Tipp dabei oder vielleicht habt ihr Tipps, wie man in diesem Bereich noch besser werden kann. Über Kommentare freue ich mich wie gewohnt sehr.
Ich bin gerne ein Entwickler, soll heißen ich schreibe wirklich gerne Code, doch auf der anderen Seite koordiniere und plane ich tatsächlich auch recht gerne. Letztes ist glaub ich extrem wichtig wenn es darum geht ein Team und ein Projekt zu leiten. Denn sofern man keine Ambitionen in diesen Bereichen hat, sollte man lieber bei der reinen Entwicklung bleiben. Grund dafür ist die massive Verschiebung der Aufgaben und die entsprechend veränderte Zeitverteilung. Sofern einem dann der Verwaltungsteil gar nicht gefällt, wird man vermutlich schnell unzufrieden sein.
Wie erwähnt finde ich aber durchaus Gefallen daran und war froh mit dem genannten Team arbeiten zu dürfen. In Retrospektive denke ich damit steht und fällt generell alles, also ob das Team allgemein und menschlich funktioniert. Erst darauf kann man dann auf professioneller Ebene etwas aufbauen. Wir hatten das Glück das es passte und mit einer recht guten Wissensverteilung (2x Android, 2x iOS, 1x Testing) konnten wir eine Flutter App entwickeln, welche mit genügend Platform-Background versorgt wurde.

Ich schreibe seit ca. 15 Jahren Software und seit 5 Jahren ist es mein täglicher Vollzeitjob Programme zu entwickeln. In dieser Zeit fallen einem verschiedene Dinge auf und man lernt extrem viel. Vor kurzem wurde ich von einem Kollegen, der gerade den Sprung von der Uni ins Berufsleben vorbereitet, gefragt wie ich Projekte angehe und Entscheidungen in der Starphase treffe. Während ich meine Ansichten und Ideen mit ihm teilte dachte ich mir, dies könnte auch ein gutes Thema für den Blog sein und hier sind wir nun.
Meiner Meinung nach ist der Anfang eines Projekts, noch bevor man überhaupt über die Architektur nachdenkt, einer der wichtigsten Momente. Denn ich denke man sollte ein Projekt initial mit der richtigen Plattform, Technik und Sprache aufziehen. Hier gibt es natürlich Limitierungen bezüglich dem eigenen Wissen oder dem Wissen des Teams, aber man muss z.B. nicht einen Blog, einen Shop, einen Hausbootverleih und eine Dinosaurierzucht mit Wordpress bauen. Natürlich bietet es um drei Ecken die Möglichkeiten, aber ihr nehmt ja wahrscheinlich auch keine Rohrzange, um damit Nägel in die Wände zu kloppen.
Soll heißen, nur weil man etwas tun kann, heißt dies nicht dass es gut oder gar der beste Weg ist. Hier gilt auch über den Tellerrand zu schauen und vielleicht die Chance zu nutzen und etwas Neues lernen. Dabei ist es mir sehr wohl bewusst, dass dies gerade im professionellen Umfeld durchaus kompliziert und nicht immer machbar ist. Doch einige Minuten des Nachdenkens zu investieren und vielleicht Vorschläge für neue und passende Ansätze zu unterbreiten dürfte selten falsch sein.

Im Rahmen der Software-Entwicklung nutzt man oft Libraries, Tooling und andere Dinge die man selbst nicht komplett durchdringt. Dies ist zu bestimmten Teilen auch in Ordnung und an der Tagesordnung, doch manchmal ist eine Software-Blackbox ein extremes Problem.
Doch definieren wir erst einmal Blackbox. Für mich ist eine Blackbox im Software-Bereich eine Komponente, die man selbst nicht durchdringt und die nicht mit akzeptablem Zeitaufwand, aus welchen Gründen auch immer, verstanden werden kann. Gründe sind hier, auch wenn es sich um Open Source Software handelt, andere Programmiersprachen, zu komplexe Konzepte, fehlende Dokumentation oder ähnliches. Closed Source Software ist natürlich per-se eine Blackbox.

Wann ist eine Blackbox aber nun ein Problem? Meiner Meinung nach wenn sie grundlegende Konzept abstrahiert oder zu essentielle Abläufe übernimmt und dem Entwickler dabei nicht klar ist was wann passiert und warum. Nimmt man z.B. das Build-Tool Gradle open_in_new, so hätte man vielleicht eine Blackbox vor Augen. Diese funktioniert allerdings sehr gut, es gibt eine sehr umfangreiche Dokumentation und auch weitere Ressourcen sind vorhanden. Hier muss man also Vorsicht walten lassen bei Updates und ähnlichem, falls man nicht durchdringt was dies bedeuten könnte. Doch durch vorhandene Dokumentation kann man sich entsprechend und mit akzeptablem Zeitaufwand schlau machen. Insofern würde ich persönlich nicht von einer Blackbox reden, wenn es um Gradle geht.
Hat man nun aber ein derartig wichtiges Tool (z.B. für die Build-Toolchain) oder eine Library die grundlegende Funktionen der eigenen Software übernimmt (z.B. Netzwerk-Interaktionen oder die Implementierung von Protokollen) und eine derartige Informationsquelle ist nicht gegeben, kann man sich in große Probleme manövrieren.