From BASIC to Principal Developer: Roman Brandstetter at RUBICON IT GmbH on Education, Teamwork, and Quality

The spark that stuck: Why Roman’s path resonates

At DevJobs.at, we gravitate to stories where an early spark becomes a lifelong engine. That’s exactly how Roman Brandstetter tells it. His programming journey began in middle school with a class and with BASIC. He loved computer games and asked the obvious question: How is this built? That curiosity turned into a stance that keeps showing up across decades: try, learn, keep going.

One detail gives this early phase its edge: “Google didn’t exist.” Still—maybe even because of that—Roman kept moving, switched to C and C++, and doubled down on hands-on exploration. The pattern is consistent: interest, experimentation, persistence.

From classroom to Master’s: Why formal education matters

Curiosity was followed by structure. Roman went to ATL and then to Technikum, where he completed his Master’s in Software Engineering. After that, he tried a few jobs and then joined RUBICON—where he’s stayed. Thirteen years, one team, one product—and the entire development pipeline.

Our takeaway: self-study is a powerful motor, but it’s not the whole engine. As Roman puts it, self-study is “important and good, but not everything.” Professional education adds depth, formality, and the tooling to build and evolve complex systems responsibly.

Early career: Detours that lead somewhere

After his Master’s, Roman explored different roles—a phase of testing assumptions and building experience. Eventually, he found the continuity many developers seek: a long-term role at a company where you can truly understand and shape a product. At RUBICON, he’s been doing just that for 13 years. That kind of tenure isn’t an end in itself; it enables a different level of accountability—talking to customers, conceiving features as a team, implementing them, and pitching in on testing.

To us, this phase of Roman’s path underlines a bigger point: once you carry product responsibility, depth beats breadth. Living with a product over years exposes you to code, yes, but just as much to domain logic, user needs, and quality constraints. That perspective shapes everything that follows.

End-to-end responsibility: Customer, concept, implementation, test

Roman describes a developer role we consider future-proof: someone who doesn’t stop at API boundaries but understands the full lifecycle.

• Customer conversations: “Upfront I sometimes talk to customers about how things should work.”
• Team conception: “Then we conceive the individual features together as a team.”
• Implementation: “And at some point it goes into implementation.”
• Testing: “And now and then you also help with testing. For me, that’s part of it.”

This approach blends three qualities: context, ownership, and quality. Context because you understand why a feature exists. Ownership because you help shape decisions. Quality because you accept responsibility for testing. It’s a mindset: software is more than code; it’s the outcome of a process with many participants.

Testing as a stance: Quality is a team sport

Roman puts it plainly: “If you build software, it needs to be tested, and you want to know whether it works and fits.” That’s not shifting QA responsibility; it’s an understanding of quality. If you talk to customers and help design features, you don’t test just to catch defects—you test to confront the original idea with reality. Does it fit? Does it really work?

We’ve seen this across strong teams: quality is distributed. Testing isn’t an end-of-line step; it’s part of the developer’s craft. That’s how robust, maintainable products emerge.

Side by side at one PC: Learning that happens every day

One scene from Roman’s story sticks: “it’s completely normal that people sit together at one PC.” That’s more than a working mode; it’s a learning culture. You build together, watch each other, explain, ask, and adjust—without hierarchy getting in the way.

The “fresh wind” that juniors bring isn’t a platitude here; it’s a daily mechanism. When newcomers show new ideas and tools, and they meet a team where openness is the norm, modernization happens organically.

Openness as a practice: Let the new in, honor what works

Roman keeps returning to the mix: interest, experimentation, openness. That applies to free-time tinkering just as much as to product work—trying out new features or ideas in a controlled, real-world context.

We read this as a pragmatic growth path: fewer big-bang changes, more continuous steps. Experiment along real tasks, and you’ll learn faster, more sustainably, and in ways your product can immediately absorb.

The developer profile that emerges

From Roman’s words, a clear profile takes shape:

• Curious: Starts with “How do you make that?” and keeps asking.
• Structured: Formal education amplifies, not replaces, hands-on practice.
• Team-oriented: Collaboration is the norm, not the exception.
• Holistic: From customer conversations to testing—the whole pipeline counts.
• Open to learning: Try new things, learn from juniors, embrace fresh inputs.

This isn’t an idealized persona; it sounds like lived reality—and explains why a 13-year product journey reads like continuous evolution, not stagnation.

Actionable takeaways for developers

Roman’s story translates into pragmatic guidance you can apply immediately:

1. Let curiosity lead—but give it structure.

• Self-study powers you forward, but “professional Software Engineering education is very important.” Theory and practice reinforce each other.

1. Choose environments where collaboration is default.

• Where it’s “completely normal to sit together at one PC,” learning is built into everyday work.

1. Follow features end to end.

• The more lifecycle stages you touch, the stronger your architectural and implementation decisions become.

1. Keep seniority humble—value upward and downward learning.

• Juniors bring “fresh wind,” seniors bring pattern recognition. The best work happens where both are welcome.

1. Experiment in small, real steps—in the product and in your free time.

• Favor experiments tied to real tasks. It keeps skills relevant and transferable.

Signals for teams and organizations

Roman’s path also offers clear signals for engineering leaders:

• Make collaboration the norm
• Create spaces and rituals where working at the same machine is expected rather than exceptional.
• Enable two-way learning
• See juniors as impulse givers; set up formats where they can “show new things” from their studies.
• Live end-to-end accountability
• Bring developers into customer conversations, co-own feature conception, treat testing as a team responsibility.
• Support education explicitly
• Encourage and fund structured learning so theory connects to product reality.
• Protect curiosity
• Provide time and room to try things—ideally tied to real features, not isolated sandboxes.

Our perspective on “Roman Brandstetter, Principal Developer bei RUBICON”

In the session “Roman Brandstetter, Principal Developer bei RUBICON” (Speaker: Roman Brandstetter, Company: RUBICON IT GmbH), we got a compact yet rich picture of a developer’s journey: early BASIC, later C and C++, an intentional path into professional education, a pragmatic transition into industry, and then a long, responsible stretch within one team and product.

What stood out to us:

• “You are a developer to a certain extent”: talent or inclination is there; education makes it productive.
• The matter-of-fact attitude toward testing—“that’s part of it”—signals shared ownership of quality.
• The normalcy of “sitting together at one PC” points to a mature collaboration culture.
• Valuing “fresh wind” from juniors shows how stability (13 years on a product) and renewal can reinforce each other.

Quotes and ideas worth keeping

A few lines make for reliable signposts. We wrote these down:

Together, they form a compact set of principles: take your talent seriously. Embrace education. Practice collaboration. Own quality. Keep curiosity alive.

Turning insights into routines

To make these ideas stick, practical routines help:

• Weekly learning sessions
• 60 minutes for someone to “show things”—including juniors bringing ideas from their studies.
• Systematize working together
• Fixed time blocks at one machine for knowledge transfer and code polish.
• Make end-to-end visible
• For each feature, keep short notes: customer intent, team concept, implementation, testing observations.
• Blend learning paths
• Small self-study experiments + targeted courses; bring outcomes back into the product.
• Bake testing into everyday work
• Combine code reviews with functional checks; walk acceptance criteria together.

All of these are small enough to start tomorrow and big enough to compound within months.

Closing: A path that proves itself by staying open

Roman’s journey isn’t spectacular in the loud sense. It’s remarkable in the reliable sense: started early, chose education deliberately, stayed the course, embraced teamwork, and took responsibility for quality. The result is the kind of professionalism that serves customers, colleagues, and products.

Our conclusion: if you nurture interest, choose solid education, embrace the full development lifecycle, and remain open to new ideas—whether from juniors or your own experiments—you create the conditions for a long, fulfilling career in software development. That is exactly what Roman Brandstetter’s path at RUBICON IT GmbH illustrates.

• 

  

  Capture Screenshots with Playwright & SpecFlow

  Hannes Etl von RUBICON IT spricht in seinem devjobs.at TechTalk über die Aufgabe, mit Playwright und SpecFlow eine große Zahl an Screenshots automatisiert zu erstellen und zu verwalten.

  Watch now
• 

  

  Retargeting einer Anwendung mit ASP.NET Web Forms auf .NET 8

  Michael Ketting von RUBICON IT zeigt in seinem devjobs.at TechTalk wie man eine saubere Migration von Web Forms auf .NET 8 durchführt und welche Vorteile dies für ein Dev Team mit sich bringt.

  Watch now

• 

  

  Dagmar Pill, Abteilungsleiterin & Sabine Eder, Abteilungsleiterin bei RUBICON IT

  Dagmar Pill und Sabine Eder von RUBICON IT sprechen in ihrem Interview über die Besonderheiten der Teams im Unternehmen, auf was beim Recruiting und Onboarding geachtet wird und welche Challenges es bei der Software Entwicklung gibt.

  Watch now

• 

  

  Stephan Palecek, Senior Deployment Engineer bei RUBICON IT

  Stephan Palecek von RUBICON IT redet im Interview von den frühen Anfängen mit BASIC, über seine Ausbildung, bis hin zu seiner aktuellen Arbeit und gibt Hinweise für Deployment Engineering Einsteiger.

  Watch now
• 

  

  Mathias Gartner, Lead Developer bei RUBICON IT

  Mathias Gartner von RUBICON IT redet im Interview über seine Anfänge in der Technik bis hin zur aktuellen Arbeit und teilt seine Gedanken, wie man am besten in die Software Entwicklung einsteigt.

  Watch now
• 

  

  Peter Gößweiner, Lead Developer bei RUBICON IT

  Peter Gößweiner von RUBICON IT erzählt in seinem Interview von den spielerischen Anfängen als Kind und über seinen weiteren Werdegang – und was das Wichtigste für Neueinsteiger ist.

  Watch now
• 

  

  Rene Sorger, Junior Full Stack Developer bei RUBICON

  Rene Sorger von RUBICON redet in seinem Interview von seinem frühen technischen Interesse als Kind bis hin zu seiner aktuellen Arbeit als Full Stack Developer und gibt Tipps für den Einstieg.

  Watch now