>

Matthias Gorzellik

Wer bin ich

Ich bin promovierter experimenteller Teilchenphysiker und arbeite nun seit mehreren Jahren als freiberuflicher Hardware-/Softwareentwickler. Mein Hintergrund als Physiker bringt eine einzigartige Perspektive auf die Aufgaben und Probleme auf die ich als Entwickler treffe. Meine Mitwirkung in der Planung und Durchführung komplexer Experimente hat mich gelehrt, systematisch zu denken, mit Unsicherheiten umzugehen und auch unter anspruchsvollen Bedingungen präzise Lösungen zu entwickeln. Ich verbinde analytische Stärke mit hands-on Mentalität: vom Entwurf digitaler Schaltungen bis zur Implementierung effizienter Software.

Was ich für Sie tun kann

Was mich auszeichnet ist meine Fähigkeit, interdisziplinäre Probleme ganzheitlich zu erfassen, schnell neue Technologien zu durchdringen und wissenschaftliche Sorgfalt mit pragmatischer Umsetzung zu vereinen. Ich kann sowohl Ihr Softwareteam, als auch Firmwareteam, oder bei der Schnittstelle dazwischen, unterstützen. Am wohlsten fühle ich mich nahe an der Hardware, und wenn es knifflige Probleme zu lösen gilt. Dabei gehe ich nicht dogmatisch vor sondern evaluiere jede Situation neu um die gesamtheitlich gesehen bestmögliche Lösung möglichst zeiteffizient zu finden.

Expertise

GNU/Linux-basierte Betriebssysteme

Ich bin seit über 20 Jahren Nutzer von Gentoo, mit tiefem Einblick und Erfahrung in unterschiedlichsten Bereichen. Ich habe über mehere Jahre die Administration des Linux-Rechenclusters meiner Abteilung an der Universität übernommen. Für meine SBCs setze ich regelmäßig Yocto ein und habe im Rahmen eines Auftrags ein Yocto-basiertes Betriebssystem als Unterbau für eine Kioskapplikation im Medizinbereich bis zur Produktionsreife entwickelt. Eines meiner Hobbyprojekte ist die Entwicklung eines Linux-Kernel Treiber für Fanatec-Simracing-Hardware.

Programmierung

In meiner Vergangenheit als Physiker war die Programmierung Mittel zum Zweck, ein Werkzeug um grosse Mengen an Daten zu analysieren und zu physikalischen Aussagen herunter zu brechen. Dazu war es nötig innerhalb komplexer Frameworks zu arbeiten und eine effiziente Vorgehensweise zu entwickeln. Im laufe der Zeit habe ich viele gänige Programmiersprachen verwendet, am meisten Erfahrung habe ich jedoch mit Python, VHDL und C. Beispielprojekte (Hobbycodequalität) finden sich auf GitHub.

VHDL

Mein Interesse an FPGAs und Hardwareprogrammierung wurde während meiner Studienzeit geweckt, als ich an einem Experiment am CERN (COMPASS) mitgearbeitet habe. Insbesondere habe ich mich dort mit dem VHDL Design für FPGA basierte Detektorauslese und Triggerlogik in einem zeitkritischen Umfeld (~1us) beschäftigt. Später habe ich dieses Wissen auch in meiner beruflichen Tätigkeit angewendet, wenn es erforderlich war.

Tooling

Mein tägliches Arbeitswerkzeug ist Neovim mit LSPs für die jeweils benötigte Sprache sowie diversen weiteren Plugins. Ich habe auch NetBeans, Eclipse, IntelliJ etc. genutzt, aber Neovim passt am besten zu meiner Arbeitsweise - vermutlich, weil ich ohnehin stark terminalorientiert arbeite. Für VHDL habe ich sowohl Intel- als auch Xilinx-Vivado-Tools verwendet und Testbenches mit cocotb entwickelt.

Meinungen

Coden

Beim Schreiben von Code beachte ich folgende Punkte:

• Code wird häufiger gelesen als geschrieben.
• Code sollte sich selbst “dokumentieren”.
• Kommentare sollten das “Warum” beschreiben, nicht das “Was” (Kommentare die den Code wörtlich wiederholen sind nutzlos).
• Der erste Ansatz für ein Problem funktioniert fast nie vollständig, daher ist es wichtiger, zunächst einen guten Proof-of-Concept (PoC) zu erstellen als zu optimieren.
• Happypath-coden ist vlt OK für einen PoC, Edge-Cases holen einen jedoch früher ein als man glaubt.
• Edge-Cases sind oft kein Randthema, sondern definieren das Systemverhalten. Wer sie ignoriert, versteht das Problem oft noch nicht vollständig.
• Refactoring ist kein optionaler Schritt.
• Zu früh abstrahieren ist genauso schädlich wie gar nicht abstrahieren.

Testing

Das Schreiben von Unit-Tests sollte Hand in Hand mit der Entwicklung gehen. Es sorgt für klareren Code und erleichtert anderen den Zugang zu den jeweiligen Codebereichen. Dennoch sollte der Entwickler entscheiden, welcher Code getestet werden muss - nicht blind auf X % Coverage hinarbeiten.

AI

Ich nutze AI und habe sie in meinen Editor integriert um effektiver zu arbeiten. “Vibe Coding” nutze ich allerdings nur sehr eingeschränkt, z. B. wenn ein PoC benötigt wird. Programmiersprachen existierun unter anderem weil die verbale Sprache nicht eindeutig genug ist. Tatsächlich war für mich bisher das “generieren von Code” nicht der limitierende Faktor, sondern mehr das Reagieren auf sich immer ändernde Voraussetzungen und Anforderungen und die daraus resultierenden Folgen für die Codebase. In solchen Szenarien habe ich bisher keine guten Erfahrung gemacht hinsichtilch der Codequalität von AI generiertem Code. Aber ich bin neugierig wie sich AI in Zukunft weiter entwickelt und werde ggf. meine Meinung aktualisieren ;)