From Hello World to Hospital Medication Workflows: The Developer Journey of Martin Brandstetter, Full Stack Developer at Meierhofer

Context: A devstory from healthcare software

In “Martin Brandstetter, Full Stack Developer bei Meierhofer,” speaker Martin Brandstetter traces a clear arc—from a curious teenager watching his older brother study at HTL St. Pölten (Informatics) to a full‑stack role in a medication team building core modules for clinical workflows. What stood out to us at DevJobs.at is the way his story fuses two realities: the grounded practice of programming (from the very first “Hello World” to production modules) and direct impact in hospitals, where software touches clinicians, patients, and everyday routines.

Brandstetter keeps everything concrete: how he learned, which languages opened doors for him, the team composition, and the cadence of distributed work. From C and Java at school, through .NET later on, to the day‑to‑day in a medication team within a hospital information system—his story is pragmatic, human, and focused on results.

The spark: curiosity, a role model, and the first lines of code

This journey begins with curiosity—and a tangible role model in his older brother, who completed the same education a few years earlier at HTL St. Pölten (Informatics). That early visibility led to the first hands‑on experiments around ages 13–14: searching, reading, and trying out a “Hello World” program. The door opens not through theory alone, but by compiling something that runs and returns feedback.

This is more than a nostalgic start. It establishes a posture that he later articulates explicitly: don’t wait for perfect conditions—just start. Listening from the sidelines turns into direct experience, and the theory becomes embodied in small, working steps. That’s lesson one of the entire story: practice is the catalyst.

HTL St. Pölten: foundations in C, motivation through Java

Formal structure arrives with HTL. The first language: C. While C wasn’t his personal favorite, Brandstetter emphasizes that it provided “a good foundation and basic knowledge” for programming. That’s exactly what you want from fundamentals: they sharpen your thinking beyond syntax. C demands precision and builds the mental models that later help when combining multiple layers of abstraction.

Java came later—and with it a spike in motivation. The reason: visible results. One assignment stuck with him: programming a traffic light system. For newcomers, that kind of project lands with impact. You see states, transitions, and effects in a direct, visual way; suddenly programming feels concrete. It’s easy to see why he ties motivation to the graphics and visibility of outcomes.

From C to .NET: widening the toolkit

After C and Java, Brandstetter broadened his toolkit. He notes that it later continued “with C., .NET,” adding that .NET ranks among the preferred choices among colleagues. The deeper point is that the path doesn’t hinge on one technology. Instead, experience accumulates across paradigms: fundamentals that hone precision, object‑oriented patterns, and framework ecosystems that accelerate delivery. What matters is not dogma but transfer—building on earlier layers to work effectively in later ones.

Full stack at Meierhofer: working at the heart of clinical workflows

Today, Martin Brandstetter works as a Full Stack Developer at Meierhofer. The product landscape he mentions is focused and interconnected:

• Hospital information system (KIS/KISS)
• Patient data management system
• Modules for OR and emergency department

Within that, Brandstetter is part of the medication team. The goals are concrete and shift real‑world work in clinics:

• Medication search
• Medication management
• Deriving the medication administration for patients
• Creating and printing prescriptions
• Handling interfaces such as e‑card or the electronic health record

Interface work in healthcare demands caution, context, and reliability. That’s what “full stack” means in this context: not just UI or database, but the complete process working end‑to‑end—including regulated, cross‑system interactions.

Scrum, team composition, and locations: collaboration without borders

Brandstetter describes the Scrum team as “well positioned,” with collaboration spanning sites and countries. The structure he outlines:

• Nine developers, two of them part‑time
• One tester
• One Scrum Master (female)
• One Product Manager (female)

Geographically, the team is distributed: Munich and Berlin are named as sites, and colleagues in Germany also work remotely from home. In Austria, Meierhofer has two sites—Graz and St. Valentin. Graz has “a developer colleague” newly on board; St. Valentin has three people at the moment, including Brandstetter himself. There he’s joined by a database specialist who is also an architect, plus a front‑end specialist for web applications.

For us, this snapshot captures modern product development: domain‑focused in Scrum, purposefully hybrid, and intentionally role‑diverse. In a medication domain—where quality, safety, and clarity matter—the explicit roles for testing, Scrum, and product management are not administrative details; they’re the scaffolding for quality and focus.

Flexibility by design: remote rhythm, equipment, communication—and the Flexi‑Desk

The day‑to‑day is defined by flexibility, and Brandstetter makes that specific:

• Working two to three days from home is possible—not just for him, but for colleagues in Germany and Austria as well.
• The technical setup is solid: “We have great work devices and communication works very well across countries.”
• St. Valentin uses a Flexi‑Desk system: set up your desk in the morning, clear it in the evening—sit somewhere else the next day.

It’s pragmatic and it works. Brandstetter points out that this reduces monotony—a fitting complement to the evolving nature of hospital processes. When day‑to‑day environments change, it helps if teams are accustomed to changing patterns too. In that sense, flexibility here isn’t just a “benefit,” but a working principle that keeps product development fresh and responsive.

Why it never gets boring: evolving processes as a driver

“Never boring”—that’s not a slogan in this domain, but a direct effect of changing processes in hospitals. What’s standard today might require a new interface logic tomorrow, a different user presentation, or an improved flow in medication management. For full‑stack work, that translates to proactive thinking, flexible prioritization, and precise scoping—while keeping the whole system in view.

In the medication team, the requirement chain is tangible: from the first search query to a printed prescription. Every step calls for reliability, traceability, and smooth handoffs. That’s what keeps the work interesting—and it connects back to why visible results (already in school) boosted Brandstetter’s motivation.

Learning that sticks: “Learning by doing” as a throughline

Asked how to start in programming, Brandstetter keeps it simple: “You have to try it to learn it—learning by doing.” His advice, especially for beginners:

• Don’t pre‑filter yourself by chasing “top three languages” lists.
• Don’t let rankings exclude options that might actually fit you.
• Compile and run small programs—like “Hello World”—to learn the full loop.

Even the simplest program introduces real frictions: dependencies, missing local packages, build tools, paths. That friction is the learning. Make it a routine and you build operational confidence—the kind you need later in larger systems.

Staying current: videos, forums, books—and your own tempo

How does Brandstetter keep up to date? He names three complementary channels:

• YouTube channels by full‑stack and web developers
• Sites and forums such as Stack Overflow
• And for those who learn differently: books—when having something to hold and read matters

Again, the message isn’t dogmatic: pick channels that fit you. The key is to keep trying and to dare. Combining visual formats, discussion forums, and deeper reading is a reliable way to stay current without falling into hype cycles.

Craft, posture, leverage: what we at DevJobs.at took away

From Brandstetter’s path, we distilled core points that travel well beyond this specific context. They speak to newcomers and experienced engineers alike—especially those building in regulated domains.

1) Start small—but make it real

A “Hello World” isn’t trivial. It’s an end‑to‑end loop: editing, compiling, resolving dependencies, executing, and seeing results. Take that loop seriously; it becomes the backbone of every future feature.

2) Fundamentals sharpen your senses

C wasn’t his favorite, but it built a good foundation. In complex systems, that foundation pays off. Knowing what abstractions sit on top of helps you build resilient bridges into frameworks and APIs.

3) Visible results drive motivation

The traffic‑light assignment stands as a metaphor. When results are visible, momentum follows. It also trains thinking in states and transitions—the heart of building software.

4) Technologies are tools—not identity

C, Java, .NET: breadth matters more than labels. Teams that match tools to problems stay nimble—an advantage when processes (like in hospitals) evolve continuously.

5) Cross‑site works—with clear roles

Nine developers (including part‑time), plus testing, Scrum, and product roles: that balance enables speed, quality, and focus. Distributed teams work when expectations, handoffs, and communication are explicit.

6) Flexibility is a design choice

Remote rhythm, good devices, healthy communication, and a Flexi‑Desk habit—this isn’t just convenience. It ritualizes variation and keeps collaboration fresh.

7) “Dare to try” beats “top three lists”

If you start with rankings, you limit yourself too early. If you start by trying, you discover what actually fits. That posture accelerates progress and avoids getting stuck at the surface of hype.

Practical steps for beginners

Translating Brandstetter’s advice into small, concrete moves:

• Install a development environment and run a small program locally. Feel the path from code to result.
• Note your stumbling blocks (dependencies, paths, packages). Solve them once—understand them for good.
• Pick a task with visible results (e.g., a small state model like a traffic light). Motivation and understanding feed each other.
• Add two learning channels: one visual (YouTube) and one discussion forum (Stack Overflow). Look things up when you get stuck.
• Don’t lock in too early. If a language or framework catches your curiosity, try it—without ranking bias.

These steps reflect exactly what Brandstetter emphasizes: learning through doing. Each small “it works” compounds into the confidence you need for complex flows later on.

Team dynamics in the medication module: why role diversity matters

The “medication” product area keeps showing up in Brandstetter’s account because it bundles multiple requirement types:

• Domain correctness (e.g., management, administration, prescription printing)
• Technical integration (interfaces like e‑card and the electronic health record)
• User‑centric impact (making clinicians’ daily work easier)

The clearly named roles—testing, Scrum, product—fit this blend. Quality assurance, pacing, and prioritization become first‑class concerns. For full‑stack work, end‑to‑end thinking isn’t optional; it’s the default—from data models to user interfaces and back.

Working across locations: trust, rhythm, equipment

According to Brandstetter, cross‑country collaboration “works super”—and we’ll leave that phrasing as is. It signals that a mix of good devices, reliable communication, and steady rhythms can connect a team spread across Munich, Berlin, home offices in Germany, and Graz and St. Valentin in Austria.

The Flexi‑Desk approach in St. Valentin is a telling detail: it enforces order and encourages mobility even inside the office. More than a logistical quirk, it instills a habit where change is normal—a quiet but effective catalyst for product teams.

Lines that linger

Several lines from Martin Brandstetter’s talk distill his devstory into memorable cues:

These are practical mantras. They celebrate iteration over perfect planning.

Closing: Impact through craft and posture

“Martin Brandstetter, Full Stack Developer bei Meierhofer” reminds us at DevJobs.at how solid developer journeys often unfold: become curious, try things, invest in fundamentals, cultivate motivation through visible results—and then scale the approach in teams with clear roles and good tools. In a domain like hospital IT—where processes evolve and precision is non‑negotiable—that mix is doubly powerful.

Brandstetter’s devstory shows that “full stack” isn’t a buzzword. It’s a willingness to own the entire flow—from a medication search to a printed prescription; from the local dependency you hit in “Hello World” to a production interface with an electronic health record. Think that way, and you stay open, learn fast, and deliver software that makes a difference in day‑to‑day clinical work.

• 

  

  Harald Leitner, Back End Developer bei Meierhofer

  Harald Leitner von Meierhofer erzählt im Interview über den Weg von seinen frühen Anfänge im Programmieren bis hin zu seiner aktuellen Arbeit und gibt Tipps für Neueinsteiger.

  Watch now