70er
Wenn ich gefragt werde, seit wann ich „was mit Computern mache“, antworte ich gerne, dass ich mit 9 Jahren BASIC aus einem Buch gelernt hätte. Richtiger wäre aber zu sagen, dass ich meine ersten Kontakte mit Computern in der Zeit hatte (also um 1979), als mein Vater nach dem „richtigen“ Homecomputer für uns zu suchen begann und erkannte, dass für uns Kinder Programmieren und/oder der Umgang mit Computern in Zukunft wichtig sein würde. Tatsächlich dauerte es bis 1981, als der C64 erschien, dass ich wirklich zu programmieren lernte – aus dem besagten Buch hatte ich bis dahin nur sehr simple „10 print ‚hallo‘ – 20 goto 10“ Programme auswendig gelernt.

80er
Um die Grafikfähigkeiten des C64 voll auszureizen (das ist Understatement – mein Freund und ich gehörten zu den ersten, die Commdore-Mitarbeiter auf Messen erklärt haben, wie man ganz einfach „Text auf den Rand“ bringen konnte, indem man Sprites per Interruptroutine „ins Nirvana schob“), lernte ich Maschinensprache. Und stritt mich lautstarkt Mitte der 80er mit studierten Köpfen, die auf ihre „Hochsprache“ Assembler schwörten, über die Reinheit und Eleganz von „echtem Programmieren“. Kinderkram? Wenn ich mir die Glaubenskriege über „strukturierten Code“ in den 90ern, „PHP ist Gott/Teufel“, „Pro und Contra Java“ in den 2000ern oder Ruby, Python, Perl und Jibberish in den 2010ern anschaue, glaube ich, dass wir (wenn auch mit 14/15 Jahren reichlich altmodisch eingestellt) ganz „up to date“ waren. Nicht in der Wahl der Programmiersprache, sicher aber in unserer Überzeugung, dass nur derjenige Programmierer, der sich das Leben selbst so schwer wie möglich macht, ein wahrer Meister ist.
Wir schrieben uns sogar Postkarten mit Programmen in Hexcode, den 6510-Code kannten wir selbstverständlich auswendig. Für Zeitschriften und Buchverlage habe ich damals in verschiedenen Sprachen (Logo, Basic, Fortran, Pascal, Assembler) Beispielprogramme und „Tools“ entwickelt, Ende der 80er für Apple- und PC-Systeme GUIs und Dokumentationen erstellt.
Wichtiger noch als meine Erfahrungen auf dem C64 war das Erscheinen des Amiga (1000), der vom Start weg viel versprach und es teilweise verdammt schwer machte, seine Leistungsfähigkeit wirklich zu nutzen.

90er
Mit Assembler habe ich mich auf der neuen Plattform nur kurz befasst, 68000 war einfach nicht mehr „schön“. Die Programme wurden umfangreiche, es ging immer mehr darum, die begrenzten Möglichkeiten des Amiga-System-GUIs „aufzubohren“, Leistungsgrenzen zu umgehen und mehr aus den Ressourcen (RAM, Festplatten) herauszuholen als andere. Thomas Wenzel und ich entwickelten Mitte der 90er eigene Audio-Hardware und kamen auf diesem Weg dazu, das damals noch von SEK’d entwickelte Samplitude (einer schon auf dem Amiga als High-End Audio-Software) zu übernehmen und auf dem Amiga weiterzuentwickeln (SEK’d wollte sich ganz auf den PC konzentrieren, die bestehenden Kunden auf dem Amiga aber nicht im Stich lassen).
Die Querelen um den Amiga und sehr negative persönliche Erlebnisse mit Commodore-/Amiga-Entscheidungsträgern haben mich gelehrt, dass jedes Festhalten an einer Plattform aus Gewohnheit oder gar Überzeugung mittelfristig zu Frust und langfristig zu Tränen führt. Computer sind Werkzeuge und Software ist deren Schmiere. Mehr nicht. Wer glaubt, dass ein Computersystem (oder ein OS) „besser“ als ein x-beliebiges anderes ist, muss dringend mal an die frische Luft.
Das einzige, das ich heute wegen meines Abschieds von der Commodore-Welt bedaure, ist, dass ich ARTAS –(zunächst „Amiga“-, später dann) Agnostic Retargetable Audio System – nicht zu Ende entwickelt habe. ARTAS nahm, wenigstens theoretisch, Funktionen vorweg, die Steinberg in VST präsentierte (wobei sicher beide nichts voneinander wussten). Grundsätzliche Ideen aus ARTAS habe ich später in Bildverarbeitungs-Workflows umgesetzt, aber eine „perfekte“ Realisation gibt es bis heute nicht.

2k
Schon in den 90ern hatte ich intensive Berührungen mit der Verlagswelt, zunächst als fester, später als freier Mitarbeiter einer Servicefirma für die „Verlagsgruppe Milchstraße“ in Hamburg (TV Spielfilm, Cinema, Max, Amica und viele weitere damalige Top-Titel), später dann als Projektbetreuer und Entwickler für Datenbanken, GUIs (Anwender-Schnittstellen) und komplexe Redaktionssysteme.
Aus Projekten, die ich zum Teil selbst gestartet, zum Teil umfangreich mit entwickelt habe, entstanden Bilddatenbanken und Heftplaner, Conten-Management- und Workflow-Systeme. Als eine Redaktion die interne Bildverwaltung von „Cumulus“, einer damals verbreiteten (kleinen) Datenbanklösung auf plattformunabhängige, mit anderen Systemen verbindbare Techniken umstellen wollte, schrieb ich einen webbasierten „Cumulus-Reader“, mit dem per Webbrowser vorhandene Datenbankfiles interaktiv genutzt werden konnten. Auf diesem Reader basierend entwickelten wir hausintern „KuhMuli“ (als Wortspiel zwischen „viele Cumulus“ und „Arbeitstier der Milchstraße“), ein System für Bild- und Textverarbeitung, Artikel-Platzierung und Herstellungs-Schnittstelle, mit dem über viele Jahre umsatzstarke Magazine produziert wurden (u.a. TV Spielfilm). Ein Bilderkennungs-Tool, das (die bei TVS damals eingesetzte) Farbgewichtungen (mit ICC Farbmanagement und Gewichtungskurven) für die Auswahl von passenden Bildern erleichterte, war „ImageBug“, aus dem ich privat den „ImageBeatle“ entwickelte, ein Keyframe-Flipchart für Videoproduktionen.
Eine Teilanwendung aus dem Workflow-Tool KuhMuli war „QImport“, ein vollautomatisches Bildverarbeitungssystem, das ich mit einem Partner für Bildagenturen und Fotografen entwickelte. QImport machte es in einigen Installationen möglich, die Zahl der täglich verarbeiteten (und damit umsatzgenerierenden) digitalen Bilder zu verzehnfachen.
Aus einem anderen Entwicklungsschritt – einer „Miniwand“ zur Heftplanung, die „live“ den aktuellen Redaktionsstand einzelner Zeitungs- und Magazinseiten im Intranet darstellen konnte, entstanden PDF- und Dokumentenarchive für Zeitungsverlage und Werbeagenturen. Einige dieser Installationen sind heute noch im Einsatz (z.B. beim ZEIT-Verlag), u.a. weil die dafür entwickelte PDF-Erfassung Texte zurück in Fließtexte wandelt (z.B. werden Zeilenendtrennungen erkannt und beseitigt) und damit eine Volltextindizierung ermöglicht, die bessere Treffer liefert als andere (zum Teil weit umfangreichere) Lösungen.

2.01k
Die allgegenwärtigen „Smartphones“ haben die Entwicklung hausinterner Datenbanken nicht erleichtert; zu Performance- und Anwenderfreundlichkeits-Problemchen sind (zum Teil erhebliche) Sicherheitsfragen gekommen, da auf einmal Zugriffe „von draußen“ auf sensible Daten gefordert sind. Eines der spannendsten Projekte, das ich Anfang der 2010er Jahre entwickelt habe, ist eine Adress- und Kontaktdatenbank mit CRM-Funktionen, Anbindungen an externe Dokumentensysteme, Schnittstellen zu Outlook und freie Emailsysteme und einem kontrollierten Datenexport an Blackberry-Geräte.
Aus der Kontaktdatenbank-Entwicklung bzw. der damit verbundenen Schnittstellen zu MS Office (die lizensierbaren Fertiglösungen boten die gewünschten Funktionen nicht) sind ein paar Smartphone-„Apps“ und Kundenkontakt-Tools entstanden.
Mein derzeit ambitioniertestes Projekt „Framtle“ (für „Frame-Beatle“) geht zurück auf „ImageBeatle“, das Bildstrecken aus Filmclips erzeugte, um Audio-Spuren ressourcensparend (und damit sehr schnell) zu Videos zu synchronisieren. Framtle befindet sich noch in der (erweiterten) Planungsphase – es wird Bild- und Tonspuren, Text- und Scribble-Inhalte zu Storyboards zusammenfassen, die für die Planung von Filmen/Videos, aber auch Texten (Büchern), Magazinen/Artikelserien oder Seitenstrecken eingesetzt werden können.