From Industrial Automation to Tailored Software: Alexander Knapp (Objectbay) on concepts, communication, and building a developer career that lasts

Introduction: A DevJobs.at devstory recap

Title: Alexander Knapp, Full Stack Software Engineer bei Objectbay

Speaker: Alexander Knapp

Company: Objectbay

What does it look like to move from electrical engineering into geoinformation and then return to hands-on software development—finding a place where problem solving sits at the center? In this devstory, DevJobs.at follows the path of Alexander Knapp. His journey runs from a practically minded family background through a technical school in St. Pölten, early years in industrial automation, a longer stop in public service working with geodata, and finally into custom software development at Objectbay.

Threading through this story is a simple idea: understand the problem, then build the right solution. Alexander’s central message to developers is equally clear: success is not about worshipping programming languages; it’s about mastering concepts, collaborating, and grasping what people truly need. In a time when AI tools keep changing how we work, that mindset becomes a defining advantage.

Technical roots: A family of makers and an early view into automation

Alexander describes growing up in a “very technical, hands-on family.” His father worked in automation—an environment where systems like ski lifts or paper machines can be controlled “with a mouse click.” That visual sticks: technology as a quiet force moving complex machinery. When you see this up close, you learn how theory blends with practice.

From there, his educational choice followed naturally: a technical high school (HTL) in St. Pölten. He started in electrical engineering and later shifted to information technology, specifically industrial IT. With hindsight, he calls this path “actually great,” and not just because it was practical. He also spent time learning Java and C during those years—an early sign that software would play a central role in his thinking.

Early career at Siemens: Automation and the discipline of real systems

After graduating, Alexander joined Siemens as an automation engineer. The focus there was “very electrical,” but his earlier exposure to Java and C proved valuable in understanding systems, interfaces, and control logic—even if the daily work tilted toward hardware and control systems.

Industrial automation has a distinct rhythm: reliability, robust processes, and interdisciplinary thinking. Starting out in this world helps explain why Alexander later emphasizes the primacy of concepts over specific tools. Whether you’re dealing with a ski lift or a paper machine, the job requires recognizing structure, mapping workflows, and prioritizing stability.

A pivot into geoinformation: Public service and the world of data

After Siemens, Alexander spent “many years in public service,” working with geodata processing and geoinformation technology. That shift moves from control systems to data-centric work. Handling geodata teaches respect for data quality, information flows, and careful curation—and it pulls you closer to software, even when the role is not pure coding.

It’s here that Alexander realigns his own compass: “I felt it should go back toward information technology. I’d like to really develop software, not just process data.” That desire—to build, not merely manage—pointed him toward his next move.

Landing in custom software: Objectbay

The decisive step was moving into software development and joining Objectbay, a setting that fits his profile. Around that time, he also decided to pursue an additional degree alongside his job, which he has “since completed” at FH Campus Wien. Education, industry, public service, part-time studies, and the return to software: this sequence speaks to persistence and an appetite for learning.

Today, he puts it simply: “I’m happy at Objectbay and work on cool projects.” Behind that sentence sits a deliberate turn: back to software, into teams that build solutions in close conversation with customers.

What defines Objectbay: Tailored solutions without a prescribed stack

Alexander describes Objectbay as a company for individual software development. Clients come with a problem “they want to solve,” and the team develops the bespoke software to address it. Crucially, there are “no pre-made or prescribed technologies.” Teams have the freedom to choose what best fits the case.

• Agile collaboration within the team
• Flat organizational structure
• Intensive communication with the customer
• A customer-side Product Owner who articulates what’s needed for the next release

This is pragmatic by design. Custom software development requires a way of working that keeps decisions close to the problem and treats technological variety as a strength.

Technology breadth: Java, Python/Django, and a wide front-end landscape

Alexander paints a clear picture: “We have a huge variety technologically.” He mentions Java, Python, and Django projects, and highlights that on the front end, they work with “pretty much every framework you can imagine.” There is also the option to specialize, especially in infrastructure, Kubernetes, and DevOps.

The key line is this: “It’s not just coding. The point is to provide something holistic for the customer.” That reframes the role from pure implementation to end-to-end responsibility—requirements, delivery, and operations aligned.

Freedom tied to responsibility: Agile teams as problem solvers

In Alexander’s account, teams are set up to make decisions. Agility is not a buzzword here; it’s proximity to the need. The customer-side Product Owner specifies “what’s necessary for the next release,” and the team delivers. Flat structures support short feedback loops. Decisions happen where they’re best understood: in the team, in conversation with the customer, close to the product.

This way of working brings two obvious benefits:

• It strengthens problem-solving skills. Directly clarifying requirements helps teams address root causes and build durable solutions.
• It accelerates learning. Technology diversity and real-world constraints force prioritization, pragmatism, and crisp communication.

Concepts over syntax: Learning in the age of AI

One of Alexander’s strongest statements is this: “Especially now in the age of AI, it’s much more important to understand the concepts. Don’t focus on a single programming language—understand the technical concepts and the ideas developed over the last 50–70 years.”

That resets the priorities. Languages, frameworks, and toolchains evolve quickly; what endures is the underlying thinking—architecture, abstractions, mental models. Developers who internalize concepts can adopt new tools faster and make more grounded decisions.

For developers, this suggests a few practical behaviors:

• Understand the problem before selecting the solution.
• Evaluate tools based on fitness for purpose, not familiarity.
• Build transfer skills: what you grasp in Java often applies in Python if you understand the underlying concept.

The human factor: Communication over the loner myth

Alexander challenges a persistent stereotype: “The idea of the coder sitting late at night with a cola and a pizza—you have to forget that.” Why? Because real software development is collaboration. To solve problems, you have to listen, ask, and understand the other side’s context.

“You really have to communicate with people. You have to understand what problems they actually have that you should solve.” That’s likely the most critical capability next to technical skill. Communication makes timelines more realistic, requirements clearer, and outcomes more relevant.

His advice is disarmingly simple:

• Show genuine interest
• Lean into teamwork
• Ask for help when you’re stuck

This attitude counters perfectionist isolation. It builds trust, strengthens teams, and produces better products.

Specialize—deliberately: Infrastructure, Kubernetes, DevOps

Alongside breadth, Alexander notes the option to specialize—in infrastructure, Kubernetes, and DevOps. These domains are integral to end-to-end ownership: deployment, scaling, resilience, and workflow automation. Specialization here expands the developer’s lens from code to operations.

The implicit takeaway: specialization and generalism aren’t mutually exclusive. You can go deep in one area while maintaining conceptual breadth—especially valuable in project-driven environments where diversity is the norm.

Career paths beyond coding: Teamlead, management, Product Owner

Alexander offers an open view on career evolution: “If later on you feel pure programming doesn’t interest you as much, there are plenty of paths you can take. For me, for example, Teamlead—or sometime management—maybe Product Owner in the agile world.”

The core is not the title but the compass: “Stay on the ball and keep an eye on your interests.” If you reflect on what motivates you, you can adjust course without losing momentum. His own moves—from automation to geodata to bespoke software development—illustrate this flexibility.

Practical takeaways from Alexander’s journey

From our DevJobs.at vantage point, several actionable insights stand out:

1) Technical upbringing helps—but does not define you.

A hands-on family and early exposure to real systems foster curiosity and a respect for how things work. It’s a booster, not a constraint.

2) Education is a springboard, not a silo.

Starting in electrical engineering and switching to industrial IT, while also learning Java and C, laid the groundwork for a broader software lens.

3) Switching domains sharpens judgment.

Moving from control systems to geodata trains you to look at problems from different angles—critical for custom software.

4) Agility is communication.

Flat structures, a customer-side Product Owner, and team decisions only work with strong communication. Understanding, negotiating, and explaining become daily skills.

5) Concepts outlast syntax.

In the “age of AI,” conceptual thinking is the lever for using new tools wisely. Those who learn principles navigate change more confidently.

6) Specialization is a choice, not a mandate.

Infrastructure, Kubernetes, DevOps—specialize where it extends your impact, and anchor it in solid conceptual understanding.

7) Careers are sequences of choices—not straight lines.

The move to Objectbay, the part-time studies at FH Campus Wien, and the focus on software show how course corrections can add depth to your profile.

Quotes that linger

How the pieces fit together

Looking back, Alexander’s stages form a coherent learning curve:

• Technical family and a father in automation: Technology as a problem solver.
• HTL in St. Pölten, switching from electrical engineering to information technology: readiness to cross boundaries.
• Siemens, automation engineering: reliability, interdisciplinary work, and real systems.
• Public service, geodata processing: data quality, information curation, domain shift.
• Return to software development, Objectbay: agile teams, customer proximity, technology variety.
• Studies at FH Campus Wien: consolidating knowledge alongside work.

The throughline is cumulative learning. Each stage feeds the next, even when the subject matter changes.

Concrete action steps for developers

• Build a conceptual foundation. With each new tool, ask: which principle is at play?
• Practice translating requirements. What is the customer actually saying? What’s the core problem?
• Balance breadth with depth. Explore multiple technologies, then choose deliberate areas of specialization (e.g., infrastructure, Kubernetes, DevOps).
• Make teamwork a core skill. Invite feedback, ask for help, learn from others, and share knowledge.
• Adjust course when needed. If processing data doesn’t fulfill you, look for roles where you actively build software.
• Recognize that career paths are diverse. Consider Teamlead, management, or Product Owner if your interests shift.

Why this story matters now

Technology cycles are accelerating, which increases the value of principles and communication. Alexander’s path confirms that sustainable capability rests on three pillars:

• Conceptual understanding (beyond languages and frameworks)
• Collaboration (customer proximity, teamwork, clear communication)
• Ownership (end-to-end thinking, specialization where it makes sense)

In the world of custom software development, as Alexander describes at Objectbay, these pillars are exercised every day. Variety is the norm, learning is part of the job, and direct conversation with customers is not a side note—it’s the core.

Closing: The craft of solving

Alexander Knapp’s devstory can be distilled into a single line: those who understand problems holistically can solve them effectively. His journey—from automation to geoinformation to bespoke software—provides the context; his advice offers the tools.

For developers, the takeaways are simple and durable: trust concepts, practice communication, stay curious, and steer your path intentionally—just as Alexander Knapp has done at Objectbay.

• 

  

  Serverless Applications with AWS Lambda

  Thomas Jäger von Objectbay geht in seinem devjobs.at TechTalk zu dem Thema Serverless Applications in die Tiefe und überprüft, ob die Marketing Slides von Amazon auch halten was sie versprechen.

  Watch now
• 

  

  Microservices for Front Ends

  Michael Eder von Objectbay spricht in seinem devjobs.at TechTalk über einen Ansatz, wie man die gängige Architektur der Microservices auch im Front End anwenden könnte.

  Watch now
• 

  

  Die Wahl der richtigen Software Architektur

  Alexander Knapp von Objectbay beschäftigt sich in seinem devjobs.at TechTalk mit der Herangehensweise, wie man aus einer Vielzahl an verschiedenen Software Architekturen die passende auswählt.

  Watch now
• 

  

  Mutation Testing

  Alexander Knapp von Objectbay widmet sich in seinem devjobs.at TechTalk dem Thema Mutation Testing – was es ist und wie jedes Software Projekt davon profitieren kann.

  Watch now