From Serendipity to Systems: Michael Sattler’s path from C to Kubernetes at nexyo GmbH

Introduction: A DevJobs.at look at curiosity, breadth, and pragmatic learning

Listening to “Michael Sattler, Software Engineer bei nexyo,” one theme stood out to us: the disarming simplicity of his story. No theatrics, no inflated claims—just a clear account of how a lucky moment, persistent curiosity, and pragmatic learning habits led to a role that spans frontend, backend, and infrastructure.

What resonated most was the straightforward way Michael Sattler describes his journey. He comes from electrical engineering, learned C at 19 for the first time, got “hooked” by the way programming tackles problems and delivers results quickly, and realized after graduation that programming-focused subjects appealed to him more than electrical engineering itself. From there, he followed that impulse: started in frontend, grew into backend—especially Golang—and eventually shifted to the bigger picture: coordinating infrastructure, working with Kubernetes, Helm, and Terraform, helping move the product forward, and engaging in many discussions with colleagues.

In this recap, we trace the points Sattler made and capture the insights we, as the DevJobs.at editorial team, took away: an example of serendipitous entry, a call for problem-driven learning, and a vivid picture of how broad and collaborative modern software work can be.

The lucky accident that opened the door

Sattler underscores something that often plays a role in tech careers: chance encounters matter. In his case, it wasn’t early exposure in childhood; it was a step during his electrical engineering studies that changed course.

He notes that he first encountered programming at 19. It was C—“very close to the machine, not quite so easy to get into.” That detail matters: C makes demands, and that first hurdle amplifies the next effect. He says he was “totally hooked.” What grabbed him was the problem-solving approach and the immediate results. It fit the way he thinks—and that momentum carried into his post-graduation decision to look for a software engineering role.

Why programming: The pull of instant feedback

For us, this line captures the core motivation behind his shift: programming compresses the cycle from idea to outcome. That density—think, do, see—can be immensely motivating, especially if you enjoy iterative problem-solving.

Sattler explicitly connects this to his personal way of thinking. Instead of starting from grand visions, he emphasizes tangible results. From there, the rest is straightforward: the programming-centric subjects spoke to him most, and after graduation he headed into software engineering.

From electrical engineering to software: A deliberate decision

We hear a pragmatic transition here. It isn’t a rejection of electrical engineering; it’s a decision to follow what resonated more strongly. The initial contact in C—“very close to the machine … not so easy to get into”—reinforces that this wasn’t about convenience. It was the joy of solving and the satisfaction of quick feedback.

Many readers will recognize this moment: you try something challenging, and the direct reward keeps you engaged. In Sattler’s case, that recognition guided him into his first full-time software role.

Frontend, backend, infrastructure: Expanding the aperture

Sattler outlines a progression grounded in steady expansion. Frontend first—the visible surface of the product. Then backend—“especially Golang”—as an extension of scope. The phrasing “grew into” suggests continuity rather than a sharp pivot.

Here the lens shifts again: from a single codebase to the systems that enable deployment and ongoing product evolution.

Kubernetes, Helm, Terraform: Infrastructure as everyday coordination

Sattler names the toolkit that anchors his day-to-day. Kubernetes, Helm, and Terraform converge on a theme: from application to managed environments—deployments, packaging, definition, and management of infrastructure. His tone remains matter-of-fact—that’s the point. The initial curiosity about solving problems has matured into a routine of coordinating infrastructure that supports the product.

What’s notable is how naturally the technical and the collaborative appear together in his account. Deployment and management imply responsibility that doesn’t stop at component boundaries. The gaze is on the system as a whole.

Product and people: Discussion as part of the craft

Sattler doesn’t just list tools and tasks; he points to the social reality of the work. Moving the product forward is not solitary. It happens in conversation—“lots of discussions.” In this succinct phrasing sits a realistic picture of software today: decisions are made together, and the connection between product and infrastructure is part of the daily rhythm.

The impression is of a day that spans multiple layers: provisioning environments, shipping deployments, managing infrastructure, pushing the product, and talking things through as a team. Breadth is the norm, not the exception.

Learning from scratch: Pick a problem, start searching, keep going

Asked how he would learn software engineering from zero today, Sattler answers without ornament. Identify a problem of your own, then research and use what’s already out there.

His learning lens is radically pragmatic: don’t wait for permission, don’t over-plan. Select a real problem, lean on existing documentation and videos, and apply them step by step. The key lies in the immediate sense of reward.

That “immediate reward” connects back to what initially hooked him: instant results. Learning becomes an applied process with concrete outcomes.

Sattler describes learning as motion: problem first, then research, then application in a project—followed by depth. Not the other way around. From our editorial vantage point, it’s a crisp recommendation for anyone seeking an entry point or a new direction.

What stood out to us in “Michael Sattler, Software Engineer bei nexyo”

In the brevity of his account lies a precision we appreciate. We derive five takeaways—nothing more than what was said, but connected into a coherent picture:

1. Serendipity matters: A “lucky coincidence” can be enough if you follow it with intent.
2. Results motivate: Quick, visible outcomes power engagement—from the first experiences in C to present-day work.
3. Growth expands scope: Frontend → backend (Golang) → coordinating infrastructure: an organic widening of responsibility.
4. Product and team go together: “Lots of discussions” are part of the day; infrastructure and product advance together.
5. Problem-driven learning: Choose a problem, search, build a project, then dive deeper—it’s a durable loop.

From spark to routine: How breadth develops

The throughline has two strands: an initial spark and a later routine. There’s no dramatic rupture; it’s a steady build. C as a demanding entry; frontend as the first professional surface; backend—especially Golang—as an expansion; coordinating “the entire infrastructure” as a consequence of accumulating responsibility.

This tracks with a reality many teams recognize: when you hold product in one hand and environment in the other, coordination becomes part of the job. In Sattler’s account, that means “a lot of Kubernetes,” Helm “for deployment,” and Terraform to “manage the whole thing.” The wording is intentionally unglamorous—and that’s exactly why it rings true.

How Sattler’s learning stance maps onto the workday

The same logic that frames his learning—problem, research, application, depth—shows up in his work: deployment and management on the one hand, product movement and conversation on the other.

For anyone applying this approach to their own practice, two effects often follow. First, starting becomes easier, because learning is anchored in something real. Second, depth comes as a response to need, not obligation. That’s where staying power comes from.

Bringing Sattler’s approach into your practice: A simple sequence

Sattler’s comments assemble into a clear, practical sequence you can adapt right away:

• Start with a real problem that matters to you.
• “Start googling”: make use of what’s publicly available—documentation and videos are “insanely good.”
• Turn it into a project you care about. Stick with it until it works.
• Register the “rewarding side effect”: each step fuels the next.
• When the basics are in, “dive into the depths” of the relevant technologies.

This order avoids overload. It mirrors Sattler’s original hook: experience first, then depth.

Frontend to backend to infrastructure: What that arc says about responsibility

Beginning in frontend puts you where users feel the product. Moving into backend—“especially Golang”—extends the scope to system behavior. Coordinating “the entire infrastructure” shifts the focus to how everything runs reliably.

From that arc, we read a picture of responsibility that grows as you accept more of it. The toolkit Sattler mentions—“Kubernetes,” “Helm,” “Terraform”—marks precisely that zone: deployment, packaging, management. And it is explicitly tied to “moving our product forward,” not separate from it. The connection is sustained through “lots of discussions with colleagues.”

Product momentum requires conversation

That “lots of discussions” line is more than a footnote. For us, it’s a reminder that modern software work depends on spaces where perspectives can meet: engineering, product, operations. Sattler’s brief description is precise: conversation is part of the craft.

For those pursuing similar breadth, this lands as a practical truth: technical work and communication aren’t opposites. They reinforce each other.

What newcomers can take away

Perhaps the most accessible piece of “Michael Sattler, Software Engineer bei nexyo” is his offer to anyone starting from scratch—or returning after a break. The playbook is deliberately simple, which is why it works:

• Pick a problem.
• Use the Internet (documentation, videos).
• Build a project around it and stick with it.
• Let the learning loop reward you.
• Go deeper afterwards.

We appreciate that this arc doesn’t demand specialized prerequisites. It asks for curiosity and persistence. Sattler emphasizes how “low-threshold” much of it is today; you don’t need a perfect plan to begin.

The significance of that first contact: C as demanding and formative

Sattler’s first contact is demanding. Yet it sticks—and partly because it’s demanding. There’s a productive tension here: the challenge meets the reward of quick results. That loop—challenge and feedback—keeps learning alive.

Once you feel that loop, you seek it again. From this perspective, his post-graduation decision makes intuitive sense: the programming-oriented work had the stronger pull.

A workday across layers

A workday at nexyo GmbH, as Sattler sketches it, spans multiple layers: deployments, infrastructure management, and product momentum. That breadth isn’t decorative—it’s functional. And it explains why his learning stance (problem, research, project, depth) aligns so naturally with the work.

In this multi-layer context, we also sense how early excitement becomes a professional throughline: what works gets repeated; what sustains progress gets deepened.

For practitioners: Balancing tools and outcomes

Sattler names specific tools—Kubernetes, Helm, Terraform—and frames them as means, not ends: instruments to “manage the whole thing,” support deployments, and move the product. In that context, his emphasis on conversation matters: tools create leverage in teams, not in isolation.

Anyone in similar roles knows the pattern: not every obstacle is a tooling issue. Sometimes it’s alignment, sometimes prioritization—often, both. Sattler’s account is a reminder that the whole-system view emerges by growing into responsibility step by step.

The power of simple steps

We linger on this wording because it captures a sustainable learning practice: don’t complicate the start, just begin. Experience creates the first scaffolding; the desire for depth follows. Repeat that loop and you build breadth and resilience—the kind that shows up, as it does for Sattler, where product, infrastructure, and team conversation intersect.

Conclusion: A modern engineering role in clear sentences

“Michael Sattler, Software Engineer bei nexyo” presents the portrait of an engineer who turned a “lucky coincidence” into a durable path:

• first contact with C during electrical engineering studies,
• fascination with problem-solving and fast feedback,
• a post-graduation decision to pursue software engineering,
• a progression from frontend to backend (Golang) to coordinating infrastructure,
• day-to-day work with Kubernetes, Helm, and Terraform,
• a focus on product and teamwork through “lots of discussions,”
• and a learning loop that begins with your own problem, relies on documentation and videos, builds a project, and only then dives deep.

Taken together, this is a role we at DevJobs.at encounter often—and value highly: pragmatic, collaborative, growth-oriented. It’s also refreshingly accessible. If you’re starting out, Sattler’s words provide a clear way in. If you’re already on your way, they outline how breadth and responsibility can grow together—without losing sight of the product.

• 

  

  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.

  Watch now
• 

  

  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.

  Watch now

• 

  

  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.

  Watch now