Von der HLW zur Medizintechnik: Die Research-Reise von Claudia Wittner bei CADS GmbH

Einleitung: Eine Entwicklerinnenlaufbahn, die mit Neugier beginnt

In „Claudia Wittner, Researcher bei CADS“ erzählt Speaker Claudia Wittner (CADS GmbH) ihren Weg von den ersten HTML/CSS-Zeilen in der Schule bis zur Forschung an patientenspezifischen Implantaten und Softwareprototypen. Wir bei DevJobs.at haben aufmerksam zugehört, wie sie Etappe für Etappe eine technische Identität geformt hat: erst Web, dann Medizintechnik, schließlich Research – getragen von Neugier, Praxisnähe und dem Willen, Fragestellungen bis zum Ende durchzudenken.

Ihr roter Faden ist bemerkenswert konstant: Sie folgt dem Interesse. Was als kreatives Ausprobieren im Web beginnt, wird zum strukturierten Arbeiten mit Code, Daten und Messsignalen – bis hin zur evidenzbasierten Publikation. Und genau daraus lassen sich für Entwickler:innen klare Lehren ziehen: Projekte ganzheitlich sehen, Prototypen schnell bauen, „Stand der Technik“ recherchieren, Datenlage prüfen, Ergebnisse iterativ verfeinern – und dranzubleiben, auch wenn etwas vorerst nicht funktioniert.

Der Start: HLW Medieninformatik und Design – Kreativ und technisch zugleich

Schon mit rund 14 Jahren berührt Claudia zum ersten Mal das, was später ihre berufliche Welt wird. In der HLW mit Schwerpunkt Medieninformatik und Design schreibt sie HTML und CSS, probiert JavaScript, verbindet Datenbanken und streift PHP. Diese Bandbreite bleibt bewusst offen – „alles ein bisschen gestreift“, wie sie sagt. Entscheidend: Sie erlebt früh, dass Technologie ein Gestaltungsraum ist.

Sie baut erste Webseiten, ohne starre Vorgaben. Der Freiraum ist spürbar: eigene Projekte, eigene Entscheidungen. Diese Phase prägt, und sie zeigt bereits zwei Qualitäten, die sich durch Claudias Weg ziehen: erstens der Mut, etwas anzufassen, bevor es perfekt ist; zweitens die Freude an der Kombination aus Kreativität und Technik. Aus unserer Sicht ist das genau jene Mischung, die viele nachhaltige Entwickler:innen-Karrieren fundiert: Neugier trifft Umsetzung.

Die Abzweigung: Weg vom Medienbereich, hinein in die Medizintechnik

Nach der HLW überlegt Claudia neu. Der Medienbereich soll es nicht bleiben. Sie schaut sich um: Welche Fachhochschulen gibt es? Welche Studiengänge in Österreich? Sie besucht Hagenberg, Linz – und bleibt bei der Medizintechnik an der FH Linz hängen. „Ich probiere es halt einmal“, beschreibt sie den Schritt. Der Start ist ohne Pathos, dafür mit offenem Ausgang. Gerade dieser nüchterne Pragmatismus passt zur späteren Research-Arbeitsweise.

Was folgt, ist ein schneller Zuwachs an Kompetenzen – nicht zuletzt durch den Informatikzweig: „Dann hast du einfach mal alle Grundlagen gelernt und relativ schnell … alles bergauf gegangen.“ Die Lernkurve ist steil, das Lernen praxisnah. Stück für Stück verlagert sich der Fokus in Richtung Medizin. Das Interesse ist da – und wächst mit den Aufgaben.

Lernen, das unter die Haut geht: Biomechanik, Elektroden, Handprothese

Ein eindrückliches Lehrmoment kommt, als Biomechanik und Körperdaten zusammenkommen. Claudia arbeitet mit Elektroden, „die Potenziale abgegriffen“ werden – und steuert damit eine Handprothese. Der Code ist transparent und verbindlich: Input-Signale, Auswertung, Steuerlogik. Das ist Informatik, die wortwörtlich greifbar wird. „Das war halt mega spannend“, sagt sie – und man spürt, wie Praxisbezug Motivation stiftet.

Für uns ist das ein Leitsatz für Developer-Karrieren: Reale Signale, reale User:innen, reale Wirkung – nichts beschleunigt Lernen so sehr wie Systeme, die spürbar etwas tun. Genau hier schlägt das Herz von „Engineering als Anwendung“: Nicht bloß Syntax, sondern Wirkung.

Python wird die erste echte Lieblingssprache – flankiert von Statistik

Im Bachelor beginnt es, im Master vertieft es sich: Python. Spätestens im Master „ist mir … eine Programmiersprache ans Herz gewachsen“, sagt Claudia – Python wird zur ersten Wahl. Daneben gewinnt Statistik an Gewicht. Das macht Sinn: Forschung braucht Hypothesen, Messungen, Auswertungen. Sie denkt bereits „hinsichtlich Paper“, verknüpft Code mit Methodik. Diese Kombination – nutzbarer Code und saubere Auswertung – wird später die Grundlage für Publikationen, Prototypen und Produktideen.

Masterarbeit: Patientenspezifische Kopfimplantatsplanung – von R zu Python

Die Masterarbeit markiert einen weiteren Meilenstein. Thema: patientenspezifische Kopfimplantatsplanung. Claudia setzt dafür auf R – und ordnet es zeitlich ein: Heute werde vieles bereits stark von Python abgelöst. Sie streift Geometric Morphometrics und verweist darauf, dass sich diese Arbeitsschritte parallel auch in Python abbilden lassen.

Uns fällt auf: Nicht die Tool-Frage steht im Vordergrund, sondern die Problemstellung. Das Werkzeug darf sich ändern; entscheidend ist der systematische Zugriff auf Daten, Modelle und Auswertung – genau jene Haltung, die in der Research-Rolle zählt.

Forschung zum Anfassen: Mikro-CT an der FH in Wöss – die ganze Pipeline

Nach der Masterarbeit bleibt Claudia in der Forschung – an der FH in Wöss, bei der Mikro-CT-Forschungsgruppe. Sie scannt selbst mit diversen CT-Geräten, segmentiert händisch (damals sogar mit Drawing-Tablet) und geht bis zur Auswertung und zum Paper. „Da habe ich mal den ganzen Werdegang selbst durchhauen können.“ Diese End-to-End-Erfahrung ist selten – und wertvoll.

Wer einmal die komplette Kette verantwortet hat – vom Objekt über Scan, Segmentierung, Datenaufbereitung und Analyse bis zur Publikation – entwickelt ein Gespür dafür, wo Qualität entsteht und wo sie verloren gehen kann. Für technische Karrieren ist das Gold wert: Man lernt, wie frühe Annahmen späte Ergebnisse prägen.

Vom Paper zum Job: Sichtbarkeit, die Türen öffnet

Aus dieser Forschungsarbeit entsteht ein Paper – und es macht die Runde, „im Obermühlviertel“, landet in der Zeitung. Freund:innen melden sich, und ein Studienkollege, der bereits bei der CADS GmbH arbeitet, fragt nach: „Möchtest du anfangen?“ Es ist eine einfache Kette: gute Arbeit → sichtbare Arbeit → Gelegenheit.

Wir sehen darin ein ermutigendes Muster für Developer:innen: Ergebnisse zeigen, nicht verstecken. Sichtbarkeit ersetzt kein Können – aber sie vergrößert den Wirkungsradius. Claudias Weg zur CADS GmbH beginnt hier.

Die Rolle bei CADS: Researcher – immer mit einer Problemstellung starten

Claudias Rolle lautet „Researcher“. Doch die Bezeichnung bleibt zweitrangig; entscheidend ist der Arbeitsstil. „Man startet … immer mit einer Problemstellung“, sagt sie. Diese kann intern entstehen („kann man das lösen?“) oder über Förderanträge in Kooperation – sie nennt etwa eine Zusammenarbeit mit Carlos Martin. Häufig landet die „Softwarelösung … dann bei uns“, inklusive „konkreter Fragestelle“ von Anfang an.

Der Prozess hat einen klaren Takt:

• Daten organisieren: Was liegt vor? Was fehlt? Wie strukturieren wir die Datengrundlage?
• Machbarkeitsanalyse: „Proof of Concept, geht das – und dann schauen wir mal weiter.“
• Recherche: „Was ist der aktuelle Stand der Technik?“ Wie haben andere das Problem gelöst?
• Datenlage absichern: „Haben wir genug Daten dafür?“ – hier hilft, „an der Quelle“ zu sitzen, „wenn man eng mit Krankenhäusern zusammenarbeitet“.
• Ersten Prototyp bauen: „eine erste Schiene … erste Ergebnisse“.
• Iteration: Während man verfeinert, tauchen neue Fragestellungen auf – oft Keimzellen für Folge- oder Nebenprojekte.

Ergebnisoffenheit ist dabei normal: „Manchmal ist es eine Softwareanwendung, ein Plugin und manchmal ist es einfach eine Publikation oder ein Nebenprodukt an einer Publikation.“ Research „lebt“ davon – neugierig bleiben, neue Wege entdecken, die sich im Prozess erst zeigen.

Was uns beeindruckt: Systematik ohne Dogma

Claudia beschreibt eine Arbeitskultur, die pragmatisch und sauber zugleich ist. Es gibt kein Tool-Dogma, kein Over-Engineering. Stattdessen: Daten klären, Stand der Technik verstehen, Machbarkeit beweisen, Schritt für Schritt verbessern. Dieses Muster ist universell – ganz gleich, ob man in der Medizintechnik, im Web oder im Embedded-Bereich unterwegs ist.

Besonders stark ist der Verweis auf den Wert unvollkommener Zwischenergebnisse. Ein Prototyp ist kein Produkt – aber ohne Prototyp kein Produkt. Eine händische Segmentierung ist mühsam – aber sie qualifiziert spätere Automatisierung. Eine Publikation ist Arbeit – aber sie schafft Klarheit und Sichtbarkeit. Claudias Weg zeigt: Jede Etappe hat ihren Zweck.

Ratschläge aus der Praxis: Neugier, Mut und Ausdauer

Claudias Ratschläge sind einfach – und deshalb wirksam:

• Ein Thema finden, das interessiert: „Dann geht’s eigentlich umso leichter.“ Interesse trägt durch Durststrecken.
• Neues ausprobieren: „Nicht scheuen, dass man etwas Neues probiert.“ Erst durch Tun entsteht Urteilskraft.
• Rückschläge einkalkulieren: „Es wird mal passieren, dass etwas nicht funktionieren wird.“ Das Wissen, „dass es nicht funktioniert und vor allem wie es nicht funktioniert“, ist bereits ein Ergebnis – oft steht man „genau so kurz davor, dass man’s eh löst“.

Übertrag auf den Entwickler:innenalltag: Jede neue Programmiersprache, jedes neue Thema folgt demselben Muster. Man kämpft mit ersten Stolpersteinen, man lernt die Eigenheiten kennen, man baut kleine Dinge, dann größere – bis es „klick“ macht. Diese Lernkurve ist nicht zu umgehen, aber sie lässt sich gestalten: neugierig bleiben, dranbleiben.

Konkrete Learnings für Entwickler:innen und Forschende

Aus Claudias Story lassen sich praktikable Handlungsmuster ableiten – unabhängig vom konkreten Fachgebiet.

1) Ganzheitlich denken – End-to-End erleben

• Wer die Pipeline von „Rohdaten bis Ergebnis“ einmal selbst trägt, schärft Qualitätsbewusstsein. Claudias Weg über Mikro-CT, händische Segmentierung (Drawing-Tablet), Auswertung und Paper zeigt: End-to-End-Verantwortung macht robust.
• Praxis-Tipp: Wenn möglich, mindestens einmal im Projekt die komplette Kette verfolgen – auch wenn nicht jede Phase die eigene Kernkompetenz ist.

2) Erst die Fragestellung, dann das Tool

• In der Masterarbeit nutzt Claudia R, heute ist viel auf Python migriert. Das zeigt: Tools sind Mittel, nicht Inhalt. Entscheidend ist, dass die Richtung stimmt – Problem, Daten, Auswertung.
• Praxis-Tipp: Toolentscheidungen regelmäßig überprüfen. Nicht „weil schon immer so“, sondern „weil für diese Fragestellung jetzt passend“.

3) Proof of Concept zuerst

• Claudia beschreibt den typischen Research-Start mit Machbarkeitsanalyse. Das schützt vor Verzettelung und schafft frühe Evidenz.
• Praxis-Tipp: Den POC bewusst klein schneiden. Eine Frage, ein Datensatz, ein messbares Kriterium.

4) „Stand der Technik“ ernst nehmen

• „Schauen wir mal, was der aktuelle Stand der Technik ist.“ Das spart Fehler, vermeidet Doppelarbeit und öffnet neue Pfade.
• Praxis-Tipp: Literatur und bestehende Lösungen gezielt screenen – und Notizen systematisch versionieren.

5) Datenlage prüfen – und Partnerschaften pflegen

• „Haben wir genug Daten dafür?“ Oft entscheidet das die Machbarkeit. Claudias Hinweis, „an der Quelle“ zu sein, wenn man mit Krankenhäusern zusammenarbeitet, ist zentral.
• Praxis-Tipp: Datenzugang frühzeitig klären – rechtlich, technisch, organisatorisch. Ohne Daten keine Aussagekraft.

6) Iteration als Normalzustand akzeptieren

• Neue Fragen tauchen während der Arbeit auf – manchmal werden daraus Neben- oder Folgeprojekte. Das ist kein Störfaktor, sondern Teil des Erkenntnisprozesses.
• Praxis-Tipp: Ergebnisse regelmäßig konsolidieren. Aus Nebenprodukten können Plugins, interne Tools oder Publikationen werden.

7) Sichtbarkeit schafft Chancen

• Das Paper, das „im Obermühlviertel“ die Runde macht und in der Zeitung landet, ist mehr als ein Meilenstein – es wird zum Türöffner für die CADS GmbH.
• Praxis-Tipp: Ergebnisse öffentlich machen, wenn möglich: Paper, Blogposts, Demos. Keine Selbstdarstellung, sondern dokumentierte Arbeit.

8) Statistik als Begleiter

• Claudia verknüpft Code mit Statistik „hinsichtlich Paper“. Saubere Auswertung macht Ergebnisse belastbar.
• Praxis-Tipp: Basale Statistik parat haben – und je nach Projekt vertiefen. Analysekompetenz ist ein Multiplikator.

9) Die Freude am Konkreten pflegen

• Das Erlebnis, mit Elektroden Potenziale abzunehmen und eine Handprothese zu steuern, zeigt: Konkrete Anwendungsfälle stiften Motivation.
• Praxis-Tipp: Wenn möglich, Prototypen so bauen, dass ihre Wirkung unmittelbar sichtbar oder messbar ist.

Was diese Geschichte Developer:innen lehrt

Claudias Weg beweist, dass Karriere kein gerader Strich ist. Sie beginnt im Web, schwenkt in die Medizintechnik, vertieft sich in Statistik und Python, baut an patientenspezifischen Implantaten, macht Mikro-CT-Praxis, veröffentlicht, wechselt in die CADS GmbH – und arbeitet dort problemgetrieben an Prototypen, Publikationen und Plugins. Kein Bruch, sondern eine fortlaufende Verdichtung: von „alles ein bisschen gestreift“ zu „gezielt vertieft“.

Für Entwickler:innen ist das eine klare Einladung:

• Folge dem Interesse, nicht dem Etikett. Die Bezeichnung „Researcher“ ist nur ein Rahmen – die Arbeit entsteht aus Fragen.
• Lerne an echten Fragestellungen. Daten, Prototypen, Evidenz – nicht bloß Ideen.
• Verlass dich nicht auf ein Tool. Lass die Problemstellung die Wahl bestimmen.
• Mache deine Arbeit sichtbar. Qualität, die niemand sieht, bleibt oft ohne Wirkung.
• Nimm Rückschläge als Datenpunkt. Was nicht funktioniert, engt den Suchraum ein.

Schluss: Neugier als Methode

Claudia bringt es auf den Punkt: neugierig bleiben, dranbleiben. Das gilt für Programmiersprachen ebenso wie für Forschungsfragen. In „Claudia Wittner, Researcher bei CADS“ (Speaker: Claudia Wittner, Company: CADS GmbH) hören wir eine Laufbahn, die mit HTML/CSS begann und heute komplexe, medizinisch geerdete Fragestellungen bearbeitet – mit derselben Haltung wie am ersten Tag: ausprobieren, lernen, verbessern.

Ihr Weg erinnert uns daran, dass gute Technik aus Fragen entsteht – und dass Antworten selten auf einmal kommen, sondern in einer Folge von Prototypen, Papern, Plugins und Projekten. Genau darin liegt die Professionalität: Schritt für Schritt, mit System, ohne Dogma – und mit genug Neugier, um den nächsten Schritt gehen zu wollen.

• 

  

  Building Products with Purpose

  Lukas Reinauer von CADS spricht in seinem devjobs.at TechTalk wie das Unternehmen das Thema der Produktentwicklung organisatorisch angeht.

  Jetzt ansehen
• 

  

  From Figma to Implementation

  Julian Zauner von CADS zeigt in seinem devjobs.at TechTalk welche Überlegungen hinter den grundlegenden Design Elementen in der Software stecken.

  Jetzt ansehen

• 

  

  Lukas Windner, Division Manager Quality Engineering bei CADS

  Division Manager Quality Engineering bei CADS Lukas Windner gibt im Interview einen Überblick über das Recruiting sowie Onboarding und spricht über den Aufbau der Teams und mit welchen Technologien gearbeitet wird.

  Jetzt ansehen
• 

  

  Dominic Koch, Product Manager bei CADS

  Product Manager bei CADS Dominic Koch erzählt im Interview über die Abläufe im Unternehmen, was Neueinsteiger erwartet und mit welchen Technologien gearbeitet wird.

  Jetzt ansehen

• 

  

  Katharina Freinschlag, 3D Software Entwicklerin bei CADS

  Katharina Freinschlag von CADS spricht im Interview über ihren Weg zur Software Entwicklung, welche Challenges im 3D Development gibt und was ihrer Meinung nach Wichtig für Beginner ist.

  Jetzt ansehen