From 8‑inch floppies to fleet orchestration: Klemens Pleiner (DS Automotion GmbH) on base software, interfaces, and code that moves things

A DevJobs.at recap of “Klemens Pleiner, Basis Software Developer bei DS Automotion”

Some developer stories read like a field guide to curiosity, persistence, and purpose in engineering. “Klemens Pleiner, Basis Software Developer bei DS Automotion” is one of those stories. We at DevJobs.at listened closely: how a primary‑school field trip to a municipal office in the 1980s sparked a lifelong fascination. How first lines in Amiga Basic turned into a deep dive through Pascal, C, and Assembler. How stepping into plant and supervisory control software followed naturally. And why there is a special kind of joy when code opens real doors, switches real lights, and—above all—safely guides vehicles through large facilities.

In this editorial, we trace Pleiner’s milestones, compress his remarks into actionable takeaways, and outline what matters in a specialized domain like supervisory control for automated fleets: modular components, robust interfaces, continuous modernization—and a healthy dose of playful modeling.

The first “wonder machine”: fascination with generating new knowledge from data

A vivid scene sets the tone: a “huge metal box” with a tiny monochrome monitor and a wide slot for 8‑inch floppies. At a nearby town hall in the 1980s, a class of schoolchildren is introduced to a computer. It can store and retrieve information—and “calculate new” information from what’s already stored.

That idea electrifies Pleiner. Generating new data from data—set against the paper reality of the day—feels radically new. Each subsequent encounter with a computer repeats the same itch: how does it work inside?

That technical curiosity is the red thread in his story. It explains why, at twelve, he starts out with Amiga 500 and Amiga Basic—and why the bundled examples only hold him briefly. Understanding pulls him deeper.

From Amiga to Assembler: the early learning arc

At age twelve, the journey begins—not with gaming, but with learning control flow and logic. Amiga Basic, simple examples, and the first feeling of making a machine follow your thought. The learning curve quickly steepens. Pleiner wants to “go deeper,” moving to PC with Pascal, C, and Assembler.

A formative highlight: together with a schoolmate, he writes a mini operating system in Assembler. Not because he must, but because he can—and because peeling back the layers is how you understand a computer.

The next step is consequential: studying computer science to get the “theoretical background” that explains “why you wisely do certain things one way and not another.” Theory supplies vocabulary and models—practice is never far away.

Study, work, self‑employment: closing the loop with reality

Pleiner starts working while still in university, completes his studies, becomes self‑employed, and later “gets hired” by a former client. None of these are detours; they’re steps in sharpening his role—from curious tinkerer to system builder with responsibility.

Then, a pivotal exposure: as an external contractor, he gets to “breathe plant software air” at DS Automotion GmbH. The domain hooks him.

That marks the chapter that defines his current work: base development in supervisory control—software that acts as a component kit for many different installations to realize customer requirements.

Supervisory control: turning lone vehicles into fleets

Pleiner’s framing is crisp: a single automated vehicle, “if you just put it down,” is a lone fighter. Supervisory control turns lone vehicles into a coordinated “fleet” moving through large sites to achieve the operator’s goals—say “the highest possible throughput” or “the shortest possible transport times” for last‑minute jobs.

The base team builds components for a component‑kit approach. The rule is simple: recurring requirements become dedicated building blocks that can be slotted into new installations and configured to fit. Customer needs are then delivered by composing and configuring, not by re‑inventing.

Component kits as an architectural stance

This isn’t merely a library; it’s a way of thinking:

• Identify recurring patterns: if a requirement occurs “more than once or twice,” it deserves its own component.
• Separate logic from configuration: keep the building block generic; specialize per facility via configuration.
• Make plug‑and‑play in reality: “plugging in” means integrations and interfaces meet defined expectations.

The payoff is a system that stays reusable, maintainable, and extendable—critical in a world where facilities run for decades and continue to grow.

Interfaces everywhere: orders, sensors, doors, traffic lights

There is no supervisory control without interfaces. Pleiner lists what’s routinely needed:

• Order interfaces: ingest transport tasks and report progress to third‑party systems.
• Sensor interfaces: e.g., an occupancy sensor at a handover station.
• Interfaces to external hardware: for example, door control so “fire sections are only open when a vehicle needs to pass” and close again afterward.
• Traffic lights: guiding pedestrians on whether it’s safe to cross a lane.

These examples anchor abstraction in physical reality. It’s not only messaging; it’s reliable behavior in environments where safety, timing, and state are tied to hard constraints.

Building supervisory control means bridging software state and physical state—aware that a bad timing bug isn’t just a log line but a disruption of real operations.

Modernization: yesterday’s state‑of‑the‑art gathers dust

Pleiner states it plainly: “What was state of the art 20 years ago is now so dusty that nobody wants it.” The consequence is continuous porting of existing functionality to new technologies.

He calls out specific channels for order handling: “database interfaces, REST interfaces, web technologies”—waves of adoption across decades. The point isn’t hype; it’s long‑term maintainability. When installations have run since 2004, software must grow with them without losing purpose.

Modernization here means:

• Understand before you replace.
• Consolidate interfaces without creating functional gaps.
• Choose technological shoulders broad enough to carry for years.

Teaming without rigid walls: stepping in where it matters

At DS Automotion GmbH, team boundaries aren’t “totally rigid.” People are regularly “loaned” to sister teams. Pleiner himself is currently working on a large maintenance project: an existing installation “running since 2004” was expanded with “very many vehicles” and “new buildings.” The task is to bring new transport flows into the system so that “in the new parts it does exactly what the customer wants.”

That’s real product and project accountability: building components and integrating them into live, evolving plants—precisely where it matters. For engineers, it’s a chance to learn beyond one’s niche, deepen system knowledge, and get feedback from operational reality.

“The coolest thing is: we write software that moves things in the real world.”

You can feel the appeal of this domain. Pleiner puts it bluntly:

Many of us know the intellectual kick of a server app that boots and a UI that renders. Here something truly moves—weight, direction, destination. That visibility fuels motivation, especially when projects are long and complexity grows.

Culture: collegial, eye‑level, with room to roam

Pleiner’s description is understated and thus credible: a “collegial” tone, not “rigidly” confined to one team, the chance to “help out elsewhere,” and colleagues you can “communicate with at eye level.” No buzzwords—just the kind of environment complex systems demand: freedom to pitch in where the whole system benefits.

How to become a programmer? Curiosity, stamina—and playful modeling

Pleiner’s guidance starts with a stance: ask questions. “How does it work? How could I add new functionality?” Not only on PCs but also on “embedded devices—hardware built in somewhere, not visible from the outside,” and even on “mainframe systems.” Many things are programmable—openness is the first step.

Then comes a less glamorous truth: perseverance. Small tasks are “done quickly,” bigger ones need “a longer breath,” and very large projects running “one, two, three years” require deliberate motivation: keep steering toward the goal—and keep going.

Formalize, don’t fantasize

A striking insight concerns day‑to‑day problem solving in the team. If you want to start at DS Automotion GmbH, it’s “good to bring programming knowledge in a C‑like language.” But “many problem statements in our domain are very specialized.” You won’t arrive with a ready‑made education for them.

The essence lies in thinking:

• Think problems through—“playfully,” too. Pleiner notes they sometimes use “toys on the desk.”
• Formalize: “How can you formalize a problem?”
• Write the formalized solution down “in source code”—and that’s the component done.

It’s a blend of curious exploration and disciplined formalization.

Hands‑on takeaways for engineers—grounded in supervisory control

Directly from the session, and still broadly applicable:

• Curiosity as engine: the impulse to “calculate new data from data” can power an entire career.
• Depth pays off: from Amiga Basic to C and Assembler—knowing the lower layers makes your higher‑level work sturdier.
• Theory enables practice: learning “why you wisely do things one way” equips you with tools, not dogma.
• Treat the component kit seriously: encapsulate recurring needs, prefer configuration over copy‑paste, define crisp interfaces. That’s how systems survive decades.
• Interfaces are responsibility: orders, sensors, doors, traffic lights—integrations have real‑world consequences. Robustness outranks elegance.
• Modernize without nostalgia: what was “state of the art” will age. Porting is core work, not an afterthought.
• Keep teams flexible: help out where it matters; learn how components behave in the field.
• Manage motivation: large projects need stamina and a clear line of sight to the goal.
• C‑like languages as good footing: useful for the domain’s entry point—yet the decisive skill is problem formalization.
• Allow play: build models “with toys on the desk”—hands and eyes often understand faster than a mind alone.

A day in the base team—made tangible

Pleiners story anchors an appealing work picture: building components you can slot into plants; watching vehicles move because of your logic. In between: designing interfaces, wiring up sensors, reliably switching doors in fire sections, orchestrating traffic lights, and reporting task progress to foreign systems. And as technologies evolve, carefully porting functionality—to database interfaces, REST interfaces, and web technologies.

His current maintenance project underscores how long these systems live: a 2004 installation keeps growing—more vehicles, new buildings, new flows. Software here isn’t disposable; it’s infrastructure. It must stay understandable, configurable, and portable.

Why this story sticks

Not every developer biography comes with such a clean arc. With Klemens Pleiner we see:

• the first encounter with a “wonder device,”
• early depth (Assembler, a mini OS),
• the move into theory (computer science) in service of practice,
• years of self‑employment and the pull of good projects,
• and arrival in a domain where software moves real things.

We also hear the undercurrents: enjoyment of collegial collaboration, willingness to swap tasks when the system needs it, and the readiness not merely to code but to model problems first.

What we learned from “Klemens Pleiner, Basis Software Developer bei DS Automotion”

In plain terms:

• Software engineering is a craft with a stance: curious, patient, and formal.
• Supervisory control demands components that do more than compute: they bridge digital state and physical responsibility.
• Aging tech and modernization are normal—and mastering them is a quality marker.
• Team culture is a productivity lever: eye‑level collaboration, mobility across teams, and freedom to help where needed.

Few sentences capture so clearly why many of us fell in love with programming.

For talents eyeing this domain

For those considering environments like DS Automotion GmbH, the session surfaces clear signals:

• Solid grounding in a C‑like language helps you get started.
• Expect many “very specialized” problem statements—learning beats prior domain exposure.
• Train both playful and formal thinking: build models, test hypotheses, express them precisely in code.
• Embrace modernization as a constant—and as a chance to keep systems viable across generations.
• Look forward to the rare privilege that your code ultimately does something physical—doors, traffic lights, vehicles.

Closing: purpose through impact

We leave the session with the sense that this career has an inner compass: from awe at the first wonder machine to joy in visible effect. Klemens Pleiner, now a base software developer in the supervisory control group at DS Automotion GmbH, shows how personal curiosity, solid foundations, and a systematic, modular mindset come together. And he reminds us of something that’s easy to forget in day‑to‑day work: the most beautiful software is the kind that moves something in the world.

• 

  

  Kevin Greßlehner, IT Techniker bei DS Automotion

  Kevin Greßlehner von DS Automotion spricht im Interview über seinen ursprünglichen Zugang zur IT Technik und gibt einen Überblick über seinen Job im Unternehmen sowie Tipps für Anfänger.

  Watch now
• 

  

  Gerald Hahn, Requirements Engineer bei DS Automotion

  Gerald Hahn von DS Automotion berichtet im Interview über das Requirements Engineering: wie er in die Branche eingestiegen ist und was er Anfängern raten würde.

  Watch now
• 

  

  Lukas Fiel, Test Automation Engineer bei DS Automotion

  Lukas Fiel von DS Automotion erzählt im Interview von seinem Werdegang von den eigenen Projekten bis hin zum Test Automation Engineering und welche Tipps er für Neueinsteiger bereithält.

  Watch now