Von QBasic-Gorillas zu Hochleistungs‑Simulationen: Philipp Aumayr, Senior Software Developer Simulation bei TGW Logistics Group

Ein Entwickler, der früh begann – und nie aufgehört hat zu iterieren

Wenn wir bei DevJobs.at Gespräche wie „Philipp Aumayr, Senior Software Developer Simulation bei TGW Logistics Group“ begleiten, werden wir daran erinnert, wie stark Berufswege in der Softwareentwicklung von Neugier, Ausprobieren und beharrlichem Dranbleiben geprägt sind. Philipp Aumayr skizziert in wenigen, präzisen Momentaufnahmen eine Lernkurve, die viele von uns kennen – vom spielerischen Tüfteln am Heimcomputer über ambitionierte Projekte ohne „fertiges“ Ergebnis hin zu anspruchsvoller Simulation, in der Performance keine Obergrenze kennt.

Seine Geschichte beginnt im Alter von „11, 12“ auf einem DOS‑386‑Rechner. Ein QBasic‑Gorillaspiel öffnet ihm den Blick hinter die Kulissen – und eine simple Frage wird zur Initialzündung: „Was machen die Codezellen dahinter?“ Aus der Neugier wird Praxis: tippen, testen, verstehen. Und aus ersten Programmierschritten entsteht eine Haltung, die Philipp bis heute trägt: erst bauen, dann begreifen – und wieder bauen.

DOS, QBasic und der Moment, in dem Neugier zur Methode wird

Philipp erzählt, wie ein Spiel mit Gorillas, die sich Bananen zuwerfen, den Grundstein legte. QBasic ermöglichte das direkte Verändern und Ausführen von Code – ein friktionsloser Einstieg, der heute fast nostalgisch wirkt. Internet war „damals noch nicht so“; vieles passierte offline, durch Ausprobieren und zufällige Funde.

Mehr als das Spiel selbst prägt ihn das Gefühl, dass hinter jedem Ergebnis Logik steckt, die man anfassen kann. Sein erster Pragmatismus zeigt sich in einer Aufgabe, an der viele Jugendliche irgendwann arbeiten: Hausübung. Er automatisiert seine Mathematik‑Hausübungen. Das Ergebnis ist ambivalent – und lehrreich:

Für uns steckt darin ein starkes Signal: Programmieren kann Prozesse und Strukturen schärfen, ohne die zugrunde liegenden manuellen Fertigkeiten automatisch mitzunehmen. Philipp lernt früh, dass formale Korrektheit und händisches Rechnen zwei verschiedene Disziplinen sind – und dass Automatisierung zwar Ergebnisse liefert, aber nicht jede Lücke füllt. Gleichzeitig zeigt diese Episode, wie mächtig Software sein kann, wenn sie Alltagsroutinen transformiert.

„Lern C“ – ein Rat, der Türen öffnet

Ein Satz einer Bekannten wird zum Wendepunkt: Wenn es ernst werden soll, „dann soll ich doch bitte C lernen“. Wer je versucht hat, von einer freundlichen Einsteigerumgebung in eine Systemprogrammiersprache zu wechseln, weiß, was das bedeutet: Man steigt tiefer ein, beschäftigt sich mit Speicher, Typen, Kompilierung, Build‑Ketten. Für Philipp ist das keine Abschreckung, sondern der nächste logische Schritt.

Das führt ihn zu einer Erfahrung, die viele Entwicklergenerationen geprägt hat: Online‑Communities, in denen gemeinsame Projekte geboren werden – Projekte, die vielleicht nie „fertig“ werden, aber handfestes Lernen ermöglichen. So auch hier: neue Freundschaften, ein ambitioniertes Ziel – Quake nachprogrammieren. „Gleich mal ein großes Ziel, wenn man Hello World geschafft hat…“

Das Projekt endet nicht in einem marktreifen Shooter. Doch Philipp zieht keine Niederlage daraus. Im Gegenteil. Er betont, wie viel er daraus mitgenommen hat: Netzwerkprogrammierung, Computergrafik und mehr. Für uns als Redaktion ist das der Kern einer praktischen Lernphilosophie: Lerne, indem du dich überforderst – aber im besten Sinne. Groß denken, klein anfangen, Schritt für Schritt wachsen.

Warum ein gescheitertes Spielprojekt Erfolg sein kann

Philipp formuliert es knapp: „Wir haben kein richtiges Spiel geschafft … aber ich habe unheimlich viel gelernt.“ Diese Haltung ist bemerkenswert konsequent. Sie verschiebt den Fokus vom Produkt zum Lerngewinn. Gerade für Nachwuchs‑Entwicklerinnen und ‑Entwickler ist das befreiend: Ein Projekt darf scheitern – wenn es dich in Technologien hineinzieht, die dich sonst nie erreicht hätten.

Worauf kommt es also an? Auf realen Code, echten Austausch und sichtbare Zwischenresultate. Ein ambitioniertes Ziel setzt die Leitplanken, aber der Wert entsteht unterwegs: Wer einmal Netzwerkpakete überträgt, eine rudimentäre Render‑Pipeline zusammensteckt oder Input‑Latenzen jagt, lernt nicht nur APIs, sondern Denken in Abhängigkeiten, in Datenströmen, in Performance.

Von Spieltrieb zu Simulation: Brücken, die halten

In der Rolle als Senior Software Developer Simulation verknüpft Philipp genau diese Lernfelder. Er beschreibt prägnant, was Simulation bei TGW bedeutet:

Das ist kein akademischer Selbstzweck, sondern ein Versprechen an den Kunden – abgesichert durch virtuelle Modelle. Und genau hier treffen sich Game‑Dev‑Erfahrungen und industrielle Wirklichkeit:

• Simulationen und virtuelle Umgebungen verlangen präzises Modellieren von Zuständen, Regeln und Nebenbedingungen.
• Computergrafik schafft Visualisierungen, die komplexe Abläufe verständlich machen.
• Netzwerk- und Echtzeitdenken helfen, verteilte Prozesse zu orchestrieren.
• Performance als Leitmotiv bedeutet: warten ist keine Option.

Philipp bringt es auf den Punkt: „…es soll so schnell wie möglich gehen, da gibt es eigentlich kein Limit, was zu schnell sein könnte.“ Das ist die Ansage eines Entwicklers, der Performance als Produktmerkmal versteht – und als Kultur.

Performance: Wenn „schnell“ nicht reicht

„Keine Obergrenze.“ Dass Philipp das so klar formuliert, ist ungewöhnlich konkret – und gleichzeitig so pragmatisch, wie es in Simulation nur sein kann. Wer Simulation baut, kennt die zwei Takte des Alltags: Genauigkeit und Geschwindigkeit. Zu langsam? Die Antworten kommen nicht rechtzeitig. Zu ungenau? Die Antworten sind wertlos. Philipp wählt hier keine Seite; er zeigt, dass Performance ein nicht verhandelbarer Teil der Gleichung ist.

Für Entwicklungsarbeit bedeutet das:

• Profiling ist kein „später“, sondern Teil des Weges.
• Algorithmenwahl entscheidet über Machbarkeit – nicht nur über „Schönheit“.
• Skalierung zeigt Fehler gnadenlos. In kleinen Setups übersehene O(n²)‑Ecken werden bei großen Anlagen zur Bremse.

Seine Begründung ist explizit: „…weil viele Algorithmen einfach in der Größe von den Anlagen, die wir jetzt bauen, schon relevant werden, dass man sich das Algorithmus schon ein bisschen überlegt.“ Genau hier liegt die technische Würze der Simulation: Sie zwingt zu bewusster Komplexitätskontrolle. Wer so denkt, baut Systeme, die wachsen dürfen, ohne einzubrechen.

Modelle, die überzeugen – und warum Visualisierung mehr als „nice to have“ ist

Philipp spricht von „virtuellen Modellen“, die zeigen, „dass diese Abläufe und Prozesse auch wirklich die Performance liefern“. Der Anspruch dahinter ist zweifach:

• Intern müssen die Modelle dem realen Verhalten so nahe kommen, dass Auslastung, Durchsatz und Wartezeiten belastbar abgeschätzt werden können.
• Extern müssen Stakeholder – insbesondere Kunden – verstehen können, was sie sehen und warum es zählt.

Die Brücke schlägt die Visualisierung. Computergrafik ist für Philipp kein Gimmick, sondern Teil des Erkenntnisprozesses. Wer jemals an einer visuellen Debug‑Ansicht plötzlich „gesehen“ hat, wo ein Stau entsteht, weiß, warum.

Die Arbeitsweise: erst bauen, dann verstehen – und wieder bauen

Der Leitgedanke des Talks lässt sich in wenigen Sätzen festhalten. Philipp sagt:

Und weiter:

Wir lesen daraus eine dreistufige Praxis:

1. Fokus auf die ersten Zeilen: Reduziere die Distanz zwischen Idee und lauffähigem Code.
2. Setze dir ein anspruchsvolles Ziel: Wähle ein Projekt, das dich über deine Komfortzone hinauszieht.
3. Iteriere am Ergebnis: Lerne durch sichtbare Wirkung – nicht durch vollständige Vorabtheorie.

Das ist nicht Anti‑Theorie. Es ist Anti‑Paralyse. Philipp wendet sich gegen die Illusion, man könne Komplexität „vollständig verstehen“, bevor man anfasst. Wer baut, sieht – und wer sieht, versteht.

Was wir als Redaktion mitnehmen

Wir haben die Aussagen auf ihren Kern verdichtet und in fünf Leitsätzen formuliert, die sich direkt auf den Entwickleralltag übertragen lassen:

• Beginne klein, denke groß: Ein „Hello World“ als Startschuss, nicht als Selbstzweck. Direkt danach: ein Ziel, das dich streckt.
• Lerne an der Wirkung: Baue, miss, interpretiere, verbessere. Ohne Zwischenresultate bleibt Lernen abstrakt.
• Halte Performance sichtbar: Messe früh, messe oft. Beschleunigung ist kein Feinschliff, sondern integraler Bestandteil.
• Nutze Visualisierung als Denkwerkzeug: Was du sehen kannst, kannst du erklären – und verbessern.
• Akzeptiere Unfertigkeit: Projekte dürfen scheitern, wenn sie dich nachhaltig klüger machen.

Konkrete Schritte für Einsteigerinnen und Einsteiger

Philipp sagt: „Get started!“ Was heißt das praktisch? Aus seinen Aussagen lassen sich sofort umsetzbare Schritte ableiten:

• Wähle ein Mini‑Setup: Editor, Compiler/Interpreter, ein „Hello World“. Bringe es zum Laufen.
• Setze ein übergroßes Ziel: Ein kleines Spiel, ein Netzwerktool, eine simple Simulation – etwas, das dich reizt.
• Zerlege das Ziel in sichtbare Meilensteine: Input, Output, ein erster Loop, eine einfache Visualisierung.
• Lerne just‑in‑time: Recherchiere gezielt das, was den nächsten Meilenstein unblockt. Nicht mehr, nicht weniger.
• Arbeite iterativ: Ergebnisse zuerst, Verstehen folgt. Dann wieder Ergebnisse.
• Beobachte Leistung: Miss Laufzeit und Reaktionszeit. Merke dir, welche Änderungen was bewirken.

Dieser Plan ist absichtlich simpel. Er ist darauf ausgelegt, schneller in die Praxis zu kommen als in die Perfektion.

Für Fortgeschrittene: Algorithmisches Denken am Maßstab der Anlage

Philipp betont, dass Algorithmen in der Größe realer Anlagen „relevant“ werden. Das ist ein Wink an alle, die beruflich wachsen: Komplexität ist kein Theoriethema, sondern eine Produktionsfrage. Wenn du in Simulation, aber auch in Backend‑Systemen, Datenpipelines oder Rendering arbeitest, gilt:

• Kenne die Komplexität deiner Hot‑Paths. Ein scheinbar „akzeptabler“ Ansatz kann bei realen Dimensionen kippen.
• Entwirf für Beobachtbarkeit. Ohne Metriken, Logs und Visualisierungen wird Perf‑Arbeit blind.
• Plane Zeit für Performance‑Arbeit ein. Sie entsteht nicht als Nebenprodukt.

Diese Punkte lassen sich aus Philipps Performance‑Fokus unmittelbar ableiten – und sie sind anschlussfähig für verschiedene Domänen.

Warum Simulation Entwicklerinnen und Entwickler mit Game‑DNA anzieht

Philipp sagt klar, was ihn an seiner Arbeit fesselt: Simulationen, virtuelle Umgebungen, Computergrafik, Performance. Wer mit Gaming sozialisiert wurde, findet hier vertraute Koordinaten – aber mit einem Twist: Das Ziel ist nicht Unterhaltung, sondern Nachweis. Die Frage lautet nicht „macht es Spaß?“, sondern „liefert es die versprochene Performance?“ Gerade dieser Wechsel vom Spielraum zur Beweisführung kann enorm motivierend sein: Dinge, die man aus Leidenschaft gelernt hat, werden zu Werkzeugen, um reale Systeme verlässlich zu planen.

Lernen ohne Internet‑Komfort – und was davon bleibt

Ein interessantes Detail in Philipps Weg: „Internet war damals noch nicht so.“ Der Mangel an Ressourcen führte dazu, dass Versuch und Irrtum nicht nur Mittel, sondern Notwendigkeit waren. Heute ist der Zugang zu Wissen breiter denn je – und genau darin liegt die Gefahr, die Philipp anspricht: „…man bleibt leicht wo stecken … versucht alles irgendwie zuerst zu verstehen.“

Sein Gegenrezept bleibt gültig – vielleicht mehr denn je: weniger lesen, mehr bauen; gezielt lesen, wenn das Bauen stockt.

Ein Satz, der bleibt

Wenn wir sein Statement auf eine Essenz herunterbrechen müssten, wäre es dieser Appell:

Er klingt schlicht, doch in ihm steckt Praxisdisziplin: jeden Tag die Distanz zwischen Idee und Code minimieren.

Fazit: Ambition als Antrieb, Iteration als Methode

„Philipp Aumayr, Senior Software Developer Simulation bei TGW Logistics Group“ ist eine kurze, klare Einladung an alle, die Programmieren lernen oder vertiefen wollen. Die Geschichte führt vom QBasic‑Gorillaspiel über C und ein übergroßes Quake‑Ziel in eine Welt, in der Simulation Geschäftsversprechen überprüfbar macht – und Performance nie „genug“ ist.

Wir nehmen mit:

• Große Ziele sind kein Risiko, wenn du sie in kleine, sichtbare Schritte verwandelst.
• Scheitern an der Produktfertigstellung ist verkraftbar, wenn das Lernen maximal ist.
• Performance ist mehr als Optimierung: Sie ist eine Kultur der Aufmerksamkeit.
• Simulation verbindet Spieltrieb und Strenge – ein ideales Feld für Menschen, die gerne an Algorithmen, Grafiken und Modellen feilen.

Der erste Schritt ist der gleiche wie damals auf dem DOS‑386: Editor öffnen, eine Zeile schreiben, laufen lassen. Dann die zweite. Und die dritte. Get started.

• 

  

  Speed Up Your Pipeline

  Thomas Svoboda von TGW Logistics Group teilt in seinem devjobs.at TechTalk einige Ansätze, wie man Azure DevOps Pipelines optimieren könnte.

  Jetzt ansehen

• 

  

  Mario Leitner, Head of Software Development bei TGW Logistics Group

  Head of Software Development Intelligent Automation bei der TGW Logistics Group Mario Leitner spricht im Interview über den Aufbau der Devteams im Unternehmen, was Neuankömmlinge erwartet und welche Technologien verwendet werden.

  Jetzt ansehen
• 

  

  Klausmair Philipp, Head of Global Controls Tool Development bei TGW Logistics Group

  Head of Global Controls Tool Development bei der TGW Logistics Group Philipp Klausmair erzählt im Interview über das vergleichsweise neue Team im Unternehmen, wie dort das Recruiting abläuft und gibt Einblick in die verwendeten Technologien.

  Jetzt ansehen

• 

  

  Sascha Beyer, Full Stack Developer bei TGW Logistics Group

  Sascha Beyer von der TGW Logistics Group berichtet im Interview über seinen Werdegang, was er im Unternehmen als Full Stack Developer macht und gibt Tipps für Anfänger.

  Jetzt ansehen