Logo RUBICON IT GmbH

RUBICON IT GmbH

Established Company
Show all Videos

Mathias Gartner, Lead Developer bei RUBICON IT

Description

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.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In 'Mathias Gartner, Lead Developer bei RUBICON IT', Mathias Gartner traces his path from early tech curiosity—tinkering with a first phone and building a tiny VBA game at school—to an informatics-focused education, part-time work, and an early start at RUBICON IT, where he still works. As a Lead Developer, he extends beyond coding into project management and requirements engineering, handles tough customer support issues, and cultivates team learning through pair and, when needed, mob programming. His advice to aspiring developers: join a software team as early as possible—often via testing or support—to learn with real-world context and progress into the developer role.

From VBA Tinkering to Lead Developer: Lessons from “Mathias Gartner, Lead Developer bei RUBICON IT” at RUBICON IT GmbH

Why this devstory matters

At DevJobs.at, we gravitate toward stories where curiosity turns into craft. The session “Mathias Gartner, Lead Developer bei RUBICON IT” (Speaker: Mathias Gartner; Company: RUBICON IT GmbH) offers exactly that: a path from tinkering with a first phone and computer to discovering a “button” for code inside Office/VBA, to building a tiny game that surprised classmates, and eventually to a Lead Developer role that blends engineering, project touchpoints, and customer-facing problem solving.

What stands out is how early, hands-on practice shapes a resilient career. Starting in testing during school, combining study with part-time work, learning in the team, and embracing responsibilities that span requirements, project coordination, and technical troubleshooting—these are the building blocks Gartner lays out.

The first spark: curiosity as a method

It begins with a first phone—“pretty much everything without the internet” at the time. For Gartner, that wasn’t a limitation but an invitation. He recalls trying every setting, learning everything the device could do. The same pattern repeated with his first computer: experiment, understand, push the edges. Then the realization: there must be more. As he puts it, there was no setting for “I want to make a new program.” That’s a turning point many developers recognize—the transition from using features to wanting to create them.

Finding the first “button”: Office, VBA, and a tiny game

The next step arrived in school, in computer science class: there is, in fact, a “button.” In Office with VBA, he discovered he could write code and make programs. He ended up shipping what he calls “the smallest possible game you could probably make” in that environment—enough to surprise classmates and prove to himself that ideas can run.

The point is less about complexity and more about agency. This early, low-threshold success becomes a catalyst: you don’t need a full stack to start; you need one approachable entry point that turns intent into software.

Laying tracks: a school with an informatics focus and then university

With momentum building, Gartner chose a school with an informatics focus and continued with computer science at university. Crucially, he didn’t isolate theory from practice. He started part-time work alongside his studies, folding classroom learning directly into real-world tasks. This blending of contexts would become a recurring theme in his journey.

Entering the profession during school: Testing Assistance as a launchpad

One line captures the boldness of his approach: he started while still in school (during the Matura), with the title Testing Assistance—meaning his first professional foothold was in testing. From there the progression is clear: Junior Developer, Developer, and then the opportunity to become a Lead Developer at RUBICON IT GmbH.

This isn’t about title collection. It’s about staging responsibilities so that system understanding, domain context, and collaborative practice deepen in sync.

The path at RUBICON IT GmbH: from testing to lead

What’s telling is the continuity: “I started back then at Rubicon and I’m still there.” The stops along the way have a strong logic:

  • Testing Assistance: learn how to reproduce issues, understand systems under stress, and appreciate quality gates.
  • Junior Developer: ship small features, receive code review feedback, approach production with guidance.
  • Developer: carry larger implementation responsibilities and increase team/customer exposure.
  • Lead Developer: pair technical leadership with project coordination, requirements touchpoints, and difficult customer-facing troubleshooting.

Each stage compounds the previous one, converting hands-on practice into broader impact.

What a Lead Developer does at RUBICON IT GmbH

Gartner’s description is crisp: a Lead Developer “always has a development background,” has previously worked as a developer at the company, and then takes on more responsibility toward project management and requirements engineering. “It depends a bit on the team,” he notes—if there is established requirements engineering experience, less of that lands on the lead.

He also explains where the weight tends to accumulate:

  • “The tricky problems stick with me”—cross-cutting issues, escalations, and ambiguous ownership scenarios.
  • “Support cases when things don’t work at the customer”—blending technical depth with communication and expectation management.
  • “I spend a lot of time with pair programming”—hands-on coaching and shared design decisions.
  • “When there is a stronger knowledge deficit, we also like to apply mob programming”—building shared understanding and closing gaps together.

In short, the role stays hands-on while balancing people, code, and project flow.

Pair and mob programming as learning in practice

Two practices play a central role: pair programming for immediate collaboration and knowledge transfer between two people, and mob programming when a broader knowledge deficit needs to be addressed collectively.

  • Pair programming speeds up feedback and reduces solo dead-ends. It helps inject context and design rationale right at the keyboard.
  • Mob programming mobilizes the entire team around a problem. When the knowledge gap is systemic, aligning in real time creates shared understanding and faster, less brittle outcomes.

In a Lead Developer context, these practices aren’t accessories; they are instruments for simultaneously solving hard problems and elevating team capacity.

Start early, learn in a team: Gartner’s core career principle

Gartner’s advice is unambiguous: the best way to become a software developer is “to start directly in a software development team as early as possible.” The reasoning is practical: everything you learn immediately gains context. You know what it’s for; you look forward to the next learning step because it brings you closer to what the team actually needs.

From an editorial standpoint, this is gold. The friction often lies not in knowledge scarcity but in the lack of context. Plugging into a team provides the frame that transforms theory into judgment.

Realistic entry points: testing, support, and onboarding-friendly roles

Gartner underscores the viability of testing and support as entry paths. He emphasizes this doesn’t diminish their sophistication: testing and support can be deeply demanding specialties. Rather, they often provide accessible starting points where newcomers can contribute while building the knowledge base they need.

For aspiring developers, that translates into a pragmatic strategy: find roles where hands-on exposure is feasible early, where you can observe how systems fail, how customers report issues, and how teams reason under pressure. Then layer your formal learning on top.

What we take away as an editorial team

From Gartner’s story, several durable principles emerge—for individuals crafting their path and for teams cultivating new talent.

For aspiring developers

  • Anchor learning in real work: Seek team contexts where you can contribute regularly—even small testing tasks, simple bug fixes, or reproducing support cases. Momentum matters.
  • Tie every module to a use case: For each course or topic, ask where it fits in your team’s system. Immediate application compounds retention.
  • Small projects count: Like the tiny VBA game, small shipping wins are catalysts. They build confidence and demonstrate capability.
  • Get close to production: Even if you’re not deploying, learn how support cases unfold, what logs reveal, and how customer issues are triaged. This shapes a pragmatic problem-solving profile.
  • Use team practices: Ask for pair sessions, propose mob sessions when understanding gaps are broad. Move learning from solitary trial-and-error to collective reasoning.

For teams and organizations

  • Design entry points deliberately: Testing, support, and structured onboarding tracks are strategic funnels for talent. Keep them accessible and well-scaffolded.
  • Make context visible: Requirements, architecture maps, operating procedures—share early and often. Context accelerates learning curves.
  • Focus the lead role: As described at RUBICON IT GmbH, aim Lead Developers where tricky problems meet knowledge gaps. That’s where technical leverage and team growth reinforce each other.
  • Normalize practices: Offer pair and mob programming as standard options, not just emergency tools. Make knowledge building predictable and repeatable.

The craft of combining responsibilities: engineering, projects, requirements

A notable aspect of Gartner’s portrayal is how naturally engineering shades into project management and requirements work. The Lead Developer at RUBICON IT GmbH isn’t framed as the lone top coder, but as someone who deliberately spans boundaries where most problems originate: at the intersections of expectation, specification, and implementation.

Pair and mob programming then function as bridges: they create shared understanding that stabilizes both technical and domain footing. In practice, this reduces rework, speeds up corrections, and ensures more people on the team can explain and solve the problem end-to-end.

Motivation through context

A key psychological thread runs through the session: when learning is anchored in real tasks, it becomes motivation rather than obligation. As Gartner puts it, you look forward to the next topic because you know it brings you closer to what you actually need in the team.

This loop starts very early in his story—first phone, first computer, no internet, no “make a new program” setting—and becomes productive once the “button” appears: in Office/VBA, in testing, in pair sessions. The throughline is agency: find a path where experiments translate into outcomes.

A practical route from entry to lead

The talk maps cleanly onto a repeatable path:

  1. Follow the urge to tinker: explore settings, push boundaries, and notice where menus end and ideas begin.
  2. Find an approachable entry point: a simple stack (VBA in his case) that lets you build something—even if it’s the tiniest game—so you experience shipping.
  3. Join a team early: while in school or in parallel with formal education. Testing, support, and small dev tasks build fluency and context.
  4. Couple study with usage: for each concept learned, find a place to apply it in your team’s codebase or processes.
  5. Grow responsibility: from junior to developer—own features, understand support, and interpret customer problems.
  6. Become a multiplier: use pair programming routinely; trigger mob sessions when gaps are broad to accelerate shared learning.
  7. Balance tech and project: think requirements, clarify expectations, and prioritize tricky cross-cutting issues.
  8. Treat “lead” as a role, not a badge: show up where it’s hardest—building bridges between people, code, and customer outcomes.

Quotes that stick

“The best approach is to start directly in a software development team as early as possible.”

“The tricky problems stick with me … support cases when things don’t work at the customer.”

“I spend a lot of time with pair programming … and when the knowledge deficit is bigger, we like to apply mob programming.”

Testing and support are not “less demanding”—they are legitimate domains with highly skilled practitioners. They can, however, offer accessible starting points to contribute while building knowledge.

These lines reveal a stance: practical, team-centered, and respectful of every role in the software delivery chain.

Our conclusion: learning is a team sport, and responsibility grows from practice

“Mathias Gartner, Lead Developer bei RUBICON IT” outlines a path that avoids shortcuts—and that’s exactly why it’s compelling. Start early. Interleave learning and doing. Use team practices as levers. Shape a Lead Developer role that spans engineering, projects, and requirements.

For us, that’s the core of this devstory: don’t wait to be “ready.” Join a team, start small, absorb context, seek responsibility. That is how a first phone without internet turns into a career that unites people, code, and customer needs—at RUBICON IT GmbH and in any environment where software has to hold up in the real world.

More Tech Talks

More Tech Lead Stories

More Dev Stories