Vom ersten Handy bis zum Lead Developer: Die Entwicklungsreise von Mathias Gartner bei RUBICON IT GmbH

Warum uns diese devstory bewegt

Wir bei DevJobs.at lieben Geschichten, die den Funken zwischen Neugier und Berufung sichtbar machen. Genau das passiert in der Session „Mathias Gartner, Lead Developer bei RUBICON IT“ (Speaker: Mathias Gartner; Company: RUBICON IT GmbH). Es ist die Art von Werdegang, die viele Entwickler:innen intuitiv nachvollziehen können: vom Tüfteln am ersten Handy und PC über das erste „Hello World“ – in diesem Fall ein minimalistisches Spiel in VBA – bis hin zur Rolle, in der technische Verantwortung, Teamarbeit und Kundennähe zusammenkommen.

Was wir in dieser devstory mitgenommen haben: Früh anfangen, Praxis so schnell wie möglich mitlernen, und Verantwortung nicht als Titel, sondern als gelebte Rolle verstehen. Gartner macht deutlich, wie sich langfristiges Dranbleiben, Lernen im Team und das systematische Aufbauen von Kontextkompetenz zu einem robusten Karrierepfad verbinden.

Der erste Funke: Wenn Neugier zur Methode wird

Am Anfang steht ein simples, aber prägendes Erlebnis: ein erstes Handy – damals noch „ziemlich alles ohne Internet“. Für Gartner war das kein Hindernis, sondern eine Einladung. Er beschreibt, wie er „jede Einstellung ausprobiert, alles gewusst“ hat, „was das Ding kann“. Kurz darauf wiederholt sich die Szene am ersten Computer: ausprobieren, verstehen, Grenzen austesten. Und dann ein entscheidender Gedanke: „Da geht aber dann noch mehr.“

Diese Beobachtung trifft einen Nerv. Viele Entwickler:innen entdecken den Übergang vom Anwenden zum Gestalten in genau diesem Moment: Die Menüs geben nicht mehr her, was man im Kopf bereits bauen will. Der Satz „da war keine Einstellung für, ich will ein neues Programm machen“ fasst diese Schwelle elegant zusammen – ein klassischer Aha-Moment, in dem die Neugier nicht mehr mit GUI-Optionen zu befriedigen ist.

Der erste „Knopf“: VBA in Office und das kleinstmögliche Spiel

Der nächste Schritt kommt in der Schule. Im Informatikunterricht zeigt sich: „Da gibt’s doch irgendwie einen Knopf.“ Gemeint ist der Einstieg in Office mit VBA – ein unscheinbares Tor in eine Welt, in der die eigenen Ideen plötzlich laufen. Gartner beschreibt, wie er den Button entdeckt, „Code schreiben, Programme machen“ – und damit ein kleines Spiel baut, „das kleinstmögliche, was man wahrscheinlich machen kann“.

Das Ergebnis: überraschte Mitschüler:innen und ein erstes Erlebnis, wie aus logischer Struktur und Neugier Software entsteht. Dieses minimalistische Spiel ist weniger wegen seiner Komplexität wichtig, sondern wegen der Erfahrung, dass aus eigenem Antrieb wirkungsvolle Artefakte entstehen können. Genau solche Low-Threshold-Erlebnisse prägen das Selbstbild von Entwickler:innen – und motivieren, den nächsten Schritt zu gehen.

Weichenstellung: Schule mit Informatikschwerpunkt und anschließendes Studium

Mit diesem Rückenwind fällt die nächste Entscheidung: „Ich habe dann eine Schule mit Informatik Schwerpunkt gewählt, habe dann dort dann noch weiter das Informatikstudium angehängt.“ Der Pfad ist klar – aber nicht linear im klassischen Sinn. Denn die Praxis rückt früh hinein in die Ausbildung: „Nebenbei dann schon Teilzeit zum Arbeiten angefangen.“ Anders gesagt: Theorie und Praxis wachsen zusammen.

Für uns zeigt sich hier eine zentrale Lernstrategie: kontinuierlich das Gelernte in echte Kontexte spiegeln. Nicht warten, bis alles „fertig“ studiert ist, sondern von Anfang an Praxis reinholen. Genau das führt später zu einer Souveränität in der Rolle, die im Alltag zählt.

Berufseinstieg während der Matura: Testing Assistance als Sprungbrett

Ein Satz bleibt hängen: „Ich habe tatsächlich schon neben der Schule noch angefangen, während ich noch die Matura gemacht habe … den schönen Titel Testing Assistance gehabt, habe also im Testing angefangen.“ Das ist bemerkenswert: Ein Einstieg, der früh Verantwortung, Routinen und Teamkontext vermittelt – noch bevor die formale Ausbildung abgeschlossen ist.

Gartner sagt es ohne Pathos, aber mit Klarheit: Dieser frühe Einstieg hat sein Lernen strukturiert. Er beschreibt, wie sich das Wissen parallel zum Studium aufbaut, wie die Rolle sich entwickelt: vom Testing über Junior Developer zur regulären Developer Position – und schließlich zum Lead Developer bei RUBICON IT GmbH.

Stationen bei RUBICON IT GmbH: Vom Testing zum Lead

Dass er „damals schon bei der Rubicon angefangen und … immer noch da“ ist, deutet auf ein Umfeld hin, das Entwicklung zulässt und fordert. Die Stationen sind greifbar:

• Testing Assistance: Qualität sichern, Systeme verstehen, Reproduzierbarkeit lernen.
• Junior Developer: erste Features, erste Code Reviews, erste Produktionsnähe.
• Developer: Verantwortung für Implementierungen, mehr Kunden- und Teamkontakt.
• Lead Developer: technische Verantwortung, Schnittstellen ins Projektmanagement und ins Requirements Engineering, Troubleshooting und Coaching im Team.

Diese Abfolge ist mehr als ein Karrieretitel-Laufband. Sie zeigt einen Lernpfad, in dem Praxiswissen, Domänenverständnis und Zusammenarbeit stetig dichter werden.

Was ein Lead Developer bei RUBICON IT ausmacht

Gartner skizziert die Rolle präzise: „Bei uns ist der Lead Developer eigentlich immer eine Person mit Entwicklungshintergrund, hat noch mal vorher als Entwickler bei uns gearbeitet und übernimmt dann auch mehr Rollen in Richtung … Projektmanagement … Requirements Engineering.“ Wichtig ist die adaptive Komponente: „Hängt ein bisschen vom Team ab.“ Gibt es Erfahrung im Requirements Engineering, „dann bleibt dem Lead Developer weniger hängen“.

Er macht aber auch deutlich, wo die konkreten Lastspitzen liegen:

• „Bei mir bleiben dann auch so die kniffligen Probleme hängen“ – die Art Aufgaben, die mehrere Systeme berühren, eskalieren oder unklare Verantwortungen haben.
• „Supportfälle, wenn es beim Kunden nicht geht“ – also Situationen, in denen Fachlichkeit, Technik und Kommunikation gleichermaßen zählen.
• „Wenn die Kollegen im Team Probleme haben … verbringe [ich] auch viel Zeit mit Peer Programming“ – direkte Wissensweitergabe, Feedback im Fluss.
• „Wenn … der Wissensdefizit ein bisschen stärker gibt, dann wenden wir auch gern Mob Programming an“ – also gemeinsame Fokussierung, um Lücken zu schließen und ein geteiltes Verständnis aufzubauen.

Diese Beschreibung zeigt eine Rolle, die Hands-on bleibt, aber den Blick aufs Ganze einfordert: Technik, Prozesse und Menschen ausbalancieren.

Pair und Mob Programming: Teamlernen als Praxis

Zwei Praktiken sind zentral: Pair Programming und Mob Programming. Gartner nutzt beide situativ:

• Pair Programming als Hebel für unmittelbare Zusammenarbeit zwischen zwei Personen: schneller Wissenstransfer, Feedback in Echtzeit, gemeinsame Verantwortung für Designentscheidungen.
• Mob Programming als Werkzeug, wenn „der Wissensdefizit … stärker“ ist: Alle arbeiten gemeinsam an einem Problem, reduzieren Missverständnisse und erzeugen geteiltes Kontextwissen.

Beide Methoden sind mehr als „Nice-to-have“. In der geschilderten Rolle bedienen sie die neuralgischen Punkte eines Lead Developers: kritische Themen beschleunigt lösen, gleichzeitig das Team befähigen und Silos aufbrechen – genau dort, wo es brennt.

Früh starten, Praxis aufbauen: Gartners zentrales Karriereprinzip

Es ist eine klare Empfehlung: „Meiner Meinung nach ist der beste Ansatz … direkt in einem Softwareentwicklungsteam anzufangen, so früh wie möglich.“ Die Begründung ist handfest: „Man hat bei allem, was man lernt, immer gleich einen Praxisbezug, man weiß gleich, worauf man es anwenden kann, freut sich … auf die nächsten Inhalte, weil man weiß, man kommt immer näher an das, was man eigentlich braucht.“

Das ist ein wichtiger Punkt für alle, die ihren Weg in die Softwareentwicklung planen. Entscheidend ist weniger das „Warten auf das perfekte Know-how“, sondern das konsequente Verknüpfen von Lernen und Tun. Ob Schule, Studium oder Quereinstieg – der gemeinsame Nenner ist der frühe Teamkontext.

Einstiege, die funktionieren: Testing, Support und onboarding-freundliche Rollen

Gartner benennt realistische Einstiegsfelder: „Bei uns war es damals im Testing möglich … es gibt vielleicht auch so Möglichkeiten im Support heranzukommen oder Stellen, wo es vielleicht ein bisschen weniger aufwendiger ist, mal den initialen Wissenssoftware zu machen, wo man es vielleicht ein bisschen in Onboarding hinbekommt und da dann mal anzufangen.“

Wichtig ist ihm eine Präzisierung: „Soll jetzt nicht heißen, dass Testing oder Support Engineer jetzt nicht so anspruchsvoll ist … da gibt es ja auch sehr erfahrene Leute, die das richtig gut machen.“ Der Punkt ist ein anderer: Diese Rollen bieten häufig einen niedrigschwelligen Einstieg, um früh Teamprozesse, Codebasen und Produktkontexte kennenzulernen – und parallel das Fachwissen hochzuziehen.

Was wir als Redaktion daraus ableiten

Aus Gartners Weg lassen sich klare, praxisnahe Leitlinien ziehen – für angehende Entwickler:innen, aber auch für Teams, die Talente entwickeln möchten.

Für angehende Entwickler:innen

• Starthilfe mit Praxis: Suche gezielt Teamkontexte, in denen du regelmäßig echte Aufgaben übernehmen kannst – auch klein beginnen (Testing, einfache Bugfixes, Support-Nachvollzüge), Hauptsache im Fluss.
• Lernkurve koppeln: Verbinde jedes Lernmodul (Kurs, Vorlesung, Tutorial) mit einem konkreten Anwendungsfall in deinem Team. Was kannst du sofort nutzen, verproben, zeigen?
• Mini-Projekte zählen: Wie bei Gartners VBA-Spiel – kleine Projekte sind Katalysatoren. Sie geben dir Proof-of-Work und Selbstvertrauen.
• Nähe zur Produktion: Auch wenn du nicht deployen darfst – lerne, wie Supportfälle funktionieren, was Logs verraten, wie Kund:innenprobleme eingeordnet werden. Dieser Blick schärft dein Problemlösungsprofil.
• Teampraktiken nutzen: Pair Programming anfragen, Mob Sessions vorschlagen, wenn Verständnislücken groß sind. So verlagerst du Lernen vom individuellen Versuch-und-Irrtum ins gemeinsame Erarbeiten.

Für Teams und Unternehmen

• Entry Points bewusst gestalten: Testing, Support oder klar strukturierte Onboarding-Tracks sind strategische Talentschleusen. Halte sie offen und didaktisch gut gerahmt.
• Kontextwissen sichtbar machen: Anforderungen, Architekturkarten, Betriebsabläufe – alles, was den Systemkontext erklärt, früh und wiederkehrend teilen. Das beschleunigt die Lernkurve.
• Lead-Rolle mit Fokus: Wie bei RUBICON IT GmbH beschreiben – Lead Developers sollten dort eingesetzt werden, wo knifflige Probleme und Wissenslücken zusammentreffen. Das erzeugt technische Schlagkraft und Teamwachstum zugleich.
• Praktiken etablieren: Pair und Mob Programming als reguläre Option anbieten – nicht nur als Krisenmodus. So wird Wissensaufbau planbar und wiederholbar.

Die Kunst, Verantwortung zu kombinieren: Entwicklung, Projekte, Requirements

Was Gartners Schilderung auszeichnet, ist die natürliche Verzahnung von Technik und Projektkontext. Der Lead Developer ist bei RUBICON IT GmbH eben nicht nur der „beste Programmierer“, sondern „übernimmt … mehr Rollen in Richtung Projektmanagement … Requirements Engineering“. Warum ist das wichtig? Weil knifflige Kundenprobleme technisch nicht isoliert lösbar sind. Sie entstehen an Schnittstellen – zwischen Erwartung, Spezifikation und Implementierung.

Gerade hier wirken Pair und Mob Programming als Brücke: Sie schaffen „Shared Understanding“, das sowohl technischen als auch fachlichen Boden stabilisiert. In der Praxis heißt das: Weniger Reibungsverluste, schnellere Korrekturen, und vor allem – mehr Menschen im Team können das Problem erklären und lösen.

Praxisbezug als Motivationsmotor

Ein zentraler Gedanke aus der Session ist psychologisch klug: „Man freut sich … auf die nächsten Inhalte, weil man weiß, man kommt immer näher an das, was man eigentlich braucht.“ Wenn Lernen nicht im Vakuum geschieht, sondern täglich an echten Aufgaben andockt, verwandelt es sich in Antrieb. Der Effekt: ausdauernde Neugier statt kurzfristige Pflicht.

Dieser Motivationskreislauf beginnt – so Gartners Geschichte – erstaunlich früh: am Handy ohne Internet, am PC ohne „Knopf“ zum Programmieren. Und er wird produktiv, sobald der Knopf sichtbar wird: in Office/VBA, im Testing-Team, in Pair-Sessions.

Leitfaden: Vom Einstieg zur Lead-Rolle – in Etappen, die tragen

Aus dem Gehörten lässt sich ein robuster Weg skizzieren, ohne Mythen:

1. Dem Impuls folgen: Tüfteln, Einstellungen erkunden, Grenzen spüren – das ist kein Spieltrieb, sondern die Keimzelle von Ownership.
2. Den ersten Button finden: Ein niederschwelliger Technologiestack (wie VBA damals) kann der ideale Start sein. Entscheidend ist, etwas Schiffbares zu bauen – gern klein, aber echt.
3. Früh ins Team: Bereits während der Schule oder parallel zur Ausbildung Praxis sammeln – Testing, Support, einfache Dev-Aufgaben. Tempo entsteht durch Kontext.
4. Lernpfad koppeln: Studium oder Kurse parallel – jedes Modul fragt: „Wo im Team kann ich das einsetzen?“
5. Verantwortung erhöhen: Vom Junior zum Developer – Features tragen, Support verstehen, Kundenprobleme einordnen.
6. Multiplikator werden: Pair Programming nutzen, Defizite erkennen, Mob Programming initiieren, wenn es hakt.
7. Technik und Projekt balancieren: Requirements mitdenken, Erwartungen klären, knifflige Probleme priorisieren.
8. Lead als Rolle, nicht Titel: Dort sein, wo es brennt – Brücken bauen zwischen Menschen, Code und Kundenerfolg.

Zitate, die hängen bleiben

Diese Sätze verdichten eine Haltung: praxisnah, teamorientiert, respektvoll gegenüber allen Rollen im Entwicklungsprozess.

Unser Fazit: Lernen ist Teamarbeit, Verantwortung wächst aus Praxis

„Mathias Gartner, Lead Developer bei RUBICON IT“ zeigt einen Weg, der ohne Abkürzungen auskommt – und gerade dadurch überzeugt. Früh anfangen, bewusstes Wechselspiel aus Lernen und Anwenden, Teampraktiken als Hebel, und eine Lead-Rolle, die Technik, Projekte und Requirements zusammenführt.

Für uns ist das die Essenz dieser devstory: Nicht warten, bis du „bereit“ bist. In ein Team gehen, klein anfangen, Kontext aufsaugen, Verantwortung suchen. So entsteht aus dem ersten Handy ohne Internet eine Karriere, die Menschen, Code und Kundenbedürfnisse zusammenbringt – bei RUBICON IT GmbH und überall dort, wo Software in der Realität standhalten muss.

• 

  

  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.

  Jetzt ansehen
• 

  

  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.

  Jetzt ansehen

• 

  

  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.

  Jetzt ansehen

• 

  

  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.

  Jetzt ansehen
• 

  

  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.

  Jetzt ansehen
• 

  

  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.

  Jetzt ansehen
• 

  

  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.

  Jetzt ansehen