Vom HTL-Klassenzimmer ins Framework-Team: Jakob Wegenschimmel (RZL Software GmbH) über C#, API-Ergonomie und die Kraft starker Grundlagen

Ein devstory-Porträt: Wer ist der Entwickler hinter dem Framework?

In der devstory-Session „Jakob Wegenschimmel, Software Developer bei RZL Software“ (Speaker: Jakob Wegenschimmel, Company: RZL Software GmbH) begegnen wir einem Entwickler, dessen Weg klar von Neugier, Konsequenz und Freude am Programmieren geprägt ist. Sein roter Faden: C#. Seine Bühne: ein Framework-Team, das interne Basis-Komponenten baut. Seine Botschaft: Spaß, solide Kernkonzepte und gute API-Designs sind mehr als Technik—sie sind Hebel für Qualität und Tempo in der gesamten Organisation.

Wir bei DevJobs.at haben aufmerksam zugehört: Es ist eine kompakte Geschichte, aber sie trägt viele Lehren für Menschen, die eine Laufbahn in der Software-Entwicklung planen oder gerade in ihre Rolle hineinwachsen. Diese Story zeigt, wie aus einem Fokus auf Grundlagen und Developer Experience (DX) im Kleinen eine große Wirkung im Alltag vieler Teams entsteht.

HTL, C und C++: Das Fundament technischer Präzision

Jakob Wegenschimmel zeichnet seine Laufbahn vom Schulbeginn bis zum heutigen Tag nach. Der Ausgangspunkt: die HTL in Braunau, mit starkem Fokus auf Softwareentwicklung.

• Die ersten drei Jahre: C und C++ als Basis. Diese Sprachen schulen präzises Denken, Speicher- und Typdisziplin sowie systemnahes Verständnis.
• Darauf aufbauend kamen C# und Java gleichzeitig ins Programm. Die didaktische Idee dahinter: eine Brücke von systemnahen Grundlagen hin zu höheren Abstraktionsebenen und produktiver Anwendungsentwicklung.

Aus dieser Mischung wählt Jakob früh sein Terrain. Er sagt sinngemäß: C# fühlte sich für ihn richtig an, es machte ihm schlicht mehr Spaß als die Alternativen. Dieser Punkt ist entscheidend: Er stellt Freude als legitimen Kompass in den Vordergrund—nicht als nice-to-have, sondern als Kriterium, das Lernkurven glättet und Durchhaltevermögen erzeugt.

C# als Leitplanke: Matura-Projekt und erste Berufserfahrung

Konsequenz ist ein wiederkehrendes Muster. Jakob bleibt bei C#, setzt damit sein Matura-Projekt um und startet direkt nach der HTL in den Beruf—als Trainer für Softwareentwickler:innen in C#. Wer schon einmal unterrichtet hat, kennt den Effekt: Das Erklären zwingt zur Klarheit. Jakob sagt offen, dass er C# „ehrlicherweise da am besten gelernt“ hat—beim Lehren.

Diese Lernbewegung ist typisch: Wer Inhalte so strukturieren muss, dass sie bei anderen funktionieren, baut ein tiefes, stabiles Mentales Modell der Technologie auf. Nicht jede Karriere enthält die Station „Trainer“, aber die Erkenntnis lässt sich verallgemeinern: Der schnellste Weg, etwas wirklich zu verstehen, ist häufig, es anderen beizubringen—sei es in internen Brown-Bag-Sessions, Pair Programming oder Peer-Reviews.

Heute bei RZL Software GmbH: Arbeiten im Framework-Team

Jakob arbeitet bei der RZL Software GmbH weiterhin mit C#—und zwar in einem Framework-Team, das nach seiner Beschreibung „je nachdem wie man zählt, drei, vier, fünf Leute“ umfasst. Die Aufgabe: Komponenten bauen, die anschließend von Produktteams genutzt werden.

• „Basisframeworks für alles Mögliche“: Das Spektrum ist breit, denn Anforderungen kommen aus ganz unterschiedlichen Produktbereichen.
• Jede neue Anforderung bringt neue Herausforderungen. Das Team übersetzt sie in robuste Bausteine.
• Zielbild: APIs und Frameworks, die so anwenderfreundlich wie möglich sind, weil gute APIs weniger Raum für Fehler lassen.

Für uns ist das ein zentrales Motiv dieser devstory. Ein Framework-Team ist Multiplikator: Gutes API-Design reduziert die Fehlerquote in vielen Produktlinien gleichzeitig, es senkt Einarbeitungszeiten, macht bessere Defaults leicht zugänglich und lenkt Entscheidungen in sichere Bahnen. Das ist technischer Hebel und Organisationshebel in einem.

Warum API-Ergonomie Qualität und Tempo zugleich steigert

Wenn Jakob betont, dass anwenderfreundliche APIs weniger Fehler erzeugen, steckt viel Erfahrung in einem Satz. Was macht APIs „anwenderfreundlich“—und warum ist das so wirksam?

• Eindeutigkeit statt Ambiguität: Benennungen, Parameterreihenfolgen und Rückgabewerte müssen so gestaltet sein, dass falsche Annahmen praktisch nicht entstehen.
• Sinnvolle Defaults: Voreinstellungen, die in der Mehrzahl der Fälle „richtig“ sind, verkürzen die Zeit bis zum ersten Erfolg und verhindern Fehlkonfigurationen.
• Leitsysteme im Kleinen: Intuitive Typen und methodische Pfade führen Entwickler:innen durch die Domäne, ohne sie mit Implementation Details zu belasten.
• Fehler früh sichtbar machen: Ungültige Zustände gar nicht erst konstruierbar zu machen (oder zumindest sofort zu signalisieren) reduziert langwieriges Debugging.
• Konsistenz als Navigationshilfe: Was in Modul A gilt, muss in Modul B genauso gelten. Konsistenz senkt die kognitive Last und verhindert Copy-Paste-Fallen.

Jakobs Formulierung ist pragmatisch: Mit guten APIs baut man weniger Fehler ein. Das ist keine ästhetische Maxime, sondern eine Qualitätsstrategie. Und sie wirkt—besonders in Teams, die, wie bei ihm, Komponenten für viele andere Teams bereitstellen.

Das Spannungsfeld eines Framework-Teams

Welche Herausforderungen impliziert diese Rolle? Die devstory lässt uns Einblicke gewinnen, die sich in viele Organisationen übertragen lassen:

• Generisch vs. spezifisch: Komponenten sollen möglichst breit wiederverwendbar sein, ohne die konkreten Bedürfnisse der Produktteams zu ignorieren.
• Stabilität vs. Evolution: APIs stabil halten, aber nicht stagnieren. Design-Entscheidungen brauchen Weitblick und Respekt vor bestehender Nutzung.
• Geschwindigkeit vs. Gründlichkeit: Anforderungen kommen im Takt der Produktroadmaps. Ein Framework-Team muss richtig priorisieren und trotzdem Sorgfalt bewahren.

Jakob beschreibt das als „spannend“—und das spürt man: Immer neue Anforderungen, immer neue Lerngelegenheiten. Genau dieses Wechselspiel macht die Attraktivität der Rolle aus.

Ohne Studium zum Developer: Grundlagen schlagen Titelsammlung

Jakob adressiert ein Thema, das viele umtreibt: akademischer Abschluss vs. Praxis. Seine Haltung ist klar.

Für den Einstieg spielt die konkrete Sprache laut Jakob eine untergeordnete Rolle. Entscheidend ist, die „Kernkonzepte“ zu lernen. Dann ist der Wechsel auf andere Technologien relativ leicht.

Diese Perspektive ist entlastend und anspruchsvoll zugleich: Es gibt keinen Abkürzungsweg um die Grundlagen herum—aber man kann ihn in vielen Sprachen gehen. Spaß ist dabei kein Luxus, sondern Treibstoff. Wer Freude an seiner Wahl hat, lernt tiefer und konstanter.

Welche Kernkonzepte tragen am weitesten?

Jakobs Empfehlung „Kernkonzepte zuerst“ lädt ein, die eigenen Schwerpunkte zu justieren. Welche Konzepte sind in vielen Sprachen und Technologien anschlussfähig?

• Abstraktion und Modularität: Wie kapselt man Komplexität, wie schneidet man Verantwortlichkeiten? Das ist universell.
• Datenstrukturen und „Denkwerkzeuge“: Listen, Maps, Sets, Graphen—nicht nur kennen, sondern einsetzen und abwägen.
• Kontrollfluss und Fehlerbehandlung: Robuste Pfade, explizite Fehlerfälle, defensive Programmierung.
• Schnittstellendesign: Wie gestalte ich Methoden, Klassen oder Komponenten so, dass sie klar, sicher und konsistent sind?
• Testbarkeit: Wie schreibe ich Code, der testbar ist—und wie nutze ich Tests als Designfeedback?
• Nebenläufigkeit und Zustände: Auch wenn man sie nicht täglich manuell handhabt, ist Verständnis für Zustandschoreografien ein Vorteil.
• Versionsdenken: Wie entwickle ich etwas weiter, ohne bestehende Nutzer:innen zu brüskieren? Semantik und Kommunikationsdisziplin.

Diese Liste ist kein Curriculum aus Jakobs Mund, sondern eine Ableitung aus seiner Betonung der Basics. Sie macht jedoch greifbar, was „Kernkonzepte“ im Alltag bedeuten können.

Lernpfade mit Freude als Kompass

Die devstory unterstreicht, wie wirksam Freude als Orientierung ist. Jakobs Weg zeigt: Die anziehende Technologie wählen, dranbleiben, Projekte bauen, Wissen teilen. Ein möglicher Fahrplan, der zu seiner Haltung passt:

1. Eine Sprache wählen, die Spaß macht—ausprobieren, vergleichen, entscheiden.
2. Ein persönliches Projekt umsetzen—klein starten, iterativ erweitern.
3. Wissen laut denken—Blog-Notizen, interne Sessions, Peer-Reviews.
4. Gewohnheiten aufbauen—regelmäßiges Refactoring, Tests als Designpartner, Lesbarkeit als Standard.
5. Schnittstellen üben—kleine APIs im Kleinen entwerfen, Rückmeldungen einholen, konsequent vereinfachen.

Das Ziel ist nicht, alles zu kennen, sondern Muster zu erkennen. Wer Kernmuster verinnerlicht, wechselt leichter die Sprache oder Plattform—genau, wie Jakob es beschreibt.

Trainer-Mindset: Lernen, indem man erklärt

Jakob hat C# nach eigener Aussage dort „am besten gelernt“, wo er es erklärt hat—als Trainer. Dieser Punkt lässt sich verallgemeinern, ohne dass man eine offizielle Trainerrolle braucht:

• Eigene Entscheidungen begründen: „Warum habe ich dieses Interface so geschnitten?“ Wer das erklären kann, hat verstanden.
• Code-Reviews mit Fokus auf Lerneffekt: Nicht nur Fehler suchen, sondern Konzepte explizit machen.
• Mini-Workshops im Team: 30 Minuten zu einem Thema, das man gerade verstanden hat—leichtgewichtig, wirkungsvoll.

Lehren zwingt zu Klarheit. Klarheit produziert bessere APIs. Bessere APIs reduzieren Fehler. Die Kette schließt sich und führt zurück zu Jakobs Kernaussage.

Alltag im Framework-Team: Wirkung im Multiplikator

Die Wirkung eines Framework-Teams bemisst sich nicht nur in Features, sondern in Reibungsreduktion für viele Teams. Wenn die Komponenten stimmen, werden Produktteams schneller, integrativer und konsistenter. Aus unserer Sicht zeigen Jakobs Einblicke drei Konsequenzen für den Alltag:

• Dokumentation als Guidance: Gute APIs sind selbsterklärend, doch prägnante Begleittexte beschleunigen den ersten Kontakt.
• Feedback-Schleifen mit Produktteams: Die besten Vereinfachungen entdeckt man in echten Nutzungsszenarien.
• Bewusste Kompromisse: Nicht alles muss generisch sein. Manchmal ist eine spezifische, aber sehr gute Lösung wertvoller als ein allgemeines, aber sperriges Framework.

Wenn Jakob von „neuen Herausforderungen“ bei jeder Anforderung spricht, ist das Ausdruck dieses Austarierens.

Von der Sprache zur Denkweise: Technologien wechseln gekonnt

Jakobs Rat, sich nicht auf eine Technologie festzulegen, sondern die „Kernkonzepte“ zu beherrschen, enthält eine strategische Komponente: Wer Denken lernt, kann Werkzeuge tauschen. Und wer Werkzeuge tauscht, bleibt anschlussfähig, wenn Projekte oder Firmenlandschaften sich ändern.

• Die Wahl der ersten Sprache prägt den Stil, aber sie definiert nicht die Karriere.
• Musterkompetenz schlägt Toolkompetenz: Mit zwei, drei starken Mustern kann man viele Probleme lösen.
• Wechselkosten sinken, wenn man bewusst Portabilität trainiert: gleiche Idee, neue Syntax—die Brücke wird kürzer.

Jakobs eigener Weg bestätigt das: vom C/C++-Fundament zu C#—mit Java im Curriculum—und anschließend eine Spezialisierung, die durch Spaß und Praxis verstärkt wurde.

Der Pragmatismus der Freude

Was uns an dieser devstory überzeugt, ist ihr Pragmatismus. Es ist kein ideologischer Monolog über „die beste Sprache“. Es ist die einfache, wirkungsvolle Formel:

• Wähle, was dir Spaß macht.
• Lerne die Grundlagen gründlich.
• Baue Dinge, die andere nutzen können.
• Gestalte die Schnittstellen so, dass sie dich und andere vor Fehlern schützen.

Diese Haltung ist robust. Sie funktioniert in Ausbildungssettings, in Produktteams und besonders in Rollen, die wie Jakobs Aufgabenfeld als Framework-Team das ganze System beschleunigen sollen.

Konkrete Anstöße für Einsteiger:innen und Aufsteiger:innen

Die Aussagen aus der Session lassen sich in konkretes Handeln übersetzen. Einige Anstöße:

• Fokus auf Basics: Schreib kleine Bibliotheken oder Utilities, bei denen du Schnittstellen aktiv gestaltest. Reflektiere, wo Nutzer:innen scheitern könnten.
• Üben, was du erklären kannst: Dokumentiere Entscheidungen kurz und bündig. Wenn es schwer ist, ist das ein Signal für Vereinfachungspotenzial.
• Fehlerarme Defaults: Wenn du eine Option nicht wählen würdest, warum existiert sie? Streiche, vereinheitliche, setze sinnvolle Standards.
• Iterativ vereinfachen: Eine API, die heute einfach wirkt, war gestern noch komplizierter. Kleinere, häufige Verbesserungen zahlen sich aus.
• Sprache als Vehikel, nicht als Identität: Wenn morgen ein anderes Tool sinnvoller ist, wechsle. Deine Konzepte gehen mit dir.

Diese Punkte ergänzen Jakobs Kernbotschaften und bieten eine Brücke in die tägliche Praxis.

Zentrale Aussagen von Jakob Wegenschimmel im Wortlaut

Einige seiner Sätze sind so prägnant, dass sie für sich stehen können:

Diese Zitate verdichten den Pfad: Freude → Fokus → Lehre → Framework → API-Qualität → Wirkung.

Fazit: C# als roter Faden, Grundlagen als Sprungbrett

Die devstory „Jakob Wegenschimmel, Software Developer bei RZL Software“ (Speaker: Jakob Wegenschimmel, Company: RZL Software GmbH) zeigt einen Weg, der gleichzeitig spezifisch und universell ist. Spezifisch, weil C# für Jakob zum produktiven, glücklichen Arbeitsmittel wurde. Universell, weil hinter dieser Wahl ein Prinzip steht: Lerne die Grundlagen, folge der Freude, gestalte Schnittstellen, die andere tragen.

Für uns ist das die Quintessenz aus Jakobs Erfahrung im Framework-Team: Gute APIs sind verdichtete Fürsorge für Entwickler:innen. Sie minimieren Fehler, maximieren Tempo und machen das, was wir alle wollen, wahrscheinlicher—dass Software, die wir bauen, zuverlässig wirkt und gerne genutzt wird.

• 

  

  Herbert Windsperger, Scrum Master bei RZL Software

  Scrum Master von RZL Software Herbert Windsperger spricht im Interview über das Besondere der Dev-Teams, was Neuankömmlinge im Unternehmen erwartet und welche technologischen Herausforderungen es gibt.

  Jetzt ansehen