Zur Person

Ich bin ein "Studierter", ich habe 1980 an der TU Karlsruhe mit dem Informatikstudium begonnen, wechselte aber nach drei Semestern an die FH Karlsruhe. Ich hatte recht schnell festgestellt, daß mir die Praxis mit einer soliden theoretischen Grundlage mehr Spaß macht als die Theorie ohne rechten Praxisbezug.
Das Studium schloss ich als Diplom-Informatiker (FH) mit einer ziemlich schlechten Note, aber viel Entwicklungs- und Programmiererfahrung (für mich) erfolgreich ab.

In meiner inzwischen über 30-jährigen Berufslaufbahn bin ich recht schnell in der Schublade "hardwarenahe Programmierung" gelandet. Und da bin ich eigentlich nie wirklich rausgekrabbelt. Treiber unter den verschiedensten Betriebssystemen, kundenspezifische Entwicklungen auf unterschiedlichsten Mircocontrollern ganz ohne Betriebssystem, Testprogramme für die Hardwareentwicklung und -Inbetriebnahme, mit solchen Sachen habe ich mich hauptsächlich beschäftigt.
Projektbedingt benutzte ich von Assembler über C und C++ bis zu Lua und C# ganz unterschiedliche Programmiersprachen. Objektorientierte Programmierung mag ich gar nicht, sehe aber durchaus auch sinnvolle Einsatzfälle. Mit der notwendigen Denkweise kann ich aber trotzdem nichts anfangen.

Zu C kam ich mit einem Amiga 2000, bis dahin war Pascal meine bevorzugte Sprache (weil es die erste war, die ich je gelernt hatte). C hat mit Pascal viel gemein, bot mir aber viel mehr Möglichkeiten, direkt an die Hardware zu gelangen. Für mich war C anfangs nur ein "besser lesbarer" Assembler. Über die Jahre habe ich diese Sprache als Allround-Werkzeug zur Lösung (fast) aller Programmieraufgaben schätzen gelernt.

Mein Programmierstil bzw. meine Arbeitsweise ist normalerweise (Achtung - Fachbegriff) "bottom-up". Ich will immer zuerst wissen: geht das mit der Hardware so, wie sich deren Entwickler das vorgestellt haben? Und wie kriege ich das hin? Wo sind die Haken? Was geht schief?
Das bedingt, ein kleines Stückchen Code zu schreiben und diesen dann zu testen, gradlinig und ohne "Firlefanz". Erst wenn ein Punkt, z.B. die Initialsierung eines Bausteins, abgearbeitet ist, geht es an die nächste Stufe. Diese Arbeitsweise hat mir schon einige Probleme mit der Projektleitung eingebracht, hat aber aus meiner Sicht als hardwarenaher Programmierer mehrere Vorteile:

Probleme während der Hardwareentwicklung können zügig auf den Punkt gebracht werden - was wieder die Hardwareentwickler freut (und natürlich auch nervt).
Funktioniert eine Anwendung beim Kunden nicht, lässt sich mit den gesammelten Testprogrammen feststellen, in welcher Stufe das Problem liegt - eigene oder Kundenhardware, Treiber, Aufruf der Treiber, API bzw. der Anwendung oder einfach nur ungeschickte Dokumentation oder Kommunikation.
Aus den entstehenden Testprogrämmchen lässt sich oft eine Prüffeld-Software zusammenstellen, weil die Grundlagen schon da sind. Und für spezielle Probleme der Kollegen im Prüffeld findet man auf der vorhandenen Grundlage eher eine Lösung, weil es kein "Drumherum" gibt, welches das Testergebnis beeinflusst (so die Theorie).

Diese Herangehensweise sieht natürlich, von außen betrachtet, so aus, als würde lange Zeit nichts passieren, weil nichts für den "Laien" (die Projektleitung muss die innersten Details nicht kennen, sondern den Überblick haben) vorführbares entsteht.

Man kann solche Arbeiten sicherlich auch mit anderen Programmiersprachen erfolgreich erledigen. Aber mir erscheint die Verwendung von C immer noch am gradlinigsten. C lässt alles zu - selbstverständlich auch jeden Unsinn und jeden Fehler!

--- Cut ---

Meine Hobbys sind schon seit dem Studium Motorräder (Fahren und Schrauben) und Modellflug (im Besonderen ferngesteuerte Hubschrauber). Dabei habe ich sehr schnell gelernt: alles, was ich mache, muss ich verifizieren und doppelt und dreifach prüfen. Ein vergessener Bremsschlauch am Motorrad führt im besten Fall zu einer Überraschung, im schlimmsten Fall zum Tod. Funktioniert bei einem Modellhubschrauber eine Steuerfunktion nicht wie erwartet, wird es meistens teuer, es kann aber auch Verletzte geben.

Das und eine stark naturwissenschaftlich geprägte Jugend sind wahrscheinlich die Erklärungen für meine Herangehensweise und Eigenheiten beim Programmieren. Das betriift die Art Programme zu dokumentieren, die Coding Style Guidelines und die dauernde Testerei. Und den Widerwillen mich als Programmierer mit Betriebssystemen und GUIs herumzuschlagen, weil ich da zu wenig Kontrolle über die Begleitumstände habe.

Hörnum (Sylt), 10.9.2021