From Commodore 64 to Lead Developer: Peter Gößweiner of RUBICON IT on Learning, Architecture, and Growing Teams

Why this story matters: our takeaways from “Peter Gößweiner, Lead Developer bei RUBICON IT”

When we recorded the session “Peter Gößweiner, Lead Developer bei RUBICON IT,” it quickly became clear we were listening to someone who doesn’t just practice software development—he genuinely enjoys it. Peter Gößweiner, Lead Developer at RUBICON IT GmbH, traces a path from a wide-eyed kid watching a computer respond to code, to an architect who makes the final calls and a team lead who grows people. What stood out is the grounded candor: no buzzword fireworks, just clear insight into motivation, learning, and responsibility.

His message is consistently human and pragmatic: find joy in the work, stick with it, and build confidence through small, safe steps. That’s the foundation for a durable career. Also: if you’re motivated, you’ll get a chance. That ethos runs through his story and makes the session compelling for anyone seeking their place in tech—or looking to deepen it.

Childhood with a Commodore 64, Amiga, and Pentiums: curiosity as a driver

Peter begins in Styria. His father brought home the early machines: Commodore 64, Amiga, later the Pentium generations. One scene sticks: a kid peering over his father’s shoulder while “he enters some code and then something comes out on the computer.” It’s playful rather than academic, but it plants the seed many developers recognize: software as a space where input turns into visible impact.

The curiosity was there before the career path. Peter emphasizes that as a child, it wasn’t “hardcore programming.” The crucial experience wasn’t complexity; it was plasticity—the realization that digital tools can be shaped. That idea will later anchor his identity as an engineer: development as the craft of bringing possibilities to life.

Non-technical schooling—and an early taste of “doing more”

Peter is frank about his formal education not being technical at first: primary school, secondary school, then a business-focused Handelsakademie. In the third year he switches into an IT track—not into languages and algorithms, but into Access and Excel programming. What others might dismiss as “just Office” triggers a central insight: applications aren’t only for use—they can be extended.

He describes how simple UI actions fascinated him: inserting buttons, clicking them, executing logic—things “not possible with the standard application.” That is more than a nice aha moment. It marks the shift into systems thinking: state, events, effect. Internalize that, and it’s easier to progress toward class and component design, and eventually architecture—all of which will become part of his remit as Lead Developer.

The first job felt wrong—so he changed course

After finishing the Handelsakademie, Peter didn’t immediately go into tech. He took an office job. Within “a month or two,” he knew something was missing: “the connection with the computer.” It’s a familiar feeling for anyone who has ever landed in a role that doesn’t align with their internal drive. What matters is what he did next: not just leaving, but realigning.

He moved to Vienna, completed a Bachelor’s degree in Computer Science, then a Master’s. The decision wasn’t only academic; it was about identity—about letting personal drive (“I want to work with computers”) and formal qualification reinforce each other. His subsequent career confirms the choice: theory as foundation, practice—projects, teams, decisions—as the structure built on top.

15 years in software, 12 at RUBICON IT GmbH: a path in deliberate stages

Asked how one becomes a Lead Developer, Peter stays calm and precise: it’s a process. He’s spent 15 years as a software developer, twelve of them at RUBICON IT GmbH. The path follows the classic progression: Junior Developer, Developer, Senior Developer, then Lead Developer. Nothing about it feels rushed. It’s the accumulation of learning curves, growing responsibility, and mutual trust.

We were struck by how deliberately he credits the middle steps. As a junior, you get “small projects where you can experiment, where you have a bit of safety, where not much can go wrong.” These safe spaces are not a nice addition—they are essential. They let you make mistakes, test hypotheses, and build self-confidence—the foundation for later decisions on class design, component boundaries, and, eventually, system architecture.

From classes to architecture: how responsibility grows with experience

As the years pass, Peter’s focus shifts: from local design to system boundaries, from components to interactions, from implementation to operations. He frames it succinctly: “You start with class design and how you build components, and move up to architecture.” In the lead role, that consolidates into ownership of the “final decision on architecture,” on project design, and on how the software will run in production.

That naturally includes choosing technologies: “Which technologies should it be.” Here, Peter’s stance is pragmatic. It’s less about trends and more about fit, operability, and maintainability. Technology is a means; decision quality is the end; responsibility sits with the role that makes the call.

Lead Developer as coach: enabling people, leveraging strengths, making progress visible

Alongside architecture, Peter’s second area is people development. His team includes juniors, developers, and testers. The goal is clear: “My task is to develop them as best as possible.” Coming from someone who walked that exact path, the statement carries weight.

He calls out the challenge of recognizing each person’s strengths and “bringing them out in the best possible way.” When that works, engagement rises, “it bears fruit,” and the team builds “extremely cool things.” That’s more than a feel-good sentiment. It’s actionable: good leadership is less about top-down directives and more about enabling. Give people room and grow with them.

“The most important thing is that it’s fun.” Motivation as long-distance fuel

Few lines distill Peter’s attitude as well as:

This isn’t fluff. He ties joy in the craft to resilience in hard moments. He recalls his very first lecture at the university of applied sciences:

He stayed with it—not because it was easy, but because the work itself is rewarding. That’s the bridge to his advice for career changers: joy, curiosity, persistence.

Learning today: blogs, podcasts, videos—accessible and powerful

Peter emphasizes how straightforward it is today to get into technology: “There are so many blogs, podcasts, and online videos.” The value isn’t just quantity; it’s access. If you want to sample a domain, you can start small. If you want to go deep, there are endless paths. That builds self-efficacy, a core resource for anyone entering or re-entering tech.

His advice is as simple as it is effective: stick with it. Learning is less a sprint than a cadence. Small, regular steps beat grand, sporadic plans. That mirrors his own trajectory—from playful experiments to Access/Excel logic, all the way to architecture decisions in production systems.

No fear of non-linear paths: “Just try it—that’s the most important thing.”

Peter’s encouragement to those without a conventional technical background—e.g., no HTL—is unambiguous:

It’s not a platitude; it’s consistent with his biography: business school, a detour into an office job, then a decisive pivot and targeted upskilling. With motivation and enjoyment, you can make up for missing foundations.

Recruiting at RUBICON IT GmbH: motivation over labels

Peter gets specific on recruiting. At RUBICON IT GmbH, “everyone gets a chance” in interviews. It’s not restricted to graduates of HTL, Technikum, a university of applied sciences, or a university. What matters is how you show up, your motivation, and how you perform in the conversation.

That stance is demanding to live by—and precisely why it’s valuable. Potential-based hiring requires teams and leads who provide developmental runway. Peter names that as a core part of his lead role. It closes the loop: if you grant opportunity, you need to grow people as well—and when you do, engagement rises and outcomes improve.

What helps juniors thrive: small projects, clear goals, safe spaces

We found Peter’s description of junior onboarding and growth especially apt. Small, contained projects help people build “safety.” The point is to limit risk without limiting learning. The success factors in this phase include:

• clear, achievable goals that yield fast wins,
• visible impact (a feature you can demo or a process that clearly improves),
• pragmatic feedback that helps without overwhelming,
• a frame in which mistakes are allowed and expectations are explicit.

These ingredients accelerate confidence—the basis for transitioning from component-level thinking to architectural reasoning.

Architecture as decision craft: from code to responsibility

When Peter talks about having the “final decision on architecture,” we hear two things: technical sovereignty and responsibility. Architecture here isn’t an ivory tower. It’s the set of lines that guide design, operations, and technology. The questions his story implies include:

• Does the chosen technology fit the problem and operations context?
• Does the design support evolvability for the whole team—including juniors and testers?
• Are class and component responsibilities cut to localize change?
• Is the software’s runtime considered—stability, monitoring, maintainability?

These answers aren’t fixed in textbooks. They arise from experience, team dynamics, and a lived quality culture.

Mentoring with strengths: why teams learn faster when leadership listens

Peter’s emphasis on strengths stands out. Good leadership recognizes patterns: how does each person learn? Where are their anchors to build on? Especially in teams with juniors, developers, and testers, diversity of experience is an asset—if you use it.

Practically, a strengths-based approach looks like this:

• Tailor tasks to the “optimal stress zone”—challenging but not overwhelming.
• Make wins visible and celebrate them to grow sustainable motivation.
• Keep feedback concrete and tie it to next steps (“What should I do differently now?”).
• Keep roles permeable enough to allow people to step out of their comfort zone.

These principles may sound unglamorous, but they often decide whether a team compounds its learning—or stalls.

Organizing learning: turning blogs, podcasts, and videos into progress

Peter’s point about abundant online resources is a prompt to structure them intentionally. In the spirit of his advice, we suggest simple, disciplined routines:

• a weekly learning block (e.g., 2×45 minutes) with a clear goal,
• one “small project” per month to make a new technique or architectural pattern tangible,
• peer exchange in the team: short show-and-tell to anchor new insights,
• a personal digital notebook to capture takeaways in your own words.

These habits support the “stick with it” approach Peter emphasizes—and convert scattered resources into measurable progress.

Interviewing with intent: show motivation, evidence learning

If “everyone gets a chance” at RUBICON IT GmbH, the interview focus shifts: less on formal credentials, more on motivation and demonstrable learning. Candidates can make this tangible by bringing:

• examples of self-initiated learning (mini projects, exercises, prototypes),
• reflections on mistakes and what changed afterward,
• clear explanations of design decisions—even for small assignments,
• curiosity in question form: “How would you prioritize…?”, “What do you watch for in operations?”,
• an evident interest in team dynamics: “How do you support juniors day-to-day?”

This signals that you’re not just reciting knowledge—you’re exploring potential together, which mirrors the leadership ethos Peter describes.

Three themes from Peter Gößweiner’s journey

From “Peter Gößweiner, Lead Developer bei RUBICON IT,” three themes keep surfacing:

1) Joy as a stabilizer: When you enjoy the work, you endure the hard patches and keep showing up. Peter’s career shows that joy isn’t a luxury—it’s a power source.

2) Safety through small steps: Juniors grow in safe spaces. Start small, build solidity—then scale responsibility.

3) Leadership as enablement: Make architectural calls, grow people, leverage strengths—that’s how “extremely cool things” happen.

Quotes worth keeping

Several of Peter’s lines capture his view of work and learning:

These aren’t just encouraging. They define a culture where learning, responsibility, and teamwork reinforce each other.

Practical next steps inspired by the session

Turning Peter’s story into action—without fluff, in his pragmatic spirit:

• Pick a mini project you can finish in two weeks. Build a small feature that creates obvious value. Document what you decided and why.
• Practice “architecture in the small”: sketch components, responsibilities, and dependencies—even for small tasks.
• Seek targeted feedback. Ask for input on design, readability, and testability—and commit to one concrete improvement.
• Schedule learning like training: fixed times, clear goals, visible outcomes.
• Use interviews as a learning arena: ask about architecture, operations, and team leadership. Show motivation by evidencing your learning steps.

These routines bring Peter’s core ideas—joy, focus, progress—into your daily practice.

Closing: an invitation to try—and to stick with it

Peter’s story isn’t a tale of heroics; it’s an invitation. From watching his father type code on a Commodore, to discovering that Excel and Access can “do more,” to making architecture calls and coaching teams at RUBICON IT GmbH—the path shows that motivation, enjoyment, and consistency are the constants that carry careers.

And perhaps the most valuable line to leave with is this:

Take it seriously, and you’ve already begun.

• 

  

  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

• 

  

  Roman Brandstetter, Principal Developer bei RUBICON

  Roman Brandstetter von RUBICON erzählt in seinem Interview über seinen Werdegang mit dem Programmieren bis hin zu seinem breiten Aufgabenbereichen in der aktuellen Arbeit und was das Wichtigste als Neueinsteiger ist.

  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
• 

  

  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