Computer, Informatik und IT

(elkement. Erstellt: 2017-10-08. Tags: Arbeit, Beruf, Ingenieur, IT Security, IT-Sicherheit, Lernen, Programmieren, Software-Entwicklung, Technologie, Troubleshooting, Wissenschaft. Englische Version.)

Was mache ich eigentlich seit Jahrzehnten - in praktisch jedem Job, den ich jemals hatte ... und als Teil jeder Ausbildung, akademisch oder im Selbststudium?

Antwort: Software-Entwicklung! Diese Erkenntnis nehme ich zum Anlass, über meine Beziehung zur Computern und den dazugehörigen Wissenschaften und Aktivitäten zu philosophieren. Wie so oft, denke ich in Gegensatzpaaren.

Solide Ausbildung versus 'Learning by Doing'. Wie es ein IT-Kollege so treffend formulierte: In den Pionierzeiten war man gleich ein Experte, wenn man die Maus richtig halten konnte. Die 'IT-Branche' war ein Sammelbecken, offen für Leute mit 'irgendwelchen' oder keinen Qualifikationen.

Resultat: Die 'Hacker Ethic'. Es zählen die Fähigkeiten, die Du jetzt live demonstrieren kannst, nicht die Papiere. In den 1990ern - vor der dotcom-Krise - konnte man quasi ein handgeschriebenes Schild aufstellen 'Mache alles mit Computern' und bekam einen Vertrauensvorschuss.

Aufbau versus Zerstörung. Disclaimer: Ich war und bin lange genug verantwortlich dafür, 'Systeme' am Leben zu erhalten. Manche leben länger als es mir lieb ist; ich fühle mich wie der COBOL-Programmierer im Jahr 2000.

Aber das Interessanteste war immer herauszufinden, wie etwas funktioniert. Das kann auch kontrollierte Zerstörung erfordern. Debugging. Reverse Engineering. Troubleshooting. ... Was wiederum die Basis ist für die konstruktive Aufbauarbeit: Wie soll man sonst verwaiste System-'Blackboxen' oder undokumentierte Schnittstellen verstehen? Für mich war diese Reverse-Engineering-Mentalität immer die natürliche und direkte Verbindung zwischen Physik und IT.

... wichtiger als der mathematische Unterbau von Physik sowie Informatik oder die Programmierfähigkeiten, die man als Physiker angeblich so mitbekommt. Von FORTRAN - 'Programmierung für Physiker' weiß ich nicht mehr viel. Als Experimentalphysiker ein 'System der Natur zu debuggen', mit 'out-of-the-box' Ideen, war das eigentliche IT-Training: Welchen Parameter muss man ändern, um welchen Effekt zu erzielen? (Wenn man supraleitende Schichten erzeugt indem man mit Laserpulsen auf eine kleine keramische Probe schießt). Wie schließt man möglichst schnell und effizient aus, welche Parameter keinen Einfluss haben?

'Good-enough' Ansatz versus Perfektionismus. 80/20 oder vielleicht sogar 99/1. Man muss nicht alles wissen. Ich erinnere mich an mein erstes 'Live-Troubleshooten', als frischgebackener Computerberater. Mein Hintergrundwissen war spärlich - so gering, dass es mir heute fast peinlich ist diese Leistungen damals angeboten zu haben. Andererseits hatte ich alle Probleme tatsächlich gelöst - meistens sehr schnell.

In diesem Moment wurde mir der Kontrast zwischen pragmatischem Anpacken trotz unvollständigen Wissens und den endlosen Schleifen des Feilens an akademischen Veröffentlichungen bewusst. Wenn da ein Satz noch ergänzt wurde mit Tentatively, we assume,... nur um ganz sicher zu gehen; obwohl man eh schon ein Spezialist in einer sehr begrenzten Nische war.

Pragmatismus heißt auch: Kein falscher Stolz! Es wird die Lösung gewählt, die am vielversprechendsten erscheint: Tief hineinknien, oder auch: intelligent googeln oder jemanden mit Erfahrung fragen. (Letzteres aber nur, wenn man in ähnlicher Weise auch einmal selbst etwas beitragen konnte.)

Top-down, bottom-up, oder irgendwo in der Mitte beginnen. Ich war nicht der typische Computer-Nerd als Teenager; ich hatte keinen Computer außer dem programmierbaren Taschenrechner, auf dem man immer nur eine Zeile BASIC-Code sehen konnte. (Was aber reichte, um z.B. den Simplex-Algorithmus zu programmieren...).

Ich war eigentlich nur ein 'Benutzer', bis ich an der Reihe war, meinen Beitrag zur klassischen universitären Patchwork-Programmierung zu leisten: am Turbo-Pascal-Code zur Steuerung einer Anlage - Tieftemperaturmessungen elektrischer Eigenschaften von Proben.

Aber kurz darauf war ich dann plötzlich ganz oben in der Ebene der Abstraktionsschichten und habe - zugegeben :-) - in Visual Basic for Applications, ASP, VBScript programmiert. Langsam bewege ich mich 'nach unten', lerne endlich C++ und wärme ins Unterbewusste verdrängtes Wissen auf ... über 'Registermaschinen' und Assembler. Wobei das ja eigentlich die logische Grenzfläche zwischen Hardware und Software wäre, an der man als Physiker arbeiten sollte.

Grüne Wiese oder Renovier und ('Refactoring'). Selten habe ich etwas so richtig 'from scratch' entwickelt, und selten war mir das ein Bedürfnis. Harte Einschränkungen, Schnittstellen oder Schnipsel von mysteriösem Alt-Code sind die interessante Herausforderung - ähnlich wie die Sanierung eines alten Hauses im Vergleich zu einem Neubau.

Ich bin gerne Systemärchäologin - inklusive von 'Eigenforschung', was meine eigenen Kreationen betrifft, die ich jahrelang nicht angefasst habe.

Das Ausgraben von Alt-Daten oder -Code ist ohnehin ein Job, der bei vielen nicht sehr beliebt ist - also ist es umso besser im Sinn einer Arbeitsteilung, wenn man genau das gerne macht. Es ist das Gegenteil davon, die Chance zu haben, das neueste coolste Tool ausprobieren zu können.

Philosophische Grundlagen versus: die banale Lösung einer relativ alltäglichen Problemstellung.. Ein Meta-Thema meines kürzlich veröffentlichten Postings: Joel Spolsky empfiehlt (Bewerbern für Softwareentwickler-Jobs) ihre Leidenschaft für die Sache zu untermauern indem sie erwähnen wie die Lektüre von Structure and Interpretation of Computer Programs sie zu Tränen gerührt hat.

So weit hergeholt ist das gar nicht: Ich habe selten ein Lehrbuch gelesen bzw. eine Vorlesung besucht, die gleichzeitig so viele philosophische Erkenntnis-Lämpchen gedrückt hat und andererseits so nützlich war für die Programmieraufgabe, die gerade auf meinem Schreibtisch lag.

In der Hälfte meiner älteren Essays 'im Internet' geht's um meine qualvolle Suche nach diesen philosophischen wissenschaftlichen Tiefen - angesichts der harten Realität im Alltag des arbeitenden Techies. Auf der Uni hatte ich - noch sehr grün hinter den Ohren - angeboten bekommen, an einem Optimierungsprojekt für die Produktion von Plastikfenster mitzuarbeiten. Natürlich hatte ich das abgelehnt. Was denn auch sonst - unter dem Eindruck von Gödel, Escher, Bach und getrieben von dem Wunsch die tiefsten Rätsel des Universums zu entziffern und die Probleme der Menschheit zu lösen als Wissenschaftler-Ingenieur-Philosoph.

Ich muss lächeln; diese Anekdote demonstrierte so Vieles so perfekt. Nach x Jahren Praxis denke ich, dass man 'begeistert' ('passionate' wie das in der einschlägigen Literatur heißt) ist bzw. wird ... genau für jene Sache und jene Themen, in denen man gut ist. Nicht umgekehrt. Ich könnte sagen, ich habe zum philosophischen Überbau zurückgefunden und 'rette die Welt mit erneuerbaren Energien'. Aber eigentlich ist und war es immer das technische Rätsel, das mich angespornt hat - die 'Debugging-Challenge'. Und jedes Stückchen von noch so bodenständigem Code, das zur Lösung produziert werden muss spiegelt das die grunsätzlichen tiefen Wahrheiten (in Gödel, Escher, Bach or Structure and Interpretation) wider.

Persönliche Website von Elke Stangl, Zagersdorf, Österreich, c/o punktwissen.
elkement [ät] subversiv [dot] at.