Dieser Post gehört wohl in die Kategorie In eigener Sache und kann vorerst notgedrungen nur das Ende der Artikelserie iLogic mit Autodesk Inventor auf diesem Blog bedeuten.
Ich habe diesen Monat unerwartet meinen Job als Konstrukteur und CAD Power User verloren und werde mich beruflich neu umschauen müssen.
Derzeit habe ich nur noch eingeschränkten Zugriff auf Autodesk Vault und Inventor, was ich selber schwer bedauere, da ich eine komplette Serie zum Umgang der Vault API mittels PowerShell und der neuen spannenden Vault Data API in der Mache hatte. Dies kann und wird nun nicht mehr stattfinden können.
Ob ich einen neuen Arbeitgeber finde, der Autodesk Produkte produktiv einsetzt, ist für mich derzeit nicht absehbar. Primär gilt es für mich beruflich nach Vorne zu schauen. Zeitgleich lohnt aber auch ein Rückblick auf die existierenden 25 Beiträge der iLogic Artikelserie, die über die letzten 3 Jahre entstanden sind, denn sie vermitteln gutes Basiswissen für Anfänger und auch Anwendungsfälle, die weit über iLogic Funktionalitäten hinausgehen.
Wie kam es zu der Serie?
Ich habe damals in meiner Firma nicht aktiv darum gebeten, die iLogics zu schreiben und zu betreuen, sondern bin notgedrungen in diese Rolle geraten. Ursprünglich wurde der Code durch den Administrator der Vault Datenbank geschrieben und auch per Vault Startroutine an die User ausgerollt.
Es stellte sich bedauerlicherweise zunehmend heraus, dass der Administrator weder die Fähigkeiten, noch den erforderlichen Willen, sich in das Thema iLogic hineinzudenken, geschweige denn die Größe besaß, dies offen zuzugeben und Verantwortung für seinen Code zu übernehmen.
Das Resultat waren:
- unzählige tagesaktuelle Fehlermeldungen, die bei mir als CAD Power User aufliefen, und kontinuierlichen User Support hervorriefen
- iLogics, die sich selber widersprachen und gegeneinander arbeiteten, da konzeptfrei, strukturlos und tagesaktuell ohne Versionshistorie gearbeitet wurde
- iLogics, die unzählige unnötige Revisionen erforderten, da sie automatisiert fehlerhafte Produktdaten erzeugten, die anschließend in die Freigabe gingen
- iLogics, die kontinuierlich on the fly modifiziert wurden, ohne die Nutzer oder mich in Kenntnis zu setzen
Über zwei Jahre hinweg blieb jede Verbesserung der Situation aus. Ich nahm mich der Thematik an, weil es sonst keiner getan hätte und weil es mir zunehmend zutiefst zuwider war, tagesaktuellen Support für Fehlmeldungen zu leisten, die ich selber nicht produziert hatte.
Im Ingenieursstudium hatte ich zwei Semester VBA-Programmierung mit Excel. Einen realen Anwendungsfall habe ich dafür im Berufsleben nie gefunden. Daher war die Auseinandersetzung mit dem Thema iLogic eine willkommene Abwechslung zum Alltag als Konstrukteur, da die Thematik Realbezug aufwies und iLogic Schnittmengen mit VBA besitzt.
Farewell
Rückwirkend betrachtet bedeutet mir die Serie viel, da sie für mich selber eine kleine chronologische Dokumentation meines beruflichen Schaffens darstellt und zeitgleich Zeuge meiner persönlichen Lernkurve ist. Nahezu alle Beiträge waren inspiriert durch tagesaktuelle Probleme oder Hürden, die es zu meistern galt. Ich habe diverse Mails anderer Konstrukteure erhalten, die sich ebenfalls an iLogic versucht haben und fand den Gedanken immer schön, dass meine Serie auch anklang in der Welt gefunden hat.
An dieser Stelle möchte ich auch jeden Konstrukteur ermutigen, sich offen dem Thema iLogic zu stellen, denn es ist ein mächtiges Werkzeug, das Zeitersparnis produzieren kann und zeitgleich lernt man die Funktionsweise von Inventor aus Sicht der Programmierschnittstelle kennen. Die Schnittstelle zwischen Engineering und Programmierung ist ein spannendes Themenfeld, das in vielen Unternehmen bis heute noch nicht ausreichend wertgeschätzt, und in Zukunft zunehmend an Bedeutung gewinnen wird.
Sollte ich in Zukunft erneut beruflich mit Inventor arbeiten, werde ich die Serie ggf. fortsetzen. Bis dahin bleibt jedoch nur eins zu sagen: “Adieu iLogic!”