Oliver Schneider, Softwareentwickler im Raum Bonn/Köln und in Zeiten von Home-Office auch überall

image

Normalerweise heißt der Raum ja Köln/Bonn, für meinen Job heißt er Bonn/Köln. Aber seit dem bösen C hat sich die Arbeitswelt ja plötzlich flexibilisiert. Durch mein Informatikstudium an der FH Rhein-Sieg und durch vielfältige Tätigkeiten als Softwareentwickler bin ich zu einem Experten herangereift. Ob hausteschnische Software in C++ oder mobile Software in C++ und Java für Android oder fürs Web mit PHP, Java und Python, ich habe alles erfolgreich gemacht. Vollbepackt mit Erfolg bringenden Prinzipien und Best Practices suche ich mir das passende Werkzeug für den jeweiligen Einsatzzweck aus. Ich bin stets zu interessanten Problemen verpflichtet. Trotz aller breiten Aufstellung habe ich mittlerweile in folgenden Programmiersprachen mindestens 4 Jahre professionelle und solide Berufserfahrung: Python, Java und C++. Fürs Web habe ich die meiste Zeit entwickelt. Es ist einfach die Plattform, die am effizientesten eingesetzt werden kann. Daneben habe ich für den Windows-Desktop und für Android entwickelt. Hobby- bzw Lernprojekte habe ich begonnen auf github zu veröffentlichen Hier mein Profil auf github Nachfolgend meine beruflichen Stationen im Einzelnen und mein theoretischer Hintergrund.

Professionelle Erfahrung als Softwareentwickler

6. Station: Entwickler eines ERP-Systems basierend auf Odoo in Python in Köln

Der mit Abstand beste Job bis jetzt. Alles passt. Ich kann alle meine erworbenen Fähigkeiten einsetzen und sehr eigenständig arbeiten. Und, oh Wunder, sobald man eigenverantwortlich und selbstorganisiert arbeiten kann, klappt es auch. Mit großem Erfolg habe ich als einzelner Softwareentwickler die Prozesse eines mittelständischen Unternehmens in der Bildungsbranche und ein zu portierendes System, das als Office-Lösung programmiert war, analysiert und in Odoo, ein in Python geschriebenes Open Source-System abgebildet. Alle Informationen waren vorhanden und daher war auch alles sehr transparent. Ich habe direkt mit den Kunden gesprochen und agil in Iterationen entwickelt. Beginnn jeder Iteration war ein Meeting, sei es physisch oder per Zoom (Was tut mein beim gemeinsamen Planen und Feedback sammeln anderes als die Oberfläche bedienen und zusammen reden? Alles problemlos remote möglich. Sowieso gab es verschiedene Standorte und ich kann nicht jede Woche nach Berlin reisen. Bzw. wofür?) Entwickelt wurde testgetrieben (TDD). Endlich qualitativ hochwertiger Code. Wenn ich von einer Odoo-Version auf die nächste umgestiegen bin oder ein neues geschäftskritisches Feature entwickelt habe, lies ich die Tests laufen und wusste sofort, ob alle zugesagten Funktionen noch vorhanden und fehlerfrei waren. Wie immer gibt es auch Nachteile: Ich bin mit meinem Vorgesetzten Digital-Pionier und damit relativer Einzelkämpfer. Auf Dauer ist das anstrengend und ich würde mir ein fortschrittlicheres Umfeld und mehr von Meinesgleichen wünschen.

5. Station: Java EE-Entwickler für die Pharmaindustrie in Bonn

Technologisch und fachlich war hier ebenfalls richtig was los. Ich habe einen alten Shop, der noch in JSP geschrieben war, übernommen und gewartet. Ich habe eine Stammdatenbank mit Oberfläche, die nicht richtig bzw. von Azubis kaputtprogrammiert wurde, basierend auf moderneren Frameworks wie JSF und JPA, repariert und ihr zu Produktionsreife verholfen. Ich habe mitgeholfen, einen neuen Webshop für die angeschlossenen tausenden Apotheken zu entwickeln. Und ich habe Automaten programmiert und rationalisiert, die vereinheitlicht Bestellungen für die unterschiedlichen Pharma-Hersteller entgegennahmen und weiterleiteten. Eclipse als IDE muss aber zukünftig nicht mehr sein. Ich würde heute NetBeans verwenden oder mir IntelliJ wünschen. Die kleine Ausgabe lohnt sich.

4. Station: Android-Entwickler für eine Navigations-App in Bonn

Ich glaube, heute hat Google Maps die meisten Navigations-Apps in den Ruhestand versetzt. Meine Kollegen gibt es bei dem Arbeitgeber nicht mehr. Nicht jede App ist sinnvoll und nützlich. Für mich war der Wechsel dennoch gut, so wie jeder Wechsel bisher. Denn mit jedem Job wachsen die Fähigkeiten und Kenntnisse und man ist die Summe der Einflüsse, denen man ausgesetzt war. Hier war meine Aufgabe, eine Android-App zu entwickeln, die auch eine Oberfläche für einen C++-Navigationskern war. Der C++-Kern wurde noch in anderen Produkten verwendet, nämlich in einer iOS-App, einer Windows CE-App und einer Web-App. Und da es auch für diese Codebasis keine Unit-Tests gab, dauerte es immer recht lang, ein Feature zu entwickelt, da immer manuell gestet werden musste, ob der Code für alle Plattformen noch läuft. Ein weiteres Indiz: Automatisierte Tests sind absolut notwendig! Die Kunden wurden ungeduldig bei so einer zähen Entwicklung

3. Station: Haustechnische Software für Windows-Clients in C++ in Bonn

Eine Aufgabe war die Überarbeitung aller Dialoge mit einem hauseigenen Framework. Kollegen wunderten sich, welche versteckten Funktionen ich hervorzauberte. Ich realisierte weiterhin initial ein neues Gewerk Elektroinstallation, so dass das Unternehmen auf Messen etwas in dieser noch neuen Richtung vorzeigen konnte und die Interessierten grafisch planen und ausprobieren konnten. Eine weitere Aufgabe war die Erstellung einer Oberfläche für Projektarbeit - mehrere Benutzer konnten kolaborieren.

C++ - das war damals eigentlich schon oldschool. Jedenfalls zum Entwickeln von Planungssoftware für Windows-Clients. Aber eigentlich ist es ein guter Einstieg ins Entwicklerleben, denn bei C++ muss man sich um Vieles selber kümmern und wenn man in C++ sicher ist, kann man jede Sprache schnell lernen. Damals gab es schon länger .NET. Deshalb startete der Entwicklungsleiter auch einen Neuanfang. Aber nur er. Für alle anderen war .NET tabu. Und deswegen hatte er auch so wenig Zeit für seine Entwickler. Aber ein Entwicklungsleiter, der selbst nur programmiert und dem ständig “Lass mich bloß in Ruhe” ins Gesicht geschrieben steht, ist für jemanden, der immer noch am Anfang seiner Karriere steht, nicht förderlich. Aber mein Kommunikationsstil war auch nicht gut. Heute schreibe ich hauptsächlich wichtige Dinge als Email. Als erstes hat man schwarz auf weiß, was man kommuniziert hat und dann muss der Adressat nicht sofort antworten und kann in Ruhe darüber nachenken und die Antwort fällt zufriedenstellender aus, da sie tiefer und umfangreicher ist. Was hilft es mir, wenn ich gerade einen Gedankenfetzen aus dem Rückenmark bekomme? Auch da wäre ich heute kreativer. Es gibt ja auch andere Leute im Unternehmen. Marketing, Sales, … Es gab sogar noch einen anderen Projektleiter, der nicht programmierte. Das sind immer die besten fachlichen Informationsquellen.

Das A und das O für erfolgreiche Entwicklungsarbeit ist die Kommunikation. Das andere ist technischerseits eine gute Quellcodebasis. Ein Maß für Qualität ist die Testbarkeit. Man muss erst mal testen können. Dafür muss Code lose gekoppelt sein, so dasa man sich Teile herauspicken und testen kann. Hier war alles mit allem verbunden. Es gab an die 100 DLLs und es gab zirkuläre Abhängigkeiten. Wir hatten es einmal visualisiert. Es war ein undurchdringliches Knäuel. Ableiten von anderen Klassen war cool. Nicht selten waren es 10 Hierarchiestufen. Das Design-Pattern Aggregation over Interitance galt hier nicht und war auch unerwünscht. Ein Test, der 4 Minuten dauert, weil erst mal die ganze Anwendung hochgerissen werden muss, ist sinnlos. Ich erinnere mich, wie frustriert ich war, als ich mehrere Stunden brauchte, um einen Reset-Button in einen Dialog einzubauen. Alles durchkompompilieren dauerte eine Mittagspause.

Ich hatte wieder einen Zimmerkollegen, der ständig privat programmierte. Das animierte mich und ich probierte Verschiedenes in .NET aus, aber auch in Java. Ich überlegte mir, was für mich als nächstes nach C++ kommt. Ein anderer Kollege war mit mir auf einer Wellenlänge und wir fachsimpelten viel über Clean Code und TDD (Test Driven Development) und wie wir das in dieser schwierigen Umgebung realisieren könnten.

Eine Lektion aus dieser Station: Lieber schneller den Job wechseln und nicht so lange zögern. Wenn es nicht passt, passt es nicht.

2. Station: PHP-Webentwiklcer für einen Dienstleister in Bonn

Die Kunden waren öffentliche Auftraggeber. Wir entwickelten eine Sprachtestsoftware in PHP. Eine andere Aufgabe war die Fertigentwicklung einer Bestellungssoftware für die Bundeswehr, ebenfalls in PHP. Wir hatten ein hausinternes Framework. Damals war man noch der Meinung, dass man ein Framework besser selbst entwickelt. Da denkt man heute anders und heute gibt es für PHP ja Web-Frameworks wie Sand am Meer. Mein Zimmerkollege hat mich positiv beeinflusst. Er sagte mal: “Was produzierst du denn für einen Spaghetticode?” Das habe ich mir zu Herzen genommen. Ich achte heute sehr auf lesbaren und wartbaren Code, der lose gekoppelt ist, so dass ein Codeabschnitt eine Einheit ist, die möglichst nur einmal vorkommt. Dieser Kollege hat mich auch angesteckt, zu programmieren. Er hat ein Spieleframework programmiert. Das fand ich immer zu ambitioniert. Aber auf jeden Fall hat mich das befruchtet. Man lernt am allermeisten, wenn man sich selbst Ziele steckt. Von außen kleinere Programmierarbeiten annehmen bedeutet als Junior-Programmierer leider oft, dass man das größere Ganze nicht kennt, sei es technisch oder auch fachlich. Auf jeden Fall lernt man, die Dinge zu hinterfragen und an Informationen zu kommen. Ein anderer Kollege hat immer gelesen. Ein sehr guter Tipp von ihm: Immer eine Seite mit wichtigem Lernstoff im Browser offen haben!

1. Station: Programmierung eines Webshops und Vertrieb von Netzwerkfestplatten in Bonn

Ja, ich habe den Shop selbst in PHP programmiert. Ich wollte ja schließlich programmieren lernen. Ja, auch das würde man heute mit einem Shop-Framework erledigen. Aber irgendwie muss man sich die Basics beibringen, die man immer im Hintergrund wissen muss.

Bücher, die ich für den jeweiligen Job gelesen habe

Das waren größtenteils Bücher über die jeweils genutzte Programmiersprache. Das direkt benutzte Werkzeug muss ich schon genau kennen und alle Arbeitserleichterungen und damit Produktivitätsschübe mitzunehmen. Oft versteht man dann auch Frameworks und Bibliotheken besser, die die Eigenheiten der Sprachen ausnutzen.

Fluent Python

Ein sehr gutes Buch. Bedenkt man, dass es sich um kein Syntax-Buch handelt - solche Büche lese ich nicht, dafür gibt es datenschutzfreundliche Suchmaschinen wie StartPage oder DuckDuckGo - und das Buch fast 800 Seiten hat, wirft das ein gutes Licht auf die Programmiersprache Python. Denn dann muss die Sprache schon einiges zu bieten haben. Andererseits wird die Ausführlichkeit des Buches genutzt, um Python sehr verständlich und unterhaltsam zu erklären. Alles ist mit aussagekräftigem Code sehr anschaulich und mit guten Beispielen erklärt. Das Buch löste Probleme, die ich im Alltag hatte auf sehr knappe und pythonische Art und seit ich das Buch gelesen hatte, konnte ich mit mehr Freude und weniger sich wiederholendem Code programmieren.

Der ERP-Kompass

Noch nicht zu Ende gelesen. Der Autor spricht sich sehr klar gegen Individualprogrammierung aus, was ich nicht teilen kann. Dennoch waren ein paar sehr gute Tips dabei. Allerdings nicht direkt für mich, da ich ja Programmierer bin. Ich habe die Tips an die fachliche Seiter weitergegeben.

Getting Clojure

Clojure ist mein neues Hobby. Es ist die erste Programmiersprache, die ich nur indirekt für den Job lerne. Denn wo entwickelt man in Clojure? Gut, Robert C. Martin empfiehlt Clojure als das neue C und so sollte die Sprache unter Clean Code-Anhängern populär sein bzw. werden. Aber man sagt auch, dass man zum besseren Programmierer wird, wenn man mit Clojure experimentiert. Und dann ist Clojure als funktionale Programmiersprache für mich etwas Neues. Und so langsam muss ich mich fragen: Wie will ich eigentlich programmieren? Programmiererfahrung in C++, Java und Python als gängige Programmiersprachen habe ich genug gesammelt. Jetzt darf es auch exotischer werden. Sowieso ist es nicht gut, der Herde hinterher zu laufen. Bisher habe ich die Basiskapitel gelesen und danach erstmal etwas programmiert. Die Basics habe ich drauf und ich will erst weitere Programmiererfahrung sammeln, bevor ich weiterlese, denn dann gibt es mehr Aha-Erlebnisse.

Effective C++

C++ ist ja als sehr komplexe Programmiersprache bekannt und C++-Code kann schon sehr kompliziert werden. Um sich hier nicht selbst in den Fuß zu schießen, braucht es gute Grundlagen. C++ ist nicht Python, wo man sehr einfach anfangen kann und die Sprache Anfängerfehler verzeiht. Hier muss man schon genau wissen, was man tut. Das Buch ist aber sehr angenehm kurz. Es vermittelt die wirklich wichtigen Dinge, die man wissen muss. Im Gegensatz zur Referenz des Schöpfers von C++, der arg in die Tiefe geht und viel über die Hintergrunde theoretisiert. Das Buch hat mir sehr weitergeholfen, alle Fallstricke zu umgehen und C++ eben effektiv anzuwenden.

Effective Java

Ein Buch, von dem ich nur die ersten Kapitel gelesen habe. Das liegt daran, dass ich als Java-Entwickler leider nicht so sehr mit der Sprache an sich zu tun hatte und das Buch nicht wirklich die Basics behandelt. Für meinen Job musste ich nicht wirklich in die Tiefe gehen, da Frameworks wie Android oder JSF oder JPA mir die Arbeit abgenommen und viele Probleme erschlagen haben.

Bücher, die mich geprägt haben

Nicht, dass ich nicht ständig lesen würde. Heute ist ja jeder Lernstoff in reichlichen Mengen und kostenlos im Internet vorhanden und Lesen macht einen guten Teil des Lebens eines Softwareentwicklers aus. Aber das lineare Lesen bietet unbestreitbar Vorteile. Man kann sich auf ein Thema konzentrieren, man hat mehr Ruhe, weil man nicht ständig durch Hyperlinks dazu angeregt wird, hin und her zu springen. Und die Wissenschaft weiß: Man lernt besser mit Papier. Und es ist auch gemütlicher und komfortabler.

The C Programming Language von Kernighan und Ritchie

Habe ich gelesen oder eher durchgearbeitet, als ich ein Jahr an der Uni Bonn Informatik studierte, bevor ich zur FH Rhein-Sieg gewechselt bin. C ist die Mutter aller Sprachen und wenn man C kennt, weiß man, was im Hintergrund abläuft, wenn man in höheren Sprachen wie Java oder Python programmiert. Man ist dankbar, dass man sich nicht um alles kümmern muss und nimmt die Hilfen von höheren Sprachen gerne in Anspruch. Mein weiß, dass Speicherverwaltung etwas kostet. Es ist schon wichtig, dass man mal einige Sortieralgorithmen von Hand programmiert hat, damit man Vor- und Nachteile der Algorithmen kennt und ein Gefühl dafür bekommt, was abläuft, wenn man in höheren Sprachen sort(Collection) aufruft. Und schließlich ist C immer noch die Grundlage für C++, meine Einsteigersprache.

Vom Problem zum Programm

Bis heute begeistert mich die Idee. In den Buch geht es darum, dass Problem genauestens zu verstehen und zwar so genau, dass man es mathematisch exakt formulieren kann. Wenn man das Problem genau formuliert hat, hat man schon die Lösung, denn dann kann man den Computer einfach damit füttern. Das hat meine Denkweise geprägt. Habe ich das Problem genau verstanden? Habe ich das Problem genau verstanden?

Clean Code von Robert C. Martin

M104: The Sombrero Galaxy - Das Cover von Clean Code von Robert C. Martin
M104: The Sombrero Galaxy - Das Cover von Clean Code von Robert C. Martin von WikiImages

Wenn mich eine Strömung beeinflusst hat, dann ist es die Clean Code-Bewegung und damit eng verknüpft ja auch die agile Schiene. Robert C. Martin ist einer der Drahtzieher des agilen Manifests. Die Prinzipien habe ich verinnerlicht und entsprechen auch meiner Erfahrung. Sich regelmäßig mit Anwendern oder von mir aus Product Ownern treffen und zusammen planen und - ganz wichtig - den aktuellen Stand des funktionierenden Produkts präsentieren, das ist der Kern. TDD (Test Driven Development) hat sich für mich als Werkzeug herausgestellt, mit dem dieses Funktionieren sichergestellt werden kann. Das agile Manifest besteht aus Prinzipien und nennt keine konkreten Regeln. Einige meinen agil sei gleich Scrum. Mit Scrum bin ich bisher nicht warm geworden, denn Scrum ist nur Scrum, wenn man alle Regeln dieser Methode umsetzt und da wird es religiös.

Hier gibt es das Buch und mehr auch auf github (klärt die lizensrechtliche Problematik selbst!)

Sehr schade, dass ich das Buch aus der Hand gegeben habe. Es zählt zu den zeitlosen Büchern, die mal mehrmals lesen kann.

Design Patterns

Beide Bücher, das von den Gang of Four (GoF) und das Head First, sind trocken durchzulesen, obwohl letzteres spaßig sein will. Aber das Thema ist zu wichtig, es nicht zu beherrschen. Und so habe ich mir zu jedem Design Pattern ein Codeschnipsel geschrieben, der es implementiert und dabei die Bücher zu Hilfe genommen. Leider habe ich damals meinen Code noch nicht auf github veröffentlicht. Aber sowieso war die Übung nur für mich. Wie weiter unten unter Ausbildung geschrieben ist Bildung das, was übrigbleibt, wenn man vergisst, was man gelernt hat. So denke ich heute nicht bewusst an ein Design Pattern, wenn ich programmiere. Aber ich bin mir sicher, dass ich die Prinzipien ständig anwende. Wie oft binde ich der Flexibilität wegen z.B. eine neue Abstraktionsebene ein. Ob das jetzt ein statisches Interface wie in Java oder ein informelles Interface wie in Python ist, oder wie auch immer die Abstraktion aussieht. Ich habe mir auch den Satz eingeprägt: “Aggregation over Interitance” - gemäß dem Strategie-Muster, das grundlegendste Muster, auf dem viele weitere Muster aufbauen. Auch wenn ich Design Patterns nicht direkt anwende, kann ich Frameworks wie beabsichtigt verwenden, weil ich den Nutzen dahinter sehe.

Ausbildung

image image

“Bildung ist das, was übrig bleibt, wenn wir vergessen, was wir gelernt haben”. So steht es in meiner Diplomurkunde, die mir den akademischen Grad Diplom-Informatiker (FH) verleiht. Und wenn man das mit der Bildung mal so unscharf sieht, dann ist man doch ganz schön gebildet! Dann ist Bildung viel mehr als das Wissen, dass man sich eine zeitlang intensiv verschafft hat oder im Job ständig aufsaugt. Dann sind es die Menschen, die mich geprägt haben und die mir Wissen mit auf den Weg gegeben haben. Da ist mein Vater, promovierter Physiker, der die Welt schon immer in Zahlen und Formeln gefasst hat. Also der Job, den ich jetzt professionell mache. Da ist meine Mutter, eine sehr fleißige und leistungsfähige Frau, die immer 20 Sachen auf einmmal gemacht hat. Die körperliche Betätigung bei (aufgezwungener) Gartenarbeit. Wir hatten einen riesigen Garten. Ich wuchs ohne Wohnungsnot auf und wir hatten ein großes Haus. Dinge, die sich förderlich auf die Gesundheit auswirkten und von denen ich immer zehren werde. Warum hat man so schlechte Erfahrungen beim Outsourcing von Softwareentwicklung nach Indien? Weil das eine ganz andere Welt ist und weil man Software letztendlich immer noch von Menschen und für Menschen entwickelt. Ich kann meiner Umwelt nur danken für die Chancen, die ich erhielt. Ich bin in den Beruf des Softwareentwicklers hineingewachsen, weil die Welt mich braucht und weil ich dafür geeignet bin und nicht, weil ich als Profi-Nerd geboren bin.

Die erste Programmierung

Was war mein erster Computer? Es war der ZX-81

A typical Sinclair ZX81 setup including cassette recorder and black-and-white television set
A typical Sinclair ZX81 setup including cassette recorder and black-and-white television set von Mike Cattell , lizensiert unter CC BY 2.0

Wie ich jetzt in Wikipedia lese, war er mit 1 Kilobyte - EIN KILOBYTE - Arbeitspeicher nicht nutzbar, so dass man die 16 KB große Speichererweiterung kaufen musste, die aber nicht nur bei mir einen Wackelkontakt hatte. Ein Kassettenrekorder als Massenspeicher war auch nicht sonderlich verlässlich. Und trotzdem war so weit verbreitet. Die Folientastatur - ein Krampf.

Für den nächsten Home-Computer VC-20 von Commodore, dessen berühmter Nachfolger der C64 war, habe ich ein Spiel an die Home-Computer verkauft und dafür 120 Mark bekommen! Die Zeitschrift, in der man sogenannte Listings, den Programm-Code abtippen konnte - teilweise seitenlange Zahlenkolonnen - existierte von 1983 bis ca. Mitte 1986, d.h. ich war damals 10 - 13 Jahre alt.