Vom Schaltschrank zur maßgeschneiderten Software: Die Entwicklerreise von Alexander Knapp (Objectbay) und was sie Devs über Konzepte, Kommunikation und Karriere lehrt

Einleitung: Ein Devstory-Porträt von DevJobs.at

Titel: Alexander Knapp, Full Stack Software Engineer bei Objectbay

Speaker: Alexander Knapp

Company: Objectbay

Was motiviert jemanden, von der Elektrotechnik über die Geoinformation in die individuelle Softwareentwicklung zu wechseln – und dabei genau das zu finden, was ihn erfüllt? In dieser Devstory begleitet DevJobs.at den Weg von Alexander Knapp. Sein Werdegang führt von einer handwerklich geprägten Familie über eine technische Ausbildung in St. Pölten, erste Berufsjahre in der Automatisierung und eine Etappe im öffentlichen Dienst bis hin zu seiner heutigen Rolle in der maßgeschneiderten Softwareentwicklung bei Objectbay.

Sein roter Faden: echte Probleme verstehen und lösen. Seine zentrale Botschaft an Entwicklerinnen und Entwickler: Es geht nicht nur um Programmiersprachen – es geht um Konzepte, Zusammenarbeit und die Fähigkeit, die Bedürfnisse von Menschen präzise zu erfassen. In einer Zeit, in der KI-Tools den Alltag verändern, wird genau das zum entscheidenden Vorteil.

Wurzeln in der Technik: Familie, Praxisnähe und ein früher Blick für Automatisierung

Alexander beschreibt eine Herkunft, die vieles vorzeichnet: „Ich bin aus einer sehr technischen, handwerklichen Familie.“ Sein Vater arbeitete in der Automatisierungstechnik – eine Welt, in der Skilifte oder Papiermaschinen „mit einem Mausklick“ angesteuert werden. Dieses Bild bleibt hängen: Technik als unsichtbarer Hebel, der komplexe Anlagen bewegt. Wer damit aufwächst, bekommt ein Gespür dafür, wie Theorie und Praxis zusammenwirken.

Für Alexander war der nächste Schritt folgerichtig: eine Ausbildung an einer HTL in St. Pölten. Zuerst wählte er den Zweig Elektrotechnik, später den Schwerpunkt Informationstechnik, konkret industrielle Informationstechnik. Er beschreibt diese Kombination rückblickend als „eigentlich super“ – und eben nicht nur, weil sie praxisnah ist. Schon in dieser Phase vertiefte er sich in Programmiersprachen wie Java und C. Der Blick über den Tellerrand der reinen Elektronik hin zur Software war also früh vorhanden.

Frühe Karriere: Siemens, Automatisierung und der Praxisdruck der Industrie

Nach der HTL startete Alexander bei Siemens als Automatisierungstechniker. Hier lag der Schwerpunkt „sehr elektrotechnisch“. Doch das zuvor Gelernte blieb präsent: Die in der Schule erworbenen Kenntnisse in Java und C bildeten eine wertvolle Grundlage für das Verständnis von Systemen, Schnittstellen und Steuerungen – auch wenn die Rolle anfangs eher hardware- und steuerungslastig war.

Die industrielle Automatisierung ist eine Welt mit klaren Anforderungen: hohe Verlässlichkeit, robuste Prozesse und interdisziplinäres Denken. Dass Alexander genau dort begonnen hat, erklärt, warum er später so stark betont, wie wichtig Konzepte gegenüber einzelnen Technologien sind. Ob ein Skilift oder eine Papiermaschine – der Job verlangt, Strukturen zu erkennen, Abläufe zu verstehen und Stabilität zu priorisieren.

Ein Schwenk in die Geoinformation: Öffentlicher Dienst und Datenwelten

Nach Siemens folgten „viele Jahre im öffentlichen Dienst“. Inhaltlich ging es um Geodatenverarbeitung und Geoinformationstechnik. Das ist ein Brückenschlag in eine andere Domäne: weg von Steuerungen, hinein in die Welt strukturierter Daten. Wer täglich mit Geodaten arbeitet, lernt, wie wichtig saubere Datenflüsse und die sinnvolle Aufbereitung von Informationen sind. Zugleich entsteht eine neue Nähe zur Software – nicht unbedingt im Sinne des reinen Codens, wohl aber im Sinne datengetriebener Lösungen.

Alexander benennt genau an dieser Stelle seinen inneren Kompass neu: „Eigentlich sollte es schon wieder Richtung Informationstechnologie gehen. Ich würde gerne wirklich Software entwickeln und nicht Daten verarbeiten.“ Der Wunsch, wieder stärker zu bauen statt nur zu bewirtschaften, führt zur nächsten Station seines Weges.

Ankommen in der individuellen Softwareentwicklung: Objectbay

Der entscheidende Sprung: Alexander wechselt in die Softwareentwicklung und findet bei Objectbay genau das Umfeld, das zu seinem Profil passt. Parallel dazu entscheidet er sich für ein Studium nebenbei, das er „mittlerweile abgeschlossen“ hat – an der FH Campus Wien. Ausbildung, Industrie, öffentlicher Dienst, berufsbegleitendes Studium und der Wechsel zurück in die Software: Diese Abfolge steht für Konsequenz und Lernbereitschaft.

Heute sagt er schlicht: „Jetzt bin ich glücklich bei Objectbay und mache coole Projekte.“ Dahinter steckt mehr als Begeisterung – es ist das Ergebnis einer bewussten Weichenstellung: zurück zur Software, hin zu Teams, die im engen Austausch mit Kundinnen und Kunden Lösungen bauen.

Was Objectbay ausmacht: Maßgeschneiderte Lösungen statt vordefinierter Schablonen

Alexander beschreibt Objectbay als Anbieter individueller Softwareentwicklung. Kundinnen und Kunden kommen mit einem Problem, „das sie lösen möchten“, und das Team entwickelt eine passgenaue Software. Entscheidend: Es gibt keine „vorgefertigten oder vorgeschriebenen Technologien“. Die Teams haben Freiraum, die jeweils beste Lösung zu wählen.

• Agile Zusammenarbeit im Team
• Flache Strukturen
• Hoher kommunikativer Austausch mit dem Kunden
• Kundenseitiger Product Owner, der die Anforderungen für den nächsten Release priorisiert

Das klingt pragmatisch – und ist es auch. Individuelle Softwareentwicklung braucht eine Arbeitsweise, die zwei Dinge ermöglicht: zentrale Entscheidungen möglichst nah am Problem zu treffen und technologische Vielfalt als Stärke auszuspielen.

Technologische Bandbreite: Von Java über Python/Django bis zu Frontend-Frameworks

In Alexanders Beschreibung steckt ein klares Bild: „Technologisch haben wir eine irrsinnige Vielfalt drin.“ Er nennt Java, Python und Django-Projekte und betont auf der Frontend-Seite die Breite: „eigentlich so ziemlich jedes Framework, das man sich vorstellen kann.“ Dazu kommt die Option, sich zu spezialisieren – etwa in Infrastruktur, Kubernetes und DevOps.

Wichtig ist sein Hinweis: „Es ist nicht nur das reine Coden. Es geht wirklich darum, ganzheitlich für den Kunden etwas bereit zu stellen.“ Das ist ein professioneller Perspektivwechsel: Technologie ist Mittel, nicht Zweck. Wer individuelle Lösungen baut, denkt in End-to-End-Verantwortung – von der Anforderung über die Umsetzung bis zum Betrieb.

Entscheidungsfreiheit mit Verantwortung: Agile Teams als Problemlöser

Alexander skizziert ein Umfeld, in dem Teams bewusst Entscheidungen treffen. Agilität bedeutet hier nicht Buzzword, sondern gelebte Nähe zum Bedarf. Der kundenseitige Product Owner formuliert, „was für den nächsten Release zum Beispiel notwendig ist“, und das Team setzt es um. Die flachen Strukturen unterstützen schnelle Feedbackschleifen. Entscheidungen werden dort getroffen, wo sie am besten verstanden werden: im Team, im Austausch mit dem Kunden, nah am Produkt.

Diese Arbeitsweise hat zwei offensichtliche Effekte:

• Sie stärkt die Problemlösungskompetenz. Wer Anforderungen direkt klärt, versteht die Ursache und kann nachhaltiger handeln.
• Sie fördert Lernkurven. Vielfältige Technologien und reale Anforderungen zwingen zu Priorisierung, Pragmatismus und sauberer Kommunikation.

Konzepte wichtiger als Syntax: Lernen im Zeitalter der KI

Ein Schwerpunkt in Alexanders Botschaften: „Gerade jetzt im Zeitalter der KI ist es auch viel wichtiger, die Konzepte einfach zu verstehen. Also nicht auf eine Programmiersprache fokussieren, sondern wirklich das technische Konzept, die Ideen dahinter zu verstehen, die sich die letzten 50, 60, 70 Jahre entwickelt haben.“

Das ist ein starker Satz. Er rückt die Prioritäten zurecht: Sprachen kommen und gehen, Frameworks wechseln, Toolchains ändern sich rasant. Stabil bleibt, was dahinter liegt – Denkmodelle, Architekturprinzipien, klare Abstraktionen. Wer Konzepte versteht, kann neue Technologien schneller einordnen und souveräner entscheiden.

Für Entwicklerinnen und Entwickler heißt das konkret:

• Verstehen, was ein Problem wirklich ausmacht, bevor man eine Lösung auswählt.
• Werkzeuge nach ihrer Eignung beurteilen, nicht nach Bekanntheit oder Gewohnheit.
• Transferfähigkeit aufbauen: Was man in Java lernt, kann in Python genauso relevant sein – wenn man das zugrunde liegende Konzept durchdrungen hat.

Kommunikation statt Klischee: Der Mensch im Mittelpunkt

Alexander räumt mit einem hartnäckigen Bild auf: „Die Idee von dem Coder, der spät nachts mit einer Flasche Cola und einer Pizza vorm Computer sitzt, die muss man vergessen.“ Warum? Weil echte Softwareentwicklung Kollaboration ist. Wer Probleme lösen will, muss zuhören, Fragen stellen und die Perspektive des Gegenübers verstehen.

„Man muss wirklich mit Menschen kommunizieren. Man muss verstehen, was haben die eigentlich für Probleme, die ich lösen soll.“ Das ist die wohl wichtigste Kompetenz neben dem Technischen. Kommunikation macht Zeitpläne realistischer, Anforderungen klarer und Ergebnisse relevanter.

Seine praktischen Hinweise sind einfach und stark:

• Interesse zeigen
• Teamarbeit nutzen
• Um Hilfe bitten, wenn man ansteht

Dieses Selbstverständnis ist der Gegenpol zum einsamen Perfektionismus. Es stärkt Teams, schafft Vertrauen und macht Produkte besser.

Spezialisieren – aber bewusst: Infrastruktur, Kubernetes, DevOps

Neben der technologischen Breite hebt Alexander die Möglichkeit hervor, sich zu spezialisieren – zum Beispiel in Infrastruktur, Kubernetes und DevOps. Diese Felder sind integraler Bestandteil der End-to-End-Verantwortung: Deployment-Pfade, Skalierung, Ausfallsicherheit, Automatisierung von Abläufen. Wer sich hier vertieft, erweitert den Blick vom Code zum Betrieb.

Die implizite Botschaft: Spezialisierung und Generalismus schließen sich nicht aus. Man kann in einem Gebiet tiefer gehen und gleichzeitig die Grundkonzepte breit verstehen – gerade weil die Vielfalt im Projektgeschäft das verlangt.

Karrierepfade jenseits des Codens: Teamlead, Management, Product Owner

Alexander skizziert ein offenes Bild der Karriereentwicklung: „Wenn man später mal sagt, das reine Programmieren interessiert mich jetzt nicht mehr so, dann gibt es genug Möglichkeiten, in die man gehen kann. So wie bei mir Teamlead oder irgendwann ins Management, vielleicht als Product Owner in der agilen Welt.“

Der entscheidende Punkt ist nicht die Jobbezeichnung, sondern die innere Kompassnadel: „einfach am Ball bleiben und immer schauen, wo sind meine eigenen Interessen.“ Wer seine Interessen kontinuierlich reflektiert, kann den Kurs anpassen – ohne die Reise zu verlieren. Der Wechsel von der Automatisierung zur Geoinformation und schließlich zur individuellen Softwareentwicklung ist dafür ein gutes Beispiel.

Praxisnahe Learnings aus Alexanders Weg

Aus unserer Perspektive bei DevJobs.at ergeben sich aus dieser Devstory mehrere handfeste Erkenntnisse:

1) Technische Sozialisation ist wertvoll – aber nicht deterministisch.

Ein technisches Elternhaus und frühe Praxisnähe sind ein Turbo, kein Zwang. Sie vermitteln Neugier, Respekt vor Systemen und die Lust, Dinge zum Laufen zu bringen.

2) Ausbildung als Sprungbrett, nicht als Schublade.

HTL, elektrotechnischer Schwerpunkt, dann industrielle Informationstechnik – und dennoch offen für Softwareentwicklung: Entscheidend ist die Fähigkeit, Gelerntes zu transferieren. Dass Alexander bereits in der HTL Java und C gelernt hat, war eine frühe Investition in Breite.

3) Domänenwechsel schärft das Urteilsvermögen.

Vom Schaltschrank zu Geodaten: Solche Wechsel trainieren, Probleme aus verschiedenen Blickwinkeln zu betrachten – eine Schlüsselkompetenz für individuelle Softwareentwicklung.

4) Agilität leben heißt kommunizieren.

Flache Strukturen, kundenseitiger Product Owner, Teamentscheidungen – das funktioniert nur, wenn Kommunikation zentral ist. Anforderungen verstehen, Kompromisse abwägen, Ergebnisse erklären: Das ist tägliche Praxis.

5) Konzepte sind langlebiger als Syntax.

Im „Zeitalter der KI“ ist konzeptionelles Denken der Hebel, um neue Tools sinnvoll einzusetzen. Wer Prinzipien verinnerlicht, wechselt souveräner zwischen Technologien.

6) Spezialisierung ist eine Option, kein Dogma.

Infrastruktur, Kubernetes, DevOps – Spezialisierung erweitert die Wirkung, wenn sie bewusst gewählt ist und von einem soliden Konzeptverständnis getragen wird.

7) Karriere ist eine Folge von Entscheidungen – keine Gerade.

Der Wechsel zu Objectbay, das berufsbegleitende Studium an der FH Campus Wien und der Fokus auf Softwareentwicklung zeigen: Man kann die Richtung korrigieren und dabei an Profil gewinnen.

Zitate, die hängen bleiben

Wie Alexanders Stationen zusammenpassen

Rückblickend fügen sich die Stationen zu einer kohärenten Lernkurve:

• Technische Familie, Automatisierung im Elternhaus: Das Bild von Technik als Problemlöser prägt.
• HTL in St. Pölten, Wechsel von Elektrotechnik zu Informationstechnik: Die Bereitschaft, sich in neue Felder zu wagen.
• Siemens, Automatisierungstechnik: Verlässlichkeit, Interdisziplinarität, reale Systeme.
• Öffentlicher Dienst, Geodatenverarbeitung: Datenqualität, Informationsaufbereitung, Domänenwechsel.
• Rückkehr zur Softwareentwicklung, Objectbay: Agile Teams, Kundennähe, Vielfalt an Technologien.
• Studium an der FH Campus Wien: bewusstes Vertiefen und Strukturieren des Wissens.

Diese Linie zeigt: Lernen ist kumulativ. Jede Station zahlt auf das Profil ein, selbst wenn die Themen wechseln.

Konkrete Handlungsimpulse für Entwicklerinnen und Entwickler

• Baue ein konzeptionelles Fundament. Frage bei jedem neuen Tool: Welches Prinzip steckt dahinter?
• Übe das Übersetzen von Anforderungen. Was sagt der Kunde wirklich? Was ist der Kern des Problems?
• Wechsle bewusst zwischen Breite und Tiefe. Lerne mehrere Technologien kennen, wähle gezielt Bereiche für Spezialisierung (z. B. Infrastruktur, Kubernetes, DevOps).
• Pflege Teamarbeit als Kompetenz. Hole Feedback, bitte um Hilfe, lerne von anderen und teile dein Wissen.
• Korrigiere den Kurs, wenn es nötig ist. Wenn dich reines Datenverarbeiten nicht erfüllt, suche Jobs, in denen du aktiv Software baust.
• Erkenne, dass Karrierewege vielfältig sind. Prüfe Optionen wie Teamlead, Management oder Product Owner, wenn sich deine Interessen verschieben.

Warum diese Geschichte gerade jetzt relevant ist

Technologiezyklen werden schneller – genau deshalb gewinnen Prinzipien und Kommunikation an Gewicht. Alexanders Weg bestätigt, dass nachhaltiges Können aus drei Bausteinen entsteht:

• Konzeptverständnis (über Sprachen und Frameworks hinaus)
• Kollaboration (Kundennähe, Teamarbeit, klare Kommunikation)
• Verantwortungsübernahme (End-to-End-Denken, Spezialisierung dort, wo sie sinnvoll ist)

In der individuellen Softwareentwicklung, wie Alexander sie bei Objectbay beschreibt, werden diese Bausteine täglich gebraucht. Vielfalt ist normal, Lernen ist Teil des Jobs und der direkte Austausch mit Kundinnen und Kunden ist kein Zusatz, sondern Kern der Arbeit.

Schluss: Das Handwerk des Lösens

Am Ende lässt sich Alexanders Devstory in einen Satz fassen: Wer Probleme ganzheitlich versteht, kann sie wirksam lösen. Seine Reise von der Automatisierung über Geoinformation hin zur individuellen Softwareentwicklung liefert dafür den Kontext – seine Ratschläge geben die Werkzeuge an die Hand.

Für Entwicklerinnen und Entwickler heißt das: Vertraut auf Konzepte, pflegt Kommunikation, bleibt neugierig – und gestaltet eure Laufbahn aktiv, so wie Alexander Knapp es getan hat.

• 

  

  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.

  Jetzt ansehen
• 

  

  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.

  Jetzt ansehen
• 

  

  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.

  Jetzt ansehen
• 

  

  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.

  Jetzt ansehen