Über mich

Beruflicher Werdegang

Nach erfolgreichem Abschluss meines Informatik-Studiums an der FH Regensburg im Frühjahr 1996 (Dipl. Inform. (FH)) arbeitete ich zunächst von Oktober 1996 bis April 2000 in Feststellung bei einem Internet Service Provider und erlernte dabei die Systemadministration, durfte aber parallel auch an einem größeren Programmierprojekt teilnehmen.

Im Mai 2000 ging ich in die Freiberuflichkeit mit dem Ziel mich auf Software-Entwicklungsprojekte zu fokussieren. Mein Projekt-Spektrum, das ich seitdem erleben durfte, deckt die komplette Palette von sehr großen über mittelgroße bis hin zu einigen kleineren Projekten ab. Ebenso reicht die Kundenpalette von internationalen Großkonzernen über Behörden bis zu Mittelständlern.

Dabei habe ich im Lauf der Jahre die klassischen technischen Rollen durchlaufen können: Vom Entwickler zum Lead-Entwickler bis zum Software-Architekt und auch Solution-Architekt.

Als ich ca. in 2013 erstmals mit „Clean Code“ und den „SOLID Principles“ in Kontakt kam, war mir sofort klar, dass das der Weg ist, den man als qualitätsbewusster Entwickler gehen muss. Nachdem ich mich intensiv damit auseinandergesetzt hatte konnte ich das Wissen in einigen Projekten auch an die Team-Kollegen weitergeben und sie z.T. auch coachen.

Tatsächlich ist „Clean Code“ über die Jahre auch zu einem de-facto Standard geworden. Aus meiner Projekterfahrung muss ich jedoch sagen, dass ein Großteil der heute laufenden Softwaresysteme immer noch aus qualitativ minderwertigem Code besteht oder zumindest nicht den Clean Code-Standards entspricht. Auch wenn vielerorts Qualitätssicherungstools wie Sonarqube zum Einsatz kommen, so werden die Regeln meist soweit „entschärft“, dass kein echter Clean Code mehr geschrieben werden muss. Zum anderen entziehen sich zentrale Aspekte des Clean Code diesen Tools per se, wie z.B. ein aussagekräftiges Naming oder auch die Anwendung der SOLID Principles.

Im Rahmen meiner freiberuflichen Tätigkeit entwickelte ich auch bereits frühzeitig (ca. ab 2008) ein starkes Interesse an Methoden der „Fachlichen Analyse“ und habe daher diverse Kunden auch als Business Analyst / Requirements Engineer beraten.

Als optimal würde ich diejenigen Konstellationen bezeichnen, in denen ich in Doppelrollen, z.B. als Business-Analyst und Architekt oder als Architekt und Lead-Developer tätig war.