Vom Zufall zur Verantwortung: Michael Sattlers Weg vom C-Einstieg zur Kubernetes-Infrastruktur bei nexyo GmbH

Einleitung: Ein DevJobs.at-Porträt über Neugier, Breite und pragmatisches Lernen

Als wir „Michael Sattler, Software Engineer bei nexyo“ gehört haben, blieb uns vor allem eines hängen: die ehrliche Einfachheit, mit der er seinen Weg beschreibt. Kein dramatisches Narrativ, kein künstlicher Spannungsbogen – sondern eine nüchterne, klare Geschichte darüber, wie ein glücklicher Zufall, konsequente Neugier und pragmatische Lerngewohnheiten einen Menschen in eine Rolle geführt haben, die heute Frontend, Backend und Infrastruktur zusammenbringt.

Was uns besonders angesprochen hat, ist die Natürlichkeit, mit der Michael Sattler die Stationen seines Werdegangs benennt: Er kommt aus der Elektrotechnik, lernt mit 19 Jahren zum ersten Mal C, wird von der Art des Problemlösens „gehuckt“, spürt die unmittelbaren Resultate der eigenen Arbeit – und entscheidet nach dem Studium, dass ihm die programmierorientierten Fächer mehr bedeuten als die Elektrotechnik selbst. Ab da folgt er diesem Impuls konsequent: erste Schritte im Frontend, dann vertiefter Einstieg ins Backend, vor allem in Golang, und schließlich das große Ganze – Infrastruktur, Kubernetes, Helm, Terraform, Produktweiterentwicklung und der tägliche Austausch mit Kolleginnen und Kollegen.

In dieser Zusammenfassung zeichnen wir die Punkte nach, die Michael Sattler setzt, und halten die Erkenntnisse fest, die wir als DevJobs.at-Redaktion daraus mitnehmen: ein Beispiel für serendipitären Einstieg, eine Einladung zum problemgetriebenen Lernen und ein Bild davon, wie breit und kollaborativ moderne Software-Engineering-Arbeit sein kann.

Der glückliche Zufall als Türöffner

Gleich zu Beginn benennt Michael Sattler, was bei vielen Karrieren im Tech-Bereich eine Rolle spielt: Unerwartete Momente öffnen Türen. In seinem Fall war es nicht der frühe Kindheitskontakt mit Computern, sondern ein Schritt während des Elektrotechnikstudiums, der den Kurs veränderte.

Er beschreibt, wie er erst mit 19 das erste Mal in einer Programmiersprache arbeitet. Es ist C – „sehr maschinennahe, auch nicht ganz so einfach zum Reinkommen“. Dieses Detail sagt viel aus: C verlangt Aufmerksamkeit und Disziplin, und genau diese erste Hürde macht den anschließenden Effekt so eindrücklich. Sattler spricht davon, „total gehuckt“ gewesen zu sein. Was ihn gepackt hat, ist die Art, Probleme anzugehen, sowie die Erfahrung, schnell Resultate zu sehen. Das passt „für [seine] Art zu denken“ – und setzt etwas in Bewegung, das sich durch sein weiteres Studium und die Jobwahl nach dem Abschluss zieht.

Warum Programmieren: Die Anziehung unmittelbarer Resultate

Für uns stand in diesem Satz das Kernmotiv seines Einstiegs: Programmieren liefert ein direktes Feedback. Dieses Dichteverhältnis von Idee, Umsetzung und sichtbarem Ergebnis kann unglaublich motivierend sein, besonders dann, wenn man eine Denkweise mitbringt, die iterative Lösungsfindung schätzt.

Sattler verknüpft das explizit mit seiner persönlichen Art des Denkens. Statt mit großen Visionen zu beginnen, stellt er das spürbare Resultat in den Vordergrund. Was folgt, ist keine spektakuläre Kurve, sondern die klare Feststellung, dass ihm „die programmierorientierten Fächer einfach am besten gefallen haben“. Diese Einsicht ist klein in der Formulierung – und groß in der Wirkung. Denn sie erklärt direkt, warum er nach dem Studium „auf die Suche [geht] nach einer Software Engineering Stelle“.

Von der Elektrotechnik in die Software: Eine bewusste Entscheidung

Wir hören in dieser Aussage einen pragmatischen Übergang. Es ist kein Bruch mit der Elektrotechnik; vielmehr eine Entscheidung, dem stärkeren Interesse zu folgen. Dass der erste Kontakt in C stattfand – „sehr maschinennah“ und „nicht ganz so einfach“ – unterstreicht, dass die Motivation nicht aus Bequemlichkeit erwachsen ist. Sie entsteht aus der Freude am Lösen und am Erleben unmittelbarer Fortschritte.

Für viele Leserinnen und Leser dürfte genau das vertraut wirken: Man probiert etwas Neues, das zunächst anstrengend ist – und bemerkt dann, wie sehr das eigene Denken diese Art von Feedback belohnt. In Sattlers Fall führte das geradeaus zum Berufseinstieg in die Softwareentwicklung.

Frontend, Backend, Infrastruktur: Die Breite der Rolle

Die berufliche Entwicklung, die Michael Sattler skizziert, ist die eines Engineers, der seine Perspektive stetig ausweitet. Zuerst Frontend – die sichtbare Seite des Produkts. Dann ein wachsendes Interesse am Backend – „vor allem in Golang“. Die Wortwahl „reingewachsener“ deutet darauf hin, dass es keine Abrisskante gab, kein Entweder-oder. Eher eine kontinuierliche Bewegung, die auf der anfänglichen Begeisterung für Problemorientierung aufbaut.

Hier verschiebt sich die Linse noch einmal: von der einen Codebasis hin zu Systemen, die den Betrieb und die Weiterentwicklung des Produkts ermöglichen.

Kubernetes, Helm, Terraform: Infrastruktur als koordinierte Praxis

Damit benennt Sattler den Werkzeugkasten, mit dem er heute regelmäßig arbeitet. Die Kombination aus Kubernetes, Helm und Terraform steht für den Schritt von der einzelnen Anwendung zur verwalteten Umgebung: Deployments, Paketierung, Definition und Management von Infrastruktur. In seinem Tonfall bleibt das unaufgeregt – es ist Alltag. Und genau das ist die Aussage: Aus der anfänglichen Neugier für Problemlösung wird eine Routine aus Infrastrukturkoordination, die dem Produkt den Boden bereitet.

Bemerkenswert ist, wie selbstverständlich in seinem Bild von Arbeit technische Werkzeuge und Teamarbeit zusammengehen. Die Erwähnung des Deployments und des Managements verweist auf Verantwortung, die nicht an einer Component-Grenze endet. Der Blick ist auf das Gesamtsystem gerichtet.

Produktfokus und Teamarbeit: Diskussionen als Teil des Jobs

Sattler beschreibt nicht nur Tools und Tätigkeiten, sondern auch das Miteinander: Das Vorantreiben des Produkts ist keine isolierte Aufgabe, sondern geschieht im Gespräch – „viele Diskussionen“. In dieser knappen Formulierung steckt ein realistisches Bild moderner Softwareentwicklung: Entscheidungen werden gemeinsam getroffen, Austausch ist tägliche Praxis, und die Verbindung von Produkt- und Infrastrukturperspektive ist nicht optional, sondern Teil des Arbeitstages.

Was bleibt, ist der Eindruck eines Berufsalltags, in dem sich mehrere Ebenen überlagern: Umgebungen bereitstellen, Deployments durchführen, Infrastruktur managen, Produkt weiterentwickeln, im Team Entscheidungen diskutieren. Diese Breite ist kein Ausnahmezustand – sie ist Normalität.

Lernen von Null: Problem suchen, losgoogeln, dranbleiben

Auf die Frage, wie er heute von vorne anfangen würde, antwortet Sattler ohne Schnörkel. Er würde ein eigenes Problem identifizieren, dann recherchieren, welche Ressourcen verfügbar sind – und sie nutzen.

Sein Blick auf Lernen ist radikal pragmatisch: Nicht warten, bis ein Kurs beginnt, nicht nach Erlaubnis fragen. Stattdessen: Ein reales Thema wählen, die bestehenden Dokumentationen und Videos nutzen, Schritt für Schritt anwenden. Der entscheidende Effekt liegt für ihn im direkten Belohnungsgefühl.

Dieses „sofortige Belohnen“ verbindet sich mit dem, was ihn ursprünglich am Programmieren festgehalten hat: das schnelle Resultat. Lernen wird dadurch kein abstrakter Akt, sondern ein Prozess mit greifbaren Fortschritten.

Er beschreibt Lernen als Bewegung: erst das Problem, dann die Recherche, dann die Anwendung in einem Projekt – und schließlich das Eintauchen in die Tiefe. Nicht umgekehrt. Aus unserer Perspektive ist das eine klare Empfehlung für alle, die ihren Einstieg suchen oder ihre Richtung neu finden wollen.

Unsere wichtigsten Beobachtungen aus „Michael Sattler, Software Engineer bei nexyo“

In der Kürze seiner Aussagen liegt eine Präzision, die wir als Redaktion schätzen. Daraus leiten wir fünf Kerngedanken ab, ohne mehr zu behaupten, als gesagt wurde:

1. Einstieg durch Gelegenheit: Ein „glücklicher Zufall“ kann reichen, wenn man ihm Raum gibt.
2. Motivation durch Resultate: Schnelle, sichtbare Ergebnisse sind ein starker Motor – von der ersten C-Erfahrung bis zu heutigen Projekten.
3. Breite durch Wachstum: Frontend → Backend (Golang) → Infrastrukturkoordination: Eine organische Erweiterung der Verantwortung.
4. Team und Produkt: Diskussionen mit Kolleginnen und Kollegen gehören zum Alltag; Produkt und Infrastruktur sind miteinander verschränkt.
5. Lernen ist problemgetrieben: Problem wählen, recherchieren, Projekt bauen, die Tiefe nachschieben – so beschreibt Sattler seinen bevorzugten Weg.

Von der Begeisterung zur Routine: Wie Breite entsteht

Was uns am Verlauf auffällt, ist die Kombination aus anfänglicher Begeisterung und späterer Routine. Sattler schildert kein dramatisches Umschwenken, sondern ein Aufeinanderaufbauen: C als fordernder Start; Frontend als erste berufliche Spielfläche; Backend – insbesondere Golang – als Ausdehnung; Infrastrukturkoordination als Konsequenz aus Verantwortung.

Diese Entwicklung illustriert eine Realität, die viele Teams kennen: Wer mit einem Auge am Produkt und mit dem anderen an der Umgebung arbeitet, wird automatisch in die Rolle des Koordinators hineinwachsen. In Sattlers Fall manifestiert sich das in der Arbeit „viel mit Kubernetes“, mit Helm „für Deployment“ und mit Terraform, „das Ganze irgendwie zu managen“. Die Aussage wirkt bewusst unglamourös – und gerade dadurch authentisch.

Wie Sattlers Lernhaltung in den Arbeitsalltag übersetzt

Die gleiche Logik, mit der er Lernen beschreibt, findet sich in der Arbeitsstruktur wieder: Probleme identifizieren, recherchieren, anwenden, vertiefen. Das entspricht dem beschriebenen Tagesablauf, in dem technische Umsetzung (Deployments, Management) und Diskurs (Produkt, Team) Hand in Hand gehen.

Wer diesen Ansatz auf das eigene Arbeiten überträgt, wird zwei Effekte bemerken: Erstens fällt der Einstieg leichter, weil Lernen an ein reales Problem gebunden ist. Zweitens entsteht Tiefe nicht aus Zwang, sondern aus dem Wunsch, das aktuelle Problem besser zu lösen. Genau darin liegt die Stabilität dieses Ansatzes.

Konkrete Schritte: So setzt du Sattlers Ansatz für dich um

Die Aussagen im Talk ergeben eine einfache, klare Abfolge, die du direkt auf deinen Weg legen kannst:

• Starte mit einem echten Problem, das dich interessiert.
• „Drauf losgoogeln“: Nutze die frei verfügbaren Ressourcen – Dokumentationen und Videos sind „wahnsinnig gut“.
• Wähle ein Projekt, das dieses Problem adressiert. Mach es dir „zu Herzen“ – halte daran fest, bis es funktioniert.
• Nimm den „belohnenden Nebeneffekt“ bewusst wahr: Jeder kleine Fortschritt motiviert.
• Wenn das Fundament steht, „stürze dich in die Tiefen“ der relevanten Technologien.

Diese Reihenfolge vermeidet Überforderung. Sie knüpft an das an, was Sattler über seinen eigenen Einstieg sagt: Erst erleben, dann vertiefen.

Frontend, Backend, Infrastruktur: Was die Abfolge über Verantwortung sagt

Sattler beginnt im Frontend – dort, wo Nutzerinnen und Nutzer unmittelbar sehen, was entwickelt wird. Die Bewegung ins Backend – „vor allem in Golang“ – erweitert die Perspektive um die Funktionslogik. Die Koordination der „gesamten Infrastruktur“ verschiebt den Fokus schließlich auf die Frage, wie alles zuverlässig zusammenläuft.

Aus dieser Abfolge lesen wir ein Bild von Verantwortung: Sie wächst, wenn man sie annimmt. Die genannte Toolkette – „Kubernetes“, „Helm“, „Terraform“ – markiert genau diese Verantwortungszone: Deployment, Paketierung, Management. Sie ist nicht losgelöst vom „Produkt vorantreiben“, im Gegenteil. Die Verbindung beider Seiten – Technik und Produkt – gewinnt Sattler zufolge durch „viele Diskussionen mit den Kollegen und Kolleginnen“ Form.

Produkt vorantreiben heißt reden können

Dass „viele Diskussionen“ Teil des klassischen Arbeitstages sind, ist mehr als ein Randdetail. Für uns war es eine Erinnerung daran, dass moderne Softwareentwicklung einen Raum braucht, in dem Perspektiven gewechselt werden können: Engineering, Produkt, Betrieb. Sattlers Schilderung ist knapp – und gerade deshalb präzise: Der Dialog gehört zum Kerngeschäft.

Wer die eigene Laufbahn ähnlich breit anlegt, wird sich wiederfinden: Technik und Kommunikation sind keine Gegensätze. Sie stabilisieren sich gegenseitig.

Was Anfängerinnen und Anfänger mitnehmen können

Der vielleicht zugänglichste Teil von „Michael Sattler, Software Engineer bei nexyo“ ist seine Offerte an jene, die neu beginnen möchten – oder die nach einer Pause wieder einsteigen wollen. Die Anleitung ist einfach, und genau dadurch wirksam:

• Suche dir ein Problem.
• Nutze das Internet (Dokumentationen, Videos).
• Baue ein Projekt daraus und halte daran fest.
• Verspüre den Lerneffekt – er belohnt dich.
• Gehe danach tiefer.

Wir schätzen an dieser Abfolge, dass sie keine spezielle Vorbildung verlangt. Sie setzt Neugier voraus und die Bereitschaft, dranzubleiben. Sattler betont, wie „niederschwellig“ vieles heute zugänglich ist; es braucht keinen perfekten Plan, um anzufangen.

Die Bedeutung des ersten Kontakts: C als „maschinennah“ und fordernd

Sattlers erster Kontaktpunkt ist fordernd. Trotzdem – oder gerade deshalb – bleibt er hängen. Für unser Ohr beschreibt er damit einen produktiven Widerspruch: Etwas ist schwierig, aber die Nähe zu sichtbaren Resultaten motiviert. Das ist die Schleife, die Lernen trägt: Herausforderung und Rückmeldung.

Wer diesen Mechanismus einmal erlebt, sucht ihn wieder. Aus dieser Perspektive wird verständlich, warum Sattler nach dem Studium die programmierorientierten Fächer höher gewichtet und gezielt in Richtung Software Engineering geht.

Ein Arbeitstag, viele Ebenen

Ein Arbeitstag bei nexyo GmbH, so wie Sattler ihn skizziert, umspannt mehrere Ebenen: von Deployments über Infrastrukturmanagement bis zu Produktfragen. Diese Breite ist nicht dekorativ, sie ist funktional – und sie erklärt, warum seine Lernhaltung (Problem, Recherche, Projekt, Tiefe) so gut dazu passt.

In dieser Multi-Ebenen-Arbeit spüren wir auch, wie aus anfänglicher Begeisterung eine Professionalität wird, die ihren Reiz aus Konsequenz bezieht: Was funktioniert, wird wiederholt. Was sich bewährt, wird vertieft.

Für Fortgeschrittene: Die Balance aus Werkzeug und Wirkung

Sattler nennt klare Werkzeuge: Kubernetes, Helm, Terraform. Entscheidend ist, wie er sie einbettet: nicht als Selbstzweck, sondern als Mittel, „das Ganze“ zu managen, Deployments zu tragen und das Produkt voranzubringen. In diesem Zusammenhang gewinnt auch sein Hinweis auf Diskussionen Gewicht: Werkzeuge entfalten Wirkung im Kontext eines Teams.

Wer sich in ähnliche Rollen bewegt, kennt die Herausforderung: Nicht jedes Problem ist ein Tool-Problem. Manchmal ist es eine Abstimmung, manchmal eine Priorität – und oft eine Mischung aus beidem. Sattlers Darstellung erinnert daran, dass der Blick auf das Ganze gelernt werden kann, indem man Schritt für Schritt in mehr Verantwortung hineinwächst.

Die Kraft der einfachen Schritte

Wir bleiben an dieser Wortwahl hängen, weil sie die Essenz einer nachhaltigen Lernpraxis trifft: nicht komplizieren, sondern beginnen. Aus dem Start folgt die erste Erfahrung; aus der Erfahrung der Wunsch, mehr zu verstehen. Wer immer wieder so lernt, baut Breite und Tiefe gleichzeitig auf – und landet womöglich, wie Sattler, dort, wo Produkt, Infrastruktur und Teamgespräch zusammenkommen.

Fazit: Ein modernes Berufsbild in klaren Sätzen

„Michael Sattler, Software Engineer bei nexyo“ zeichnet das Bild eines Engineers, der aus einem „glücklichen Zufall“ einen nachhaltigen Weg macht:

• erster Kontakt mit C im Elektrotechnikstudium,
• Faszination durch Problemorientierung und schnelle Resultate,
• Entscheidung nach dem Studium für Software Engineering,
• Schritte über Frontend und Backend (Golang) hin zur Infrastrukturkoordination,
• tägliche Arbeit mit Kubernetes, Helm und Terraform,
• Fokus auf Produkt und Zusammenarbeit über „viele Diskussionen“,
• eine Lernhaltung, die mit einem persönlichen Problem beginnt, sich der offenen Dokumentation und Videos bedient, ein Projekt baut und dann in die Tiefe geht.

In Summe ergibt das ein Rollenbild, das wir als DevJobs.at-Redaktion häufiger sehen und sehr schätzen: pragmatisch, kollaborativ, wachstumsorientiert. Und es ist wohltuend zugänglich. Wer anfangen will, findet in Sattlers Worten einen klaren Startpunkt. Wer bereits mittendrin ist, erkennt darin einen Weg, Breite und Verantwortung zu verbinden – ohne den Blick aufs Produkt zu verlieren.

• 

  

  Fast Feedback Development meets Kubernetes with Tilt

  Michael Sattler von nexyo erzählt in seinem devjobs.at TechTalk darüber, wie das Team mit dem Einsatz von Tilt ihre Development Umgebung gestreamlined hat.

  Jetzt ansehen
• 

  

  Go and DDD := Building the Right Thing

  Andreas Krimbacher von nexyo spricht in seinem devjobs.at TechTalk über die Entscheidungen, welche hinter der im Unternehmen angewandten Technologie Go und der Wahl der Architektur stehen.

  Jetzt ansehen

• 

  

  Andreas Krimbacher, CTO von nexyo

  Der CTO von nexyo Andreas Krimbacher gibt im Interview Einblicke über das Team, wie der Recruiting Prozess abläuft und wie das Unternehmen die technologischen Herausforderungen meistert.

  Jetzt ansehen