From HTML in high school to patient‑specific implants: The research journey of Claudia Wittner at CADS GmbH

Introduction: A developer’s path powered by curiosity

In “Claudia Wittner, Researcher bei CADS,” speaker Claudia Wittner (CADS GmbH) walks us through her trajectory from first web pages in school to research on patient‑specific implants and software prototypes. At DevJobs.at, we listened closely as she stitched together a career from small, consistent steps: early web tinkering, a decisive move into medical engineering, statistics, Python, Micro‑CT, a paper that made waves—and then a research role where every project starts with a question and a feasibility check.

The through‑line is steady: follow the interest. What began as creative exploration on the web matured into structured work with code, data, and signals—right through to peer‑reviewed publication. For developers, the takeaways are clear: see projects end‑to‑end, prototype fast, survey the state of the art, validate your data, iterate deliberately, and keep going when the first version doesn’t work.

First touchpoints: Media informatics and design, and the freedom to build

Around age 14, Claudia got her first taste of what would become her professional home. In a HLW focused on media informatics and design, she dove into HTML and CSS, touched JavaScript, linked databases, and skimmed PHP. The scope was broad—“everything a bit,” as she puts it. The critical insight was that technology is a creative space.

She built early websites without strict templates—projects where she could decide everything herself. That freedom mattered. It revealed two qualities that run through her story: the willingness to try before everything is perfect, and the joy of blending creativity with tech. In our view, that combination sits behind many durable developer careers: curiosity plus execution.

A deliberate turn: Leaving media for medical engineering

After HLW, Claudia re‑evaluated. She didn’t want to stay in media. She looked around: Which universities of applied sciences are out there? Which programs in Austria? She visited Hagenberg and Linz and ultimately settled on medical engineering at the FH Linz. “I’ll just try it,” she says—a grounded beginning with an open outcome. That pragmatism matches the research mindset she later describes.

What followed was a quick expansion of skills, especially through the informatics track: “You learn all the basics … and relatively fast everything goes uphill.” The learning curve steepened, the tasks became more medical. Interest was there—and grew with the work.

Learning that connects to the body: Biomechanics, electrodes, and a prosthetic hand

A defining hands‑on moment came when biomechanics met body signals. Claudia worked with electrodes to capture potentials and used them to control a hand prosthesis. The code was tangible: input signals, processing, control logic. Informatics suddenly had immediate, physical effect. “That was mega exciting,” she says—you can hear how real‑world feedback fuels motivation.

For us, that’s a powerful lesson about developer growth: real signals, real users, real impact. Nothing accelerates learning like systems that actually do something you can see or feel. This is engineering as application—not just syntax but effect.

Python becomes the first true favorite—alongside statistics

Python appeared late in the bachelor and deepened in the master. By then, “a programming language really grew on me,” Claudia says—Python became her go‑to. At the same time, statistics took center stage. That adds up: research needs hypotheses, measurements, analysis. She was already thinking “in terms of papers,” and that blend of usable code plus solid methodology would later underpin publications, prototypes, and product ideas.

Master’s thesis: Patient‑specific cranial implant planning—R then, more Python now

The master’s thesis marked another milestone: patient‑specific cranial implant planning. Claudia completed it in R—while noting that this space is now “strongly being replaced” by Python. She touched on geometric morphometrics and pointed out that the same work can run in Python.

What struck us was the emphasis on problem first, tool second. The tool can change; the systematic handling of data, models, and analysis stays in focus. That’s a healthy bias for a research role.

Research you can touch: Micro‑CT at the FH in Wöss—owning the whole pipeline

After the thesis, Claudia stayed in research at the FH in Wöss, within a micro‑CT research group. She ran scans on various CT devices herself, segmented manually—at the time even with a drawing tablet—and took the work all the way through analysis to a paper. “I could go through the entire path myself,” she recalls. That end‑to‑end responsibility is rare—and invaluable.

Anyone who has owned a pipeline from physical object to scan, segmentation, data prep, analysis, and publication develops a feel for where quality is created—and where it can get lost. For technical careers, that awareness is gold. Early assumptions ripple through to final results.

From paper to opportunity: Visibility opens doors

The research led to a paper—and it circulated “in the Obermühlviertel,” even landing in a local newspaper. Friends reached out, and a fellow student already at CADS GmbH asked the simple question: “Would you like to start?” The chain is straightforward: good work → visible work → opportunity.

For developers, that’s a strong encouragement: don’t hide your results. Visibility doesn’t replace competence—yet it expands the radius of your impact. Claudia’s path to CADS GmbH began right there.

The role at CADS: Start with a problem, build a prototype, iterate

Claudia’s title is “Researcher,” but the working mode is what matters. “You always start with a problem,” she says. It may come from inside the company (“can we solve this?”), or through funded collaborations—she mentions a cooperation with Carlos Martin. Often, the “software solution ends up with us,” including a “concrete question” from the start.

Her process has a clear cadence:

• Organize the data: What do we have? What’s missing? How do we structure the dataset?
• Feasibility first: “Proof of concept, does this work—then we continue.”
• Survey the state of the art: “What’s the current state of the art?” How did others solve this?
• Validate the data situation: “Do we have enough data for it?”—being “close to the source” helps “when collaborating closely with hospitals.”
• Build a first prototype: “an initial track … first results.”
• Iterate: As you go deeper, new questions appear—often seeds for follow‑up or side projects.

Outcomes are open‑ended: “Sometimes it’s a software application, a plugin, and sometimes it’s simply a publication or a by‑product of a publication.” Research “should live for this,” she notes—stay curious and let the work surface new directions.

What stands out: Method without dogma

Claudia describes a culture that is pragmatic and clean. There’s no tool dogma, no over‑engineering. Instead: clarify the data, understand the state of the art, prove feasibility, then refine step by step. This pattern is universal—be it medtech, web, or embedded.

We especially noted her comfort with imperfect intermediates. A prototype isn’t a product—but without a prototype, there is no product. Manual segmentation is tedious—but it informs future automation. A publication is work—but it brings clarity and visibility. Claudia’s trajectory shows that each stage has a purpose.

Advice that travels well: Curiosity, courage, perseverance

Claudia’s guidance is simple—and powerful:

• Find a topic that truly interests you: “Then everything gets easier.” Interest carries you through the dry spells.
• Try new things: “Don’t shy away from trying something new.” Doing begets judgment.
• Expect setbacks: “Things won’t work at times.” Knowing “that it doesn’t work—and how it doesn’t work” already brings you closer; often you’re “just about to solve it.”

Translated to developer routines: a new language, a new domain, a new stack—they all follow the same curve. First friction, then familiarity, then fluency. You can’t bypass it, but you can shape it—by staying curious and staying with it.

Practical takeaways for developers and researchers

Claudia’s story yields concrete patterns you can apply across domains.

1) Think end‑to‑end—own the pipeline at least once

• Micro‑CT scans, manual segmentation (drawing tablet), analysis, paper—Claudia’s path sharpened her sense of quality across the chain.
• Practice tip: whenever possible, follow a project from raw input to final results at least once—even if parts sit outside your core specialty.

2) Problem first, tool second

• Claudia used R for her thesis; now much of that work is shifting to Python. Tools are means, not ends.
• Practice tip: revisit tool choices regularly. Not “because we always did it this way,” but “because this fits this question right now.”

3) Start with feasibility

• The research flow at CADS begins with a proof of concept. That protects you from sprawling too early and yields early evidence.
• Practice tip: keep the PoC minimal. One question, one dataset, one measurable criterion.

4) Take the state of the art seriously

• “Let’s see the current state of the art.” That prevents reinvention, reveals blind spots, and opens paths.
• Practice tip: systematically capture what you read and test—notes, references, and small experiments.

5) Validate the data—and invest in partnerships

• “Do we have enough data?” often decides feasibility. Claudia notes the advantage of being “closer to the source” when collaborating with hospitals.
• Practice tip: clarify data access early—legally, technically, operationally. Without data, you don’t have conclusions.

6) Normalize iteration

• New questions appear mid‑flight—and sometimes become side or follow‑up projects. That’s not noise; it’s the insight engine at work.
• Practice tip: schedule regular consolidation. Side products can turn into plugins, internal tools, or publications.

7) Visibility creates opportunity

• The paper that circulated in the Obermühlviertel and made the newspaper ultimately opened the door to CADS GmbH.
• Practice tip: share results when possible—papers, blog posts, demos. Not self‑promotion, but documented work.

8) Keep statistics close

• Claudia paired code with statistics “in terms of papers.” Sound analysis makes results robust.
• Practice tip: know your basics and deepen as projects demand. Analytical competence multiplies impact.

9) Stay close to tangible impact

• Capturing potentials with electrodes and controlling a prosthetic hand underlined the power of concrete use cases.
• Practice tip: design prototypes so their effect is visible or measurable as early as possible.

What this story teaches developers

Claudia’s path shows that careers aren’t straight lines. She started on the web, pivoted into medical engineering, deepened statistics and Python, worked on patient‑specific implants, practiced micro‑CT end‑to‑end, published, and joined CADS GmbH—where work starts from a problem and grows into prototypes, publications, or plugins. Not a break, but a steady condensation—from “touched everything a bit” to “deliberate depth.”

For developers, this is a clear invitation:

• Follow the interest, not the label. “Researcher” is a job title; work emerges from questions.
• Learn on real problems. Data, prototypes, and evidence beat abstract speculation.
• Don’t wed yourself to a tool. Let the problem decide.
• Make your work visible. Quality that no one sees rarely creates opportunities.
• Treat setbacks as data points. Knowing what doesn’t work narrows the search space.

Closing: Curiosity as a method

Claudia’s summary resonates: stay curious and keep going. That applies to programming languages just as much as to research questions. In “Claudia Wittner, Researcher bei CADS” (Speaker: Claudia Wittner, Company: CADS GmbH), we hear a journey that starts with HTML/CSS and now tackles complex, medically grounded problems—guided by the same habit as on day one: try, learn, improve.

Her trajectory reminds us that good engineering grows from good questions—and that answers rarely arrive all at once. They surface through a sequence of prototypes, papers, plugins, and projects. That’s the professional craft: step by step, with method, without dogma—and with enough curiosity to take the next step.

• 

  

  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.

  Watch now
• 

  

  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.

  Watch now

• 

  

  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.

  Watch now