Vom Spiele‑Modding zum Lead Backend Engineer: Die Lernkurve von Dominik Ager (Antiloop GmbH)

Kontext der Session

• Titel: Dominik Ager, Lead Back End Engineer von Antiloop
• Speaker: Dominik Ager
• Company: Antiloop GmbH

Wir bei DevJobs.at haben diese Session als eine geradlinige, bodenständige Entwicklergeschichte erlebt: keine Buzzwords, keine Folien-Schlachten, sondern eine klare Linie von der ersten Begeisterung in der Schulzeit über eine Lehre bis hin zur Teamleitung im Backend. Dominik Ager zeichnet die Stationen nach, die ihn geprägt haben – und macht dabei eindrücklich sichtbar, wie viel im Backend passiert, lange bevor eine Nutzerin oder ein Nutzer einen schönen Button klickt.

Der erste Funke: Zwölf Jahre alt, Sporttag – und lieber Rechner pflegen als sprinten

Die Reise beginnt für Dominik Ager in der Hauptschule, ungefähr im Alter von zwölf Jahren. Während andere am jährlichen Sporttag auf dem Feld ihre Runden drehen, hilft er lieber dem Informatiklehrer, Computer zu aktualisieren. Das ist kein Zufall, sondern Ausdruck früher Neugier, kombiniert mit der Gelegenheit, praktische Verantwortung zu übernehmen. Besonders hängen geblieben ist ihm die Unterstützung dieses Lehrers, der das Team gefördert und „gepusht“ hat – ein frühes Beispiel für gute Mentorship-Kultur.

Was wir hier lernen: Motivation braucht Kontaktflächen. Es reicht oft ein kleines, konkretes Projekt – ein harter Praxisbezug, der unmittelbaren Nutzen stiftet. Für Dominik war das das Aktualisieren von Rechnern. Dieses Handfeste, sofort Greifbare setzt Energie frei, weckt Forscherdrang und lässt erste Ownership entstehen.

Modding als erste Feedback‑Schleife: Zahlen ändern, Wirkung spüren

Bald darauf folgt das Experimentierfeld, das so viele Entwickler:innen geprägt hat: Games modden. Dominik fängt an, Mods zu manipulieren – nicht mit komplexen Frameworks, sondern simpel, indem er Zahlen in Dateien ändert und dann direkt im Spiel beobachtet, was passiert. Dieser unmittelbare Ursache‑Wirkung‑Effekt ist ein starker Motivator. Er zeigt, wie schon kleine Eingriffe große Unterschiede machen können.

Dominik bringt sich vieles selbst bei – mit YouTube-Videos als Lernquelle. Die Mods sind „jetzt nicht die besten“, wie er nüchtern sagt, „aber es hat funktioniert – und darum geht es ja beim Programmieren.“ Dieser Satz wirkt nach. Er trifft einen Kern, den viele erst spät verstehen: Funktionierende Einfachheit schlägt sterile Perfektion. Und sie bildet die Basis, auf der man komplexer wird.

Für uns als Redaktion ist das die Essenz des frühesten Lernerfolgs: Minimale Änderungen, maximal sichtbares Feedback, Lernkurven in kleinen Schritten. Wer so anfängt, kultiviert Durchhaltevermögen und baut das Selbstvertrauen auf, das spätere Komplexität erst möglich macht.

Die Lehre als Fundament: Web‑Basics und eine Sprache, die bleibt

Folgerichtig entscheidet sich Dominik für eine Lehre als Informatiker und schließt diese ab. Er lernt HTML, CSS und JavaScript – das Trio, das die meisten frühen Webkarrieren trägt. Zudem nennt er eine zusätzliche Programmiersprache, die ihn „bis heute begleitet“. Der genaue Name spielt hier weniger eine Rolle als die Botschaft: In der Praxis bleiben oft einige wenige Sprachen langfristig relevant, wenn man damit echte Produkte baut und Verantwortung übernimmt.

Die Lehre wirkt im Rückblick wie ein sauberer Trittstein: strukturierte Ausbildung, Teamumfeld, reale Aufgaben. Doch die größten Entwicklungssprünge entstehen, wie Dominik betont, in der Freizeit – durch eigene Projekte. Diese Koexistenz aus formaler Ausbildung und selbst getakteter Lernzeit ist ein Muster, das wir immer wieder sehen: Curriculum gibt Halt, Side Projects geben Traktion.

Heute: Lead Backend Engineer – Arbeit, die man nicht sieht, aber die alles trägt

Dominik Ager ist Lead Backend Engineer. Er beschreibt seine Rolle nicht als Einzelkämpferposition, sondern als Arbeit am gemeinsamen Strang. Es geht darum, das Backend‑Team so zu führen, dass alle in dieselbe Richtung entwickeln. Dazu gehören Kundenabstimmungen, technische Klärungen, klare Verantwortlichkeiten – und die Haltung, Probleme nicht zu individualisieren, sondern im Team zu lösen.

Gemeinsam ziehen: Richtung, Fokus, Prioritäten

Als Lead richtet Dominik das Team aus. Das ist weniger ein hierarchischer Akt als ein dauerhaftes Synchronisieren: Wo wollen wir hin? Welche Schnittstelle hat heute Priorität? Welche Entscheidung reduziert morgen die meiste Komplexität? Aus seinen Formulierungen spricht Pragmatismus. Führung bedeutet hier, technische Entscheidungen in ein kollektives Verständnis zu überführen – nicht nur „was“, sondern vor allem „warum“.

Kund:innenabstimmung: Was machen wir – und was macht ihr?

Eine zentrale Aufgabe ist die Abstimmung mit Kund:innen: „Dieses System wird implementiert“ – und dann gilt es, technische Details zu klären. Wer liefert welche Daten? Wo liegen Verantwortlichkeiten? Was muss das Team tun, was bleibt auf Kundenseite? Diese Trennschärfe ist in Integrationsprojekten Gold wert, weil sie spätere Überraschungen verhindert. Sie setzt einen klaren Erwartungsrahmen und hilft, Abhängigkeiten realistisch zu planen.

Verantwortung teilen: Fehler gemeinsam lösen

Dominik betont die Teamverantwortung, wenn es um Bugs geht: nicht „einer alleine rumdockt“, sondern gemeinsam analysieren und beheben. Das klingt simpel, ist aber ein kultureller Eckpfeiler. Wer Fehler kollektiv betrachtet, optimiert nicht nur den Fix, sondern verbessert die Wissensverteilung. Kein Bereich bleibt zur Blackbox einzelner Spezialist:innen – ein zentraler Hebel für Resilienz.

Code Reviews als Qualitätsanker

Auch Code Reviews gehören zum Alltag. Sie sind hier weniger Gatekeeping als Lernvehikel: Standards sicherstellen, Risiken früh entschärfen, stilles Wissen sichtbar machen. In Backends mit vielen Relationen und Integrationen sind Review‑Schleifen das Airbag‑System der Codebasis.

Komplexität hinter dem Knopf: Bezahlen klicken ist einfach – die Arbeit dahinter nicht

Frontend ist sichtbar, Backend ist wirksam. Dominik bringt ein anschauliches Beispiel: Beim Klick auf „Bezahlen“ werden im Backend Kreditkarteninformationen weitergeleitet, eine Zahlung gebucht – und noch einiges mehr. Was wie ein einzelner Event aussieht, ist im Hintergrund eine Prozesskette, die Sicherheit, Konsistenz und Integrität garantieren muss.

Genau hier liegt die typische Backend‑Komplexität:

• Datenmodelle und Relationen verstehen
• Integrationen mit Drittsystemen korrekt anbinden
• Verantwortlichkeiten und Fehlerfälle prozessual denken
• Transaktionen und Nebenwirkungen sauber koordinieren

Wer so arbeitet, spürt jeden Tag, dass der „schöne Knopf“ nur der sichtbarste Pixel einer tiefen Systemlandschaft ist. Qualität entsteht im Unsichtbaren.

Lernen durch eigene Projekte: Eine Speicherplatz‑Alternative wie Dropbox

Dominik nennt ein prägendes Nebenprojekt: eine Speicherplatz‑Alternative „wie Dropbox“. Ob Prototyp oder produktionsreif – darum geht es nicht. Entscheidend ist das Lernmoment: Architekturentscheidungen zu treffen, Fehler zu machen und daraus zu lernen. In diesem Projektformat liegt ein universeller Vorteil: Man muss End‑to‑End denken – vom Datenmodell über Schnittstellen bis zu Berechtigungen und Skalierungsfragen.

Für uns ist das das produktivste Lernsetting: radikal praxisnah, mit echter Reibung. Ein eigenes Projekt verzeiht keine Blindstellen. Es zwingt dazu, Abhängigkeiten zu sehen, statt sie zu abstrahieren, und es trainiert jene Urkompetenzen, die Dominik für das Backend hervorhebt: logisches Denken, Kausalität, Konsequenzen.

Motivation und Resilienz: Nicht verzweifeln, logisch denken, am Ball bleiben

Dominiks Ratschläge verdichten sich zu drei Leitgedanken:

1. Eigene Motivation kultivieren.
2. Nicht verzweifeln, wenn etwas nicht funktioniert.
3. Logisch denken – Abhängigkeiten erkennen, Konsequenzen bedenken.

Er spricht aus Erfahrung: Die größten Schritte passierten bei ihm in der Freizeit mit eigenen Projekten. Das ist kein Aufruf zum Overwork, sondern eine Einladung zur Selbstwirksamkeit. Wer selbst baut, lernt schneller. Und wer bei Fehlern nicht in Frustration, sondern in Analysemodus geht, wird verlässlich besser.

Was wir als Redaktion aus der Session mitnehmen

• Frühzeitige, praktische Aufgaben setzen Motivation frei.
• Kleine, sichtbare Erfolge (z. B. beim Modding) sind starke Katalysatoren.
• Lehre plus Side Projects ist eine wirksame Kombination.
• Teamführung im Backend heißt: Richtung geben, Komplexität teilen, Verantwortung klären.
• Kundenabstimmungen brauchen technische Präzision und klare Verantwortlichkeiten.
• Code Reviews sind Lernräume, nicht nur Kontrollinstanzen.
• Backend‑Arbeit ist Prozessdenken – Daten, Relationen, Integrationen, Fehlerfälle.
• Durchhaltevermögen und Logikkompetenz sind Kernfähigkeiten.

Handlungsleitfaden für angehende Backend‑Entwickler:innen

Auf Basis von Dominik Agers Erzählung haben wir konkrete Schritte abgeleitet, die du sofort umsetzen kannst:

• Baue kleine, wirkungsvolle Experimente.
• Ändere etwas Kleines (z. B. eine Konfiguration, ein Datenfeld) und beobachte die Systemauswirkung.
• Nutze das direkte Feedback, um Hypothesen zu prüfen.
• Wähle ein End‑to‑End‑Side‑Project.
• Eine Mini‑Plattform (z. B. Dateiablage, Aufgabenverwaltung) zwingt zu Architekturdenken.
• Definiere Minimalanforderungen (Upload, Authentifizierung, Freigabe) und liefere iterativ.
• Trainiere logisches Denken in Abhängigkeiten.
• Mappe: „Wenn A passiert, kann B passieren – was heißt das für C?“
• Schreibe bewusst die Fehlerpfade auf, nicht nur den Happy Path.
• Pflege Frustrationstoleranz.
• Dokumentiere Fehlversuche als Lernartefakte.
• Feiere „funktioniert – egal wie hübsch“ als legitimen Meilenstein.
• Suche Review‑Partner:innen.
• Kurze, regelmäßige PRs mit klarem Scope.
• Fragen, nicht nur Lösungen: „Siehst du einen Fall, den ich übersehen habe?“

Teamführung im Backend: Prinzipien, die tragen

Was Dominik über seine Rolle sagt, lässt sich in universelle Führungsprinzipien übersetzen:

• Gemeinsame Richtung sichtbar machen.
• Formuliere explizit, was heute die „richtige Richtung“ ist.
• Verknüpfe Entscheidungen mit Zielen (Performance, Wartbarkeit, Lieferfähigkeit).
• Verantwortung mit Kund:innen klären.
• Trenne sauber: Welche Inputs brauchen wir? Welche liefert die Kundenseite?
• Halte technische Details schriftlich fest, bevor du implementierst.
• Fehler gemeinsam lösen.
• Vermeide Schuldfragen.
• Teile Debugging‑Sessions, dokumentiere Erkenntnisse.
• Code Reviews als Wissensmultiplikator nutzen.
• Nutze sie, um implizite Annahmen explizit zu machen.
• Frage nach Relationen: „Welches Datenobjekt hängt hier wovon ab?“

Backend‑Komplexität entzaubern: Datenmodell zuerst

Dominik nennt Datenmodelle, Relationen und Integrationen als Kernherausforderungen. Für Praxisprojekte heißt das:

• Beginne mit dem Domänenmodell. Welche Entitäten gibt es, wie hängen sie zusammen?
• Leite daraus Schnittstellen ab. Welche Daten fließen zwischen Systemen, in welchem Zustand?
• Plane Fehlerfälle früh. Was, wenn ein Drittsystem verzögert antwortet? Was, wenn eine Zahlung fehlschlägt, aber eine E‑Mail schon gesendet wurde?
• Entkoppel, wo möglich. Baue Puffer oder Ereignisverarbeitung ein, um Nebenwirkungen zu isolieren.

Dieses Denken schützt vor dem Trugschluss, dass ein schöner Button gleichbedeutend mit einem fertigen Produkt ist. Wirklicher Fortschritt passiert im unsichtbaren Teil: dort, wo Konsistenz und Verantwortlichkeit verhandelt werden.

Die Lehre neu lesen: Warum Struktur und Selbstbau zusammengehören

Dominiks Weg zeigt, wie formale Ausbildung und freie Projekte sich gegenseitig verstärken:

• Struktur (Lehre) liefert Vokabular und Best Practices.
• Selbstbau (Side Projects) liefert Kontext, Fehler, Korrekturen.
• Zusammen entsteht belastbares Können, das in Teamrollen (z. B. Code Reviews, Kundenabstimmung) wirksam wird.

Der entscheidende Punkt ist nicht, alles zu wissen, sondern beständig zu lernen – mit echten Aufgaben, echtem Feedback und der Bereitschaft, einfache Lösungen zu akzeptieren, wenn sie funktionieren.

Zitatanker für den Alltag

• „Es hat funktioniert – und darum geht es beim Programmieren.“
• „Nicht verzweifeln, wenn etwas nicht funktioniert.“
• „Am Ball bleiben und motiviert bleiben.“

Diese Sätze klingen schlicht, tragen aber weit. Sie verschieben den Fokus von Idealbildern auf konkrete Fortschritte – und genau dort wächst Kompetenz.

Fazit: Sichtbare Knöpfe, unsichtbare Verantwortung

In „Dominik Ager, Lead Back End Engineer von Antiloop“ mit Speaker: Dominik Ager und Company: Antiloop GmbH zeigt sich, wie eine Entwicklerkarriere mit kleinen, funktionierenden Schritten beginnt und im Backend in Verantwortung mündet. Vom Modding über die Lehre bis zur Teamleitung zieht sich ein roter Faden: Motivation, Pragmatismus, gemeinsames Lösen von Problemen und das Verständnis, dass hinter jedem Klick eine Kette von Entscheidungen steckt.

Für uns bei DevJobs.at ist diese Geschichte eine Einladung, das Unsichtbare ernst zu nehmen: Datenmodelle, Relationen, Integrationen, Fehlerfälle – die eigentlichen Orte, an denen Qualität entsteht. Wer dort neugierig bleibt, logisch denkt und nicht verzweifelt, wenn etwas nicht sofort klappt, wird im Backend nicht nur funktionieren, sondern führen.

• 

  

  Dominik Ager, Lead Back End Engineer bei Antiloop

  Dominik Ager von Antiloop spricht im Interview über seine frühen Anfänge mit dem Programmieren, wie seine aktuelle Arbeit aussieht und gibt Tipps für Neueinsteiger.

  Jetzt ansehen