Vom Visual-Basic-Würfelspiel zum ERP für Europas Logistik: Die Entwicklerreise von Tobias Hafner-Fuchs (ECO-Soft GmbH)

Ein Gespräch, das hängen bleibt

Wir bei DevJobs.at haben in der Session „Tobias Hafner-Fuchs, Full Stack Developer bei ECO-Soft“ mit Speaker Tobias Hafner-Fuchs von der ECO-Soft GmbH eine Laufbahn kennengelernt, die vieles auf den Punkt bringt, was gute Softwareentwicklung ausmacht: Neugier, Praxis, Kritikfähigkeit – und der Blick über den Bildschirmrand hinaus. Tobias startet sein Erzählen mit einer Erinnerung, die überrascht: „Zum ersten Mal programmiert habe ich tatsächlich in der vierten Klasse Hauptschule.“ Es beginnt mit einem simplen Würfelspiel in Visual Basic. Und von dort aus geht es – konsequent, kurvig, aber zielgerichtet – in Richtung Full-Stack-Entwicklung.

Was uns besonders auffiel: Tobias ordnet seine Stationen nicht als gerade Linie, sondern als Weg mit Umwegen, Pausen und Wiederanfängen. Eine Ausbildung mit Elektronikbezug, die Grundlagen in C, Digitaltechnik bis zur Frage „Wie funktioniert ein Computer überhaupt?“; später Java und C auf Mikrocontrollern; danach Bundesheer, berufliche Praxis in der Testautomatisierung; ein sozialwissenschaftliches Studium; und schließlich die Rückkehr in die Entwicklung – zuerst als Datenmanager mit SQL und R, heute als Full Stack Developer. „Jetzt bin ich quasi wieder ein Vollblutprogrammierer“, sagt er. Dieses Spannungsfeld aus Tiefe, Breite und Wiederentdeckung prägt das, was er heute tut: Ein ERP für die Logistikbranche entwickeln, die Waren quer durch Europa bewegt – mit all der Detailverliebtheit, die solche Systeme verlangen.

Erste Zeilen Code: Visual Basic in der Hauptschule

Dass eine Schulaufgabe den Funken zünden kann, zeigt Tobias’ Einstieg: „Wir haben gelernt, wie man mit Visual Basic so ein simples Würfelspiel programmiert.“ So unscheinbar ein Würfelspiel wirkt, so viel steckt darin: Zustand, Zufall, Logik, UI – und das unmittelbare Feedback, das Programmieren so motivierend macht. Gerade dieser frühe Zugang zur Praxis wirkt nach. Er ist der rote Faden, der sich durch Tobias’ Erzählung zieht: Man lernt Programmieren, indem man programmiert.

Das ist ein Leitspruch, den Tobias später explizit betont – und den man bereits in seinem frühen Start wiedererkennt. Wir nahmen aus der Session mit: Wer früh eigene Projekte baut, fühlt früher die Verantwortung für Designentscheidungen – und lernt schneller aus Fehlern.

Elektronikfokus, C und Digitaltechnik: Das Fundament wird breit

Nach der Hauptschule folgt der Weg in eine Ausbildung mit Elektronikschwerpunkt. Tobias spricht davon, dass „die ersten paar Jahre mit C so die Programmierbasics“ auf dem Programm standen – und daneben Digitaltechnik: „Wie funktioniert ein Computer überhaupt, wie kann man einen Prozessor selber nachbauen?“ Später kommt Java dazu, und in Werkstättenpraktika „ist es weitergegangen mit C auf Mikrocontroller“. Dieses Fundament ist bemerkenswert breit: Software in C und Java, zugleich Hardwareverständnis und Systemdenken. Wer einmal gesehen hat, wie ein Prozessor auf elementarer Ebene arbeitet, denkt anders über Algorithmen, Speicher, Nebenläufigkeit und Limitierungen nach.

Da Tobias in der Rückschau kein Buzzword-Bingo veranstaltet, sondern die Basics betont, bleibt für uns ein Punkt besonders präsent: Gutes Engineering entsteht dort, wo Abstraktionen verstanden werden – und wo man im Zweifel eine Ebene tiefer denken kann. Genau das klingt in seinen Stationen an: Von Visual Basic zu C, von OOP mit Java zu Mikrocontrollern und Digitaltechnik. Die Praxisnähe ist nicht bloß Tool-Wissen, sie ist Systemverständnis.

Bundesheer, Berufseinstieg und Testautomatisierung

Nach der Matura folgt der Präsenzdienst und dann der Einstieg in die Automatisierungsbranche. Tobias formuliert das nüchtern und präzise: „Ich habe da Tests automatisiert, also die Module, die meine Firma hergestellt hat, automatisiert getestet.“ Es ist ein Schritt, der zwei Dinge zeigt: erstens das Verständnis für industrielle Qualitätssicherung, zweitens die Nähe zur Realität von Produkten. Automatisiertes Testen ist keine Fußnote – es ist eine Haltung. Funktionen sind nicht fertig, wenn sie „auf meinem Rechner“ laufen; sie sind fertig, wenn sie robust, nachvollziehbar und prüfbar sind.

Wir sehen darin eine rote Linie, die sich bis in Tobias’ heutige Arbeit zieht: In komplexen ERP-Umgebungen ist jede automatisierte Prüfung eine Entlastung. Sie macht Verhalten explizit und in Spezialfällen – davon wird noch die Rede sein – überhaupt erst greifbar. Es lässt sich erahnen, wie die Erfahrung aus der Testautomatisierung hilft, wenn es später darum geht, jede Regel und Ausnahme sauber abzubilden.

Ein sozialwissenschaftlicher Exkurs – und warum er zählt

Dann kommt eine Wendung: „Ich habe tatsächlich was Sozialwissenschaftliches studiert“, sagt Tobias. Mehrere Jahre weg vom Programmieren. Erst danach der Wiedereinstieg – über ein Forschungsinstitut, wo er „einen Job als Datenmanager gekreilt“ hat. Dort arbeitet er „wieder verstärkt mit SQL“ und lernt „die Programmiersprache R, die sich für die Transformation von großen Datenmengen und für Machine Learning und Statistik eignet“.

Wir fanden bemerkenswert, wie nahtlos Tobias den Bogen spannt: Ein Studium, das sich vom Code entfernt, wird zum Sprungbrett in datenlastige Arbeit – und damit zurück in die Softwarewelt. Gerade R und SQL deuten auf eine Stärke hin, die im Backend und in ERP-Projekten Gold wert ist: das Denken in Daten, Transformationen und Nachvollziehbarkeit. Wer gelernt hat, große Datenmengen zu bewegen, wird in Geschäftsanwendungen präziser fragen: Woher kommt diese Zahl? Welche Regeln formen sie? Welche Spezialfälle machen sie kaputt? In Tobias’ Worten klingt es gelassen, aber klar: „Jetzt bin ich quasi wieder ein Vollblutprogrammierer.“

Full Stack bei ECO-Soft GmbH – mit klarer Backend-Präferenz

Tobias beschreibt seine Rolle bei ECO-Soft unprätentiös: „Ich kümmere mich ums Frontend, also um die grafische Oberfläche, und ums Backend, das ist das kompliziertere, coolere gleichermaßen.“ Und gleichzeitig: „Ich arbeite da die meiste Zeit im Backend, das heißt, ich stelle Daten bereit und programmiere die Funktionalitäten aus.“ Die Formulierung verrät viel über Haltung: Die Entscheidung, Daten sauber aufzubereiten und Funktionalitäten verlässlich zu implementieren, steht im Zentrum. Man könnte sagen, hier treffen die frühen Grundlagen (C, Java, Microcontroller) und die späteren Datenkompetenzen (SQL, R) aufeinander – eine Schnittmenge, die in Backend-Arbeit ebenbürtig ist.

Was uns als Redaktion beeindruckt: Tobias verwechselt Full Stack nicht mit „ein bisschen von allem“. Er beschreibt sachlich, wo sein Fokus liegt, und begründet ihn durch das, was ihm „mehr taugt“. Das ist ein Rat zwischen den Zeilen: In Full-Stack-Rollen hilft es, eine klare Stärke zu kultivieren – und gleichzeitig die Schnittstellen zur anderen Seite (Frontend) ernst zu nehmen.

Ein ERP für die Logistik: schnell getaktet, komplex – und voller Spezialfälle

Über das aktuelle Projekt könnte man lange sprechen, und Tobias’ wenige Sätze öffnen bereits eine Welt: „Wir programmieren ein ERP für ein Logistikunternehmen, das Waren durch halb Europa fahren lässt.“ Die Herausforderung beschreibt er so: „Die Logistikbranche [ist] ziemlich schnell getaktet und eigentlich recht komplex … unsere Supermärkte sind voll und die Sachen müssen da hinkommen, und das ist gar nicht so einfach.“ Es ist eine Erinnerung daran, dass jedes UI und jede API auf der anderen Seite Lastwagen, Fahrer, Lieferfenster und Kundenwünsche trifft – und dass Planung und Echtzeit sich reiben.

Dazu kommt eine zweite Achse der Komplexität: „Das ERP an sich programmieren, da muss man sehr detailverliebt sein, weil egal, jeder Kunde, jede Ware, jeder Transport kann einen Spezialfall zur Folge haben, den man ausprogrammieren muss.“ Dieser Satz ist für uns der Kern eines ERP-Projekts. Geschäftliche Regeln sind nie bloß Regeln. Sie sind Geschichten: von Ausnahmen, Übergängen, Aushandlungen. In Code übersetzt heißt das: robuste Datenmodelle, klare Zustände, explizite Regeln – und die Demut, dass man nie „alle“ Fälle gesehen hat. Spezialfälle sind keine Fehler im System; sie sind das System.

Aus Tobias’ Beschreibung lassen sich mehrere Konsequenzen ableiten, die wir als Redaktion für die tägliche Arbeit in solchen Projekten festhalten:

• Detailverliebtheit ist Tugend, nicht Selbstzweck. Sie sorgt dafür, dass Regeln nicht nur skizziert, sondern zu Ende gedacht werden.
• Spezialfälle sind Feature-Treiber. Wer sie ernst nimmt, verbessert das Produkt – nicht nur den Bugtracker.
• Datenbereitstellung ist Produktarbeit. Im Backend entscheidet sich, ob Informationen rechtzeitig, richtig und vollständig ankommen.

„Es gibt nicht den einen Ausbildungsweg“ – was wirklich zählt

Tobias macht unmissverständlich klar: „Es gibt jetzt auf jeden Fall nicht den einen Ausbildungsweg, damit man Softwareentwickler wird.“ Stattdessen nennt er zwei Dinge, die in seinen Augen entscheidend sind.

Erstens: Praxis. Oder in seinen Worten: „Programmieren lernt man, indem man Programme schreibt.“ Tobias verweist darauf, dass das Internet voll von Code-Challenges ist – und natürlich kann das ein Startpunkt sein. Wesentlicher finden wir die Haltung dahinter: Nicht warten, bis jemand ein Projekt zuweist. Nicht zaudern, ob man „bereit“ ist. Einfach bauen. Scheitern. Nachbessern. Wiederholen.

Zweitens: Code Reviews – und die Fähigkeit, Kritik nicht nur zu ertragen, sondern anzunehmen. „Den Code … von erfahrenen Leuten reviewen lassen und deren Kritik wirklich annehmen“, sagt er – und ergänzt, „die Methode, die ich jetzt so halb so verwendet habe, ist nicht die Beste.“ Das klingt lapidar, ist aber ein wesentlicher Reifegrad. Code-Qualität ist Teamarbeit. Stil, Struktur, Benennung, Testbarkeit, Performanz: Das meiste lernt man schneller, wenn jemand mit mehr Erfahrung draufblickt. Dazu gehört, wie Tobias es nennt, „Selbstreflexion“ – und die Einsicht: „Es gibt immer jemanden, der besser programmiert.“

Wir nehmen das als Ermutigung, nicht als Drohung. Wer das akzeptiert, öffnet sich für Weiterentwicklung – und genau die nennt Tobias ausdrücklich: „Bereitschaft zur Weiterentwicklung“ als Grundhaltung.

Über den Bildschirmrand hinausdenken: Software als Antwort auf echte Probleme

In einem Satz fasst Tobias eine der wichtigsten Fähigkeiten für Produktteams zusammen: „Sehr wichtig ist … dass man über den Bildschirmrand hinausdenken kann, weil die Lösungen, die wir entwickeln, die sollen ja Probleme aus der echten Welt lösen.“ Das ist ein Aufruf, Geschäftsdomänen ernst zu nehmen. Nicht nur im Sinne „Was ist die Akzeptanzkriterium-Checkliste?“, sondern tiefer: Wie funktioniert der Alltag der Menschen, die das nutzen? Welche Zwänge, welche Taktung, welche Fehlerquellen? Tobias’ Beispiel – Logistik – macht die Dringlichkeit sichtbar: „Die Supermärkte sind voll und die Sachen müssen da hinkommen.“

Wir sehen darin drei konkrete Arbeitsprinzipien:

• Domänenverständnis ist Teil der Engineering-Aufgabe. Es reicht nicht, die API zu bauen; man muss verstehen, welche Realität sie repräsentiert.
• Realität schlägt Ideallinie. Wenn Prozesse schnell getaktet und komplex sind, braucht es Lösungen, die unter Druck zuverlässig funktionieren.
• Empirie vor Theorie. „Die echte Welt anschauen und verstehen“ – so formuliert Tobias – ist keine Metapher, sondern eine Arbeitsweise: beobachten, nachfragen, validieren.

Von der Praxis zur Praxis: Wie Tobias’ Weg Entscheidungen prägt

Was bleibt, wenn man Tobias’ Stationen als Ganzes betrachtet? Uns fallen vier Fäden auf, die sich immer wieder kreuzen:

1) Grundlagenkompetenz: Früh C und Java, dazu Digitaltechnik – das sind keine Zufälle, sondern feste Pfeiler. Sie machen es leichter, heute im Backend saubere Funktionalität und Datenflüsse zu bauen.

2) Test- und Qualitätsdenken: Wer Module automatisiert testet, verinnerlicht, dass die Definition von „fertig“ mehr ist als „kompiliert“ oder „läuft“. In einem ERP mit Spezialfällen ist das entscheidend.

3) Datenbewusstsein: SQL und R in einem Forschungsumfeld schulen das Denken in Transformationen, Aggregationen und Nachvollziehbarkeit – Fähigkeiten, die man in der Backend-Arbeit täglich braucht.

4) Lernhaltung: Sozialwissenschaften, Rückkehr in die Entwicklung, die Offenheit für Code Reviews, der Wille zur Weiterentwicklung – all das zeigt: Lernen ist kein Modus, den man irgendwann ausschaltet. Es ist die Arbeitsweise.

Praktische Handläufe: Was Entwickler:innen aus dieser Story ableiten können

Ohne über die Session hinaus zu spekulieren, lassen sich aus Tobias’ Aussagen konkrete Handgriffe ableiten, die jede:r in den Alltag übernehmen kann:

• Klein anfangen, konkret bauen: Ein „simpeles Würfelspiel“ ist nicht banal – es ist der erste Prototyp, der zusammenhängend funktioniert. Kleine Projekte, klare Ergebnisse.
• Regeln explizit machen: Wenn „jeder Kunde, jede Ware, jeder Transport einen Spezialfall“ erzeugen kann, gehört jede Annahme aufgeschrieben – und idealerweise getestbar gemacht.
• Code Reviews suchen, nicht fürchten: Aktiv nach Feedback fragen, die Kritik „wirklich annehmen“, wie Tobias sagt, und gezielt Varianten ausprobieren.
• Daten als Produkt sehen: „Daten bereitstellen“ ist nicht Infrastruktur-Grauzone, sondern Kern der Funktionalität. Wer Daten liefert, liefert Produktwert.
• Domäne verstehen: Über den „Bildschirmrand“ hinaus beobachten, nachfragen, mitdenken. Nur so lässt sich die Lücke zwischen Logik und Alltag schließen.
• Wachstum als Haltung leben: „Es gibt immer jemanden, der besser programmiert“ – das ist kein Urteil, sondern eine Einladung: Was lerne ich als Nächstes? Wo hole ich mir Review? Welche Praxis übe ich heute?

Logistik, ERP und die Kunst, Ausnahmen zu bauen

Tobias’ knappe Beschreibung des ERP-Projekts bietet einen wichtigen Realitätscheck: In bewegten Domänen sind Ausnahmen die Norm. Das gilt umso mehr, wenn die Taktung hoch ist. Für Entwickler:innen bedeutet das:

• Zustände modellieren, nicht improvisieren: Wer Zustandswechsel explizit macht, kann Sonderfälle gezielt anschließen, statt sie überall „durchzuschlängeln“.
• Fehler als Entwurfssignale lesen: Tritt ein Spezialfall auf, zeigt er selten nur „falsches Verhalten“. Oft zeigt er eine Lücke im Modell oder in der Kommunikation.
• Robustheit über Perfektion stellen: In schnellen Umgebungen ist ein klarer, nachvollziehbarer Flow oft wertvoller als die vermeintlich „optimale“ Variante, die keiner versteht.

Wir fanden in Tobias’ Erläuterung die freundliche Mahnung: Detailverliebtheit ist nicht Pedanterie, sondern Kundenschutz. Sie bewahrt davor, dass aus einem „Ach, das wird schon passen“ später ein Lieferausfall wird. Sie sorgt dafür, dass Systeme auch im Ausnahmezustand sinnvoll reagieren.

Full Stack mit Bodenhaftung: Fokus ohne Tunnelblick

Tobias nennt Frontend und Backend – und dann seinen klaren Schwerpunkt: „Ich arbeite da die meiste Zeit im Backend.“ Diese Klarheit schafft Fokus. Zugleich bewahrt der Full-Stack-Rahmen vor Isolation. Wer Daten bereitstellt und Funktionalität ausprogrammiert, versteht besser, wie UI und Use Cases daran andocken. Genau diese Teamfähigkeit ist es, die wir in seinen Aussagen zur Realität und den echten Problemen wiedererkennen. Full Stack ist hier nicht Selbstzweck, sondern ein Mittel, um Ende-zu-Ende-Verantwortung zu fühlen.

Für Teams heißt das: Rollen klar benennen, Stärken nutzen – und Schnittstellen pflegen. Die beste Backend-Funktionalität hilft nichts, wenn die Oberfläche sie nicht verständlich macht; die beste UI verpufft, wenn sie auf falsche oder späte Daten wartet. Tobias’ Beschreibung lässt vermuten: Es ist diese Verbindung – Daten, Funktion, Oberfläche – die in seinem Arbeitsalltag zählt.

Lernkurve ohne Endpunkt: Kritikfähigkeit als Motor

Die vielleicht persönlichste Stelle in Tobias’ Ratschlägen ist die über Code Reviews. „Oft auch einsehen, die Methode, die ich jetzt so halb so verwendet habe, ist nicht die Beste“, sagt er. Der Satz klingt leicht, aber er verlangt viel: die Fähigkeit, die eigene Lösung nicht mit der eigenen Person zu verwechseln. In Teams ist das eine Schlüsselkompetenz. Sie macht Geschwindigkeit möglich, weil sie Diskussionen versachlicht. Sie macht Qualität möglich, weil sie Alternativen zulässt. Und sie macht Freude möglich, weil Lernen zur gemeinsamen Leistung wird.

Für alle, die sich fragen, wie man diese Haltung trainiert, bietet Tobias’ Weg eine Antwort: Praxis plus Feedback. Nicht nur bauen, sondern auch zeigen. Nicht nur lesen, sondern auch umstellen. Nicht nur rechtfertigen, sondern auch loslassen. So wächst der Kompass, der in komplexen Domänen – wie der von Tobias beschriebenen Logistik – so dringend gebraucht wird.

Fazit: Eine realitätsnahe, lernende Softwarekarriere

„Tobias Hafner-Fuchs, Full Stack Developer bei ECO-Soft“ ist in unserem Rückblick mehr als eine Jobbezeichnung. Es ist eine Geschichte, die mit einem Visual-Basic-Würfelspiel beginnt und heute ein ERP für ein Logistikunternehmen mit europaweiter Reichweite umfasst. Dazwischen liegen C und Java, Digitaltechnik und Mikrocontroller, automatisierte Tests, ein sozialwissenschaftliches Studium, Datenmanagement mit SQL und R – und eine klare Haltung:

• Programmieren lernt man, indem man programmiert.
• Qualität wächst im Review.
• Es gibt immer jemanden, der besser programmiert – und das ist gut so.
• Über den Bildschirmrand hinaus denken, die echte Welt anschauen und verstehen.

Wir nehmen aus der Session mit Speaker Tobias Hafner-Fuchs von der ECO-Soft GmbH vor allem eines mit: Diese Mischung aus Basiswissen, Praxis, Kritikfähigkeit und Domänenblick ist kein Zufall, sondern gelebte Professionalität. Wer sie pflegt, baut Systeme, die nicht nur funktionieren – sondern in der Realität bestehen. Genau dort, wo Lkws fahren, Supermärkte gefüllt werden und Spezialfälle zur Tagesordnung gehören.

• 

  

  Hans Burgstaller, Full Stack Developer bei ECO-Soft

  Hans Burgstaller von ECO-Soft gibt im Interview Einblicke in die Entstehung des Unternehmens, das heutige Development Team, die Technologien die dort zum Einsatz kommen und wie das Recruiting im Unternehmen gestaltet ist.

  Jetzt ansehen
• 

  

  Florian Knoll, Full Stack Developer bei ECO-Soft

  Florian Knoll von ECO-Soft beschreibt im Interview das Team des Unternehmens, den Ablauf des Bewerbungsprozesses und gibt Einblicke in die technologischen Challenges.

  Jetzt ansehen

• 

  

  Bastian Schmidt, Software Developer bei ECO-Soft

  Bastian Schmidt von ECO-Soft redet in seinem Interview von seinem Werdegang als Developer – von den frühen Anfängen, bis hin zur aktuellen Arbeit als Developer – und welche Tipps er für Anfänger hat.

  Jetzt ansehen
• 

  

  Ricardo Reindl, Software Developer bei ECO-Soft

  Ricardo Reindl von ECO-Soft erzählt in seinem Interview von den spielerischen Anfängen während der Schulzeit und über seinen weiteren Werdegang bis zum Software Development – und was das Wichtigste für Neueinsteiger ist.

  Jetzt ansehen
• 

  

  David Kandler, Software Developer bei ECO-Soft

  David Kandler von ECO-Soft spricht in seinem Interview davon, wie er seinen beruflichen Wechsel ins Software Development durchgezogen hat, wie er im Unternehmen gestartet hat und welche Tipps er für Beginner geben kann.

  Jetzt ansehen