Vom Sprachenschwerpunkt zum Datenbankentwickler: Manuel Reichstamms Weg zu iterativer, wartbarer Software bei DBConcepts GmbH

Ein Einstieg, der gar nicht nach IT aussah

Als wir die Session „Manuel Reichstamm, Database Developer bei DBConcepts“ sahen, fiel uns zuerst der ungewöhnliche Start seiner Laufbahn auf: eine ganz normale AHS mit Sprachenschwerpunkt – und keine besondere Technikbegeisterung zu Beginn. Manuel sagt offen, er sei „immer so ein bisschen offen für sämtliche Dinge“ gewesen, aber Technik habe ihn anfangs nicht gepackt. Dass er heute Datenbankentwickler ist und genau darin seinen Platz gefunden hat, zeigt: Karrieren in der Software sind selten linear – und es gibt mehr als nur einen Weg hinein.

Der Weg dorthin begann zufällig. Manuel „ist eigentlich durch Zufall auf eine HTL-Kollege gekommen“, eine Ausbildung, die er als Mischung aus Wirtschaft und Informatik beschreibt. Genau diese Kombination erwies sich als sein Sprungbrett. Statt einer abstrakten, isolierten Ausbildung lernte er früh, wie technische Entscheidungen mit Geschäftsprozessen zusammenhängen – eine Perspektive, die seine heutige Arbeitsweise stark prägt.

C als Fundament, Datenbanken als Funke

In der Ausbildung startete Manuel „ganz klassisch einmal mit C“. Diese Wahl ist bemerkenswert: Wer mit C beginnt, lernt früh, präzise zu denken, Datenstrukturen bewusst zu modellieren und sich auf das Wesentliche zu konzentrieren. Für viele ist C das „Härtetraining“, das späteres Arbeiten an Systemen greifbarer macht.

Der eigentliche Funke sprang im zweiten Jahr über: „… im zweiten Jahr war dann schon ein Schwerpunkt Datenbanken. Und da habe ich mir damals eigentlich schon gedacht, das könnte mich eigentlich in Zukunft auch länger interessieren.“ Das ist ein Schlüsselmoment. Viele Entwicklerinnen und Entwickler entdecken ihr Feld, wenn Theorie plötzlich in konkreten Strukturen landet: Daten modellieren, Konsistenz sichern, Anfragen effizient machen, reale Prozesse abbilden. Datenbanken sind dafür prädestiniert, weil sie die Brücke zwischen Businesslogik und Technik sind – genau der Schnitt, auf dem Manuel heute arbeitet.

Praxis statt Fiktion: Lehrkräfte aus der Industrie

Prägend war für Manuel auch, dass seine Lehrkräfte „von der Praxis gekommen sind“. Die Projekte waren „sehr praxisnahe Beispiele“, keine „wild fiktiven Beispiele“. Dieser Unterschied ist elementar: Wenn Beispiele real wirken, spürt man die Relevanz – und Motivation entsteht. Manuel beschreibt diesen Effekt klar: „Es war so praxisnah, dass ich mir eigentlich gedacht habe, das ist schon ziemlich spannend und der Bereich würde mich schon ziemlich interessieren.“

Für uns als DevJobs.at-Redaktion ist das eine zentrale Beobachtung: Praxisnähe katalysiert Lernkurven. Und sie schafft einen Hebel für Selbstwirksamkeit: Das, was ich heute baue, löst morgen ein echtes Problem.

Bewusste Entscheidung: Ein Job in der Datenbankwelt

Am Ende dieser Ausbildung stand für Manuel eine klare Wahl: „Deswegen habe ich mich dann auch dazu entschieden, einen Job im Datenbankbereich zu suchen und habe den dann auch Gott sei Dank gefunden.“ Der Schritt war keine Bauchentscheidung – er fußt auf Erfahrung, Neugier und greifbarer Praxis. Sein Fazit dazu ist eindeutig: „Ich habe es auf keinen Fall bereut.“

Dieser Satz trägt. Er signalisiert, dass er nicht nur eine Technologie mag, sondern in einem Arbeitsmodus angekommen ist, der zu ihm passt: nah am Problem, nah am Kunden, mit Fokus auf Qualität über den gesamten Lebenszyklus.

Was ein Database Developer bei DBConcepts GmbH wirklich macht

Wer „Datenbankprogrammierer“ hört, denkt schnell an SQL, Stored Procedures und Schema-Design. Bei DBConcepts GmbH ist die Rolle laut Manuel jedoch deutlich breiter – und vor allem: kundennah.

Vom Prozess zur Software: Entwickler im Kundengespräch

Der Arbeitstag beginnt nicht mit Code, sondern mit Verständnis:

• „… mit dem Kunden eigentlich genau einmal abstimmen, was hat der Kunde für Prozesse“
• „… und wie können wir das in der Software eigentlich so entwickeln, dass die Prozesse leichter für den Kunden zu gestalten sind“

Das ist Anforderungsanalyse als Teamaufgabe – und zwar nicht ausgelagert an eine separate Consulting-Schicht. Manuel betont explizit: „… wir sind als Entwickler nicht nur im Hintergrund, wo irgendein Consultant uns sagt, was der Kunde braucht, sondern das sind auch wir, der mit dem Kunden das genau abstimmt.“

Diese direkte Linie zwischen Entwicklerteam und Fachdomäne ist ein Qualitätsmerkmal. Sie verkürzt Feedbackschleifen, minimiert Missverständnisse und erhöht das Verständnis für die wirklichen Pain Points der Anwender.

Inkrementell liefern statt Big Bang

Manuel beschreibt eine inkrementelle Entwicklungsweise als Standard:

Das klingt nach pragmatischem, risikoarmen Vorgehen: früher Nutzen, frühes Feedback, weniger Reibung. Gerade bei datenlastigen Systemen ist diese Arbeitsweise entscheidend – denn Datenmodelle und Auswertungen zeigen oft erst unter realen Bedingungen, wo sie klemmen.

Verantwortung über den Go-Live hinaus: Wartung und Betreuung

Ein zweites Prinzip sticht hervor: Ownership über den gesamten Lebenszyklus.

Diese Kontinuität zwingt zu guter Technik. Wer weiß, dass er selbst die Lösung später betreut, entwickelt anders:

• „… wie entwickeln wir die Sachen eigentlich, dass sie dann möglichst wartbar auch für uns sind“
• „… wir arbeiten ja schließlich im Endeffekt dann noch weiter damit und müssen uns dann eigentlich auch noch auskennen“

Das ist ein starkes Statement für Wartbarkeit als Leitmotiv. Man merkt, hier geht es nicht um kurzfristige Abnahmen – sondern um Systeme, die in einem Jahr, in zwei Jahren, noch verständlich sind.

Drei Leitprinzipien, die wir aus der Session mitnehmen

Manuels Erzählung enthält klare, wiederkehrende Muster. Aus unserer Sicht als Redaktion lassen sich daraus drei Leitprinzipien für Teams ableiten:

1) Entwickler sprechen mit dem Fachbereich

• Direkter Austausch reduziert Reibungsverluste.
• Domänenwissen wächst im Team, nicht nur in Doku.
• Entscheidungen werden nachvollziehbar, weil sie auf echten Prozessen basieren.

2) Inkrementelle Auslieferung in Arbeitspaketen

• Kleine, testbare Einheiten erleichtern Feedback.
• Änderungen werden früh sichtbar statt spät schmerzhaft.
• Vertrauen wächst durch regelmäßige, nutzbare Ergebnisse.

3) Wartbarkeit als Projektziel, nicht als Nachgedanke

• „Wir müssen uns später noch auskennen“: Architektur, Namensgebung, Tests und Doku werden dadurch zu Investitionen.
• Wer statt Big Bang in Etappen liefert, kann Wartbarkeit iterativ entwickeln.
• Betreuung nach dem Go-Live schafft Lernschleifen: Was gestern gebaut wurde, zeigt heute seine Tücken – und morgen sind wir besser.

Studium? Nicht zwingend. Sitzfleisch? Unbedingt.

Ein dritter, persönlicher Strang in Manuels Geschichte ist sein Blick auf Ausbildung und Lernen. Er macht keine große Sache daraus, ob man ein Studium hat oder nicht:

Wichtiger sind für ihn Haltung und Ausdauer:

• „… das nötige Sitzfleisch und das Herzblut, dass man sich wirklich in die Materie einliest“
• „Es mag am Anfang vielleicht ein paarmal deprimierend sein … aber meistens kommen dann die Lösungen bei Gelegenheiten, wo man jetzt nicht gerade denkt, da könnte mir jetzt eine Lösung einfallen.“

Und er unterstreicht den Wert des Selbststudiums: „Es gibt in unserer heutigen Welt ziemlich viele Möglichkeiten, … im Selbststudium relativ viel lernen.“

Für Einsteigerinnen und Einsteiger ist das eine Einladung: Lernen ist zugänglich – aber es braucht Beharrlichkeit. Gerade in der Datenbankentwicklung, wo Konzepte oft abstrakt wirken, hilft es, dranzubleiben, kleine Erkenntnisse zu stapeln und regelmäßig mit realen Beispielen zu arbeiten.

Vom Taschenrechner zur Produktidee: Lernen an greifbaren Projekten

Sehr konkret wird Manuel bei der Frage, wie man startet. Sein Rat: Erst Grundlagen, dann ein Praxisbeispiel, das man Ende-zu-Ende umsetzt. Der Klassiker:

Warum ist dieses Beispiel so wertvoll? Weil es die Bausteine echter Software enthält – und zwar ohne Ballast:

• Eingaben validieren (Zahl oder nicht?)
• Logik sauber trennen (Operationen, Fehlerfälle)
• Ausgaben verständlich präsentieren
• Schrittweise erweitern (Multiplikation, Division, Speicherfunktion, Historie)

Aus diesem Ansatz lässt sich ein Muster für den Weg in die Datenbankentwicklung ableiten:

1) Kleines, überschaubares Domänenproblem wählen.

2) Die Daten identifizieren: Welche Entitäten, welche Attribute, welche Beziehungen?

3) Ein minimales Datenmodell entwerfen und bewusst einfach halten.

4) Mit einer kleinen Anwendung verdrahten – CRUD-Funktionen reichen zunächst.

5) In Etappen erweitern, Feedback einholen, Modell anpassen.

Das ist genau das, was Manuel in seiner Arbeit beschreibt – nur eben im Lernformat. Inkrementell bauen, testen, anpassen. So wird aus Übung Verständnis.

Wie Manuels Ansatz die Qualität hebt

Aus Entwicklersicht zeigen sich klare Qualitätshebel in der geschilderten Arbeitsweise:

• Frühzeitige Domänenkenntnis: Wer Prozessesemantik versteht, modelliert Daten stimmiger.
• Iterationen statt Perfektionsfalle: Risiken werden schrittweise abgebaut, nicht verdrängt.
• Wartbarkeit als First-Class-Concern: Namenskonventionen, Strukturierung und klare Verantwortlichkeiten entstehen nicht als Pflicht, sondern aus eigenem Interesse – „wir müssen uns später noch auskennen“.
• Feedback-Schleifen ernst nehmen: Die Welt hinter den Daten (User, Prozesse) ist nicht statisch; iterative Übergaben sind das Gegenmittel zu Ewigkeitsprojekten.

Konkrete Schritte für angehende Datenbankentwicklerinnen und -entwickler

Aus dem Gesagten lassen sich praktische To-dos formulieren, die Manuels Prinzipien in den Alltag übertragen:

• Direkt mit Nutzerinnen und Nutzern sprechen: Verstehe den Prozess, bevor du das Schema zeichnest.
• Datenmodell minimal starten: Erst wenn echte Anwendungsfälle auftauchen, wachsen.
• In Arbeitspaketen planen: Jede Iteration liefert etwas Testbares.
• Frühzeitig an Wartbarkeit denken: Lesbare Namen, modulare Abgrenzungen, einfache Abläufe.
• Feedback priorisieren: Nach jeder Teilübergabe Tests einplanen und Änderungswünsche ernst nehmen.
• Selbststudium mit kleinen Projekten: Vom Taschenrechner zu einer Mini-App mit Datenhaltung – Schritt für Schritt.

Diese Punkte sind keine Theorie – sie ergeben sich aus der Arbeitsrealität, die Manuel beschreibt. Und sie funktionieren unabhängig davon, welche Sprache oder welches Datenbanksystem man nutzt.

Der stille Erfolgsfaktor: Selbstvertrauen in kleinen Dosen

Manuel spricht darüber, wie frustrierend die ersten Schritte sein können – und dass Lösungen oft dann auftauchen, „wo man jetzt nicht gerade denkt, da könnte mir jetzt eine Lösung einfallen“. Diese Erfahrung kennt jeder, der Programmieren lernt: Das Gehirn arbeitet weiter, auch wenn man es nicht merkt. Was hilft, ist ein Prozess, dem man trauen kann:

• Problem greifen, zuschneiden, kleinschrittig lösen.
• Pausen erlauben, Perspektive wechseln.
• Zurückkehren, verifizieren, weitermachen.

Die Art, wie Manuel und das Team bei DBConcepts GmbH Projekte gliedern – „in verschiedene Arbeitspakete“ mit Teilstücken, Feedback und Anpassungen – ist genau so ein Prozess. Er schützt vor Überforderung, weil er auf Lern- und Nutzbarkeitsschleifen setzt.

Iteration und Wartbarkeit: Zwei Seiten derselben Medaille

Viele Teams trennen „Delivery“ und „Wartung“ – erst entwickeln, später aufräumen. Manuels Perspektive dreht das um: Wenn ich weiß, dass ich die Lösung weiterbetreue, dann gestalte ich sie heute wartbar. Und wenn ich in Iterationen liefere, dann wird Wartbarkeit fortlaufend hergestellt und überprüft – nicht in einem nachgelagerten, oft unrealistischen „Hardening“-Schritt.

Diese Kopplung ist in der Praxis Gold wert, insbesondere im Datenbankumfeld, wo Anpassungen an neue Anforderungen regelmäßig das Datenmodell betreffen. Wartbarkeit beginnt im Gespräch mit dem Kunden, setzt sich in der Struktur der Arbeitspakete fort und zeigt sich schließlich im Betrieb – dort, wo „wir uns dann auch noch auskennen“ müssen.

Unser Fazit aus „Manuel Reichstamm, Database Developer bei DBConcepts“

Manuels Weg zeigt, dass Talentpfade vielfältig sind. Wichtiger als der perfekte Start ist die Bereitschaft, sich auf echte Probleme einzulassen, iterativ zu lernen und Verantwortung auch nach dem Go-Live zu übernehmen. Drei Aussagen bleiben hängen:

• „… nicht nur stures Entwickeln“ – Entwicklerinnen und Entwickler gehören ins Gespräch mit dem Fachbereich.
• „… in verschiedene Arbeitspakete gliedern“ – kleine Lieferungen schaffen Klarheit und Vertrauen.
• „… möglichst wartbar“ – wer morgen betreut, baut heute besser.

Für uns ist das die Essenz dessen, was moderne Datenbankentwicklung ausmacht: Praxisnähe, Iteration, Ownership. Und für alle, die einsteigen wollen, hat Manuel einen einfachen Startpunkt parat: Fang klein an, bleib dran, lerne im Tun – auch ein Taschenrechner kann der Anfang einer großen Reise sein.