API‑First im Backend: Einblicke von Moemen Saad, Senior Software Developer at Genetec, in Microservices, Clean Code und kontinuierliches Lernen

Ein mehrsprachiges „Hello World“ – und der Start einer Entwicklerlaufbahn

„Hello. Ahlan. Servus. Dzień dobry. Hello. Privet. Buna ziua.“ Mit diesem lockeren, mehrsprachigen Auftakt holt uns Moemen Saad sofort ab. Der Backend-Entwickler beschreibt seinen Einstieg in die Softwarewelt mit einem vertrauten Bild: Es begann an der Universität – mit dem ersten „Hello World“ auf dem Bildschirm. Diese simple Ausgabe war für ihn mehr als eine technische Fingerübung. Sie stand sinnbildlich für etwas, das seine Arbeit bis heute antreibt: die Freude daran, „etwas zu erschaffen, das es vorher nicht gab“.

Dieser Antrieb zieht sich durch die Stationen, die er in seinem Gespräch anklingen lässt: vom Experimentieren mit Programmiersprachen über den Fokus auf API‑First bis hin zu den täglichen Routinen in einem Microservices‑Umfeld. Für uns bei DevJobs.at ist diese Story gerade deshalb spannend, weil sie sich nicht in Übertreibungen verliert. Moemen bleibt pragmatisch und klar: gute Architektur, bewusst getroffene Trade-offs, Qualität im Code – und die Bereitschaft, kontinuierlich zu lernen.

Vom Sprachenmix zur Lieblingssprache

Moemen nennt C++ und Visual Basic als frühe Begleiter – am wohlsten fühlt er sich heute in C#. Hier spürt man die typische Entwicklerbiografie: Breite am Anfang, Spezialisierung mit wachsender Erfahrung. Er verweilt nicht in Nostalgie, sondern lenkt schnell zu dem, was ihn fachlich prägt: einer API‑zentrierten Denkweise im Server‑Side‑Entwickeln.

API‑First, erklärt aus der Praxis

„It’s all about API.“ So bringt er es auf den Punkt. Das Team arbeite API‑First – also so, dass Schnittstellen als „first citizens“ behandelt werden. Was heißt das konkret?

API‑First bedeutet bei ihm nicht nur eine sauber dokumentierte Schnittstelle, sondern auch einen Prozess:

• Vor die Implementierung schaltet sich die Denkarbeit – Design, Diskussion, Abwägungen.
• Stakeholder werden früh eingebunden, um Feedback zum API‑Design einzuholen.
• Erst wenn das Interface verstanden und akzeptiert ist, beginnt die Umsetzung.

Diese Vorgehensweise klingt unspektakulär, ist aber in der Realität oft die wichtigste Weiche für robuste Systeme. Denn wenn APIs stabil und verständlich sind, können Teams unabhängig arbeiten, ohne sich später in Breaking Changes zu verheddern.

Verantwortlichkeiten im Backend – jenseits des grünen Feldes

Neben dem Neuaufbau von APIs pflegt Moemen bestehende Services und hält sie „performant und skalierbar“. Er erwähnt Pull Requests, Codequalität und Security‑Aspekte, nimmt bei Bedarf die technische Führung größerer Features und sorgt im Hintergrund für reibungslose Abläufe. Diese Mischung aus Weiterentwicklung und Wartung ist typisch für moderne Backend‑Rollen:

• Bestehende Services stabil halten und skalieren
• Pull‑Requests prüfen und Qualität sichern
• Sicherheitsfragen adressieren
• Bei größeren Features Verantwortung übernehmen

Gerade diese Balance – zwischen Architektur, Implementation und Pflege – schafft die Grundlage für verlässliche Plattformen.

Architekturdenken: Trade‑offs, POCs und die Lust am Ausprobieren

Moemen sagt offen, dass ihm die Phasen von Design und Architektur besonders liegen. Es gehe darum, „die beste Technologie je nach Use Case“ zu wählen und dabei die nötigen Trade-offs bewusst zu treffen. Proofs of Concept (POCs) sind für ihn ein zentrales Werkzeug, um Annahmen zu prüfen.

Diese Freude am Abwägen ist kein Selbstzweck. Sie verhindert, dass Teams vorschnell Entscheidungen treffen, die später teuer werden. In seinen Worten klingt an, worauf es in der Architektur wirklich ankommt:

• Effizienz in der Umsetzung: das richtige Maß statt maximalistischem Over‑Engineering.
• Hohe Codequalität: lesbar, erweiterbar, langlebig.
• Edge Cases: bewusst testen, statt auf Glück zu vertrauen.

Microservices und verteilte Systeme: die echten Herausforderungen

Sein Team arbeite in einer Microservices‑Architektur – und Moemen spart nicht mit nüchterner Aufzählung dessen, was dabei schwierig ist: Skalierung, Concurrency, Security‑Issues und Failure‑Handling.

Mit anderen Worten: Ohne Beobachtbarkeit ist eine verteilte Architektur ein Risiko. Tracking, Monitoring und Vorbereitung auf Ausfälle gehören zur Grundausstattung. Nicht, weil es modern klingt, sondern weil Fehler in verteilten Systemen normal sind.

• Skalierung: Dienste müssen Lastspitzen aushalten, ohne dass das Gesamtsystem kippt.
• Nebenläufigkeit: Gleichzeitiges Verarbeiten darf nicht zu Dateninkonsistenzen führen.
• Sicherheit: Jede Schnittstelle ist potenzieller Angriffsvektor.
• Ausfallbehandlung: Resilienz ist keine Option, sondern Pflicht.

Wer diesen Kanon ernst nimmt, baut nicht nur Features, sondern Systeme. Moemens Schwerpunkt auf Monitoring und Vorbereitung lässt erkennen, dass bei Genetec Betrieb und Entwicklung Hand in Hand gehen.

„Technology changes every day“ – die Haltung dahinter

Auf die Frage nach der einen wichtigsten Fähigkeit antwortet Moemen bewusst unspektakulär: Es gebe „nichts Spezifisches“, man müsse neugierig bleiben und sich an den Arbeitsanforderungen orientieren. Dieses Statement wirkt fast wie ein Gegenentwurf zu Trendlisten.

Nicht jeder Hype ist relevant. Entscheidend ist, Technologien im Kontext des eigenen Problems zu bewerten – und die richtige Wahl zum richtigen Zeitpunkt zu treffen.

Der Skills‑Baukasten: Was zählt im Backend?

Moemen benennt die Bausteine, die für ihn essenziell sind. Nichts daran ist „neu“, aber genau das macht die Liste so wertvoll:

• Algorithmen und Datenstrukturen: Fundament für Effizienz und korrektes Verhalten.
• Datenbanken – SQL wie NoSQL: das passende Modell zum Use Case wählen.
• API‑Wissen: im Server‑Side‑Design heute zentral.
• Objektorientierung: strukturiert denken und Kapselung sauber umsetzen.
• Clean Code: erweiterbar schreiben, damit Code „länger lebt“.
• Versionskontrolle: Zusammenarbeit und Nachvollziehbarkeit sichern.
• Kommunikation und Soft Skills: Anforderungen klären, Konflikte lösen, Entscheidungen tragen.

In Summe beschreibt er damit ein Profil, das nicht auf Spezialeffekte setzt, sondern auf Handwerk. Genau das macht Teams belastbar – und Produkte langlebig.

Wege in den Beruf: Studium, Bootcamp oder Self‑Learning

Viele Backend‑Entwickler:innen haben laut Moemen einen Bachelor in Informatik. Aber er zeichnet bewusst Alternativen auf, falls Zeit oder Budget fehlen: Online‑Universitäten, Bootcamps, Codingschulen oder konsequentes Selbststudium. Die gute Nachricht dabei:

Wichtiger als das Etikett der Ausbildung ist die Fähigkeit, dranzubleiben – und die Lernmethoden an die Realität des eigenen Lebens anzupassen.

Einstieg und Aufstieg: So baut man Momentum auf

Seine Ratschläge für den Start klingen konkret und machbar:

1. Eine Programmiersprache wählen, die zur eigenen Zielrolle passt.
2. Formale Wege sind möglich (Universität, Bootcamp, Schule) – der Zugang ist vielfältig.
3. Fähigkeiten stärken durch Praxis: POCs umsetzen, YouTube‑Kanäle schauen, Entwickler‑Meetups besuchen, an Coding‑Challenges teilnehmen.

Entscheidend ist die Schleife aus Ausprobieren, Feedback und Wiederholung. Genau hier schließt sich der Kreis zu seiner API‑First‑Haltung: Erst denken, dann entwerfen, dann gezielt bauen – und die Ergebnisse testen.

Unsere Learnings aus dem Talk: Prinzipien für Teams

Aus Moemens Aussagen lassen sich klare Prinzipien ableiten, die sich in Teams direkt verankern lassen – ohne Buzzwords und Tool‑Dogma.

1) Design zuerst: API als Produkt

Bevor etwas implementiert wird, sollten Teams das API‑Design ausformulieren und mit Stakeholdern abstimmen. Das spart Rework und schafft verlässliche Verträge zwischen Services.

• Gemeinsam Domänenbegriffe klären
• Edge Cases im Vertrag (Inputs/Outputs) explizit machen
• Feedback vor dem ersten Commit einholen

2) Codequalität und Sicherheit als Alltag, nicht als Phase

Pull‑Requests, Code‑Reviews und ein waches Auge für Security sind keine Extras, sondern unverhandelbarer Standard. Qualität entsteht kontinuierlich, nicht in Endspurts.

• Lesbarkeit und Erweiterbarkeit priorisieren
• Security‑Überlegungen früh und regelmäßig einfließen lassen
• Review‑Kultur als Teamkompetenz pflegen

3) POCs als Entscheidungswerkzeug

POCs sind kein Spielzeug, sondern die günstigste Art, Hypothesen zu testen und Trade‑offs bewusst zu machen.

• Kernfragen formulieren: Was soll der POC beweisen oder widerlegen?
• Zeitboxen setzen, Ergebnisse dokumentieren
• Erkenntnisse transparent ins Team tragen

4) Verteilte Systeme verlangen Beobachtbarkeit

Skalierung, Nebenläufigkeit, Sicherheit und Ausfälle sind nicht „falls sie passieren“, sondern „wenn sie passieren“. Tracking und Monitoring gehören zum Systemdesign.

• Metriken und Logs planen, bevor Systeme live gehen
• Alarme auf aussagekräftige Signale legen
• Failures antizipieren und Übungsszenarien definieren

5) Neugier als Langzeitstrategie

Technologie ändert sich – Prinzipien nicht. Wer neugierig bleibt, Lernquellen nutzt und Probleme kontextsensitiv löst, trifft bessere Entscheidungen.

• Lernziele am realen Bedarf im Job ausrichten
• Informationsdiät: Relevanz vor Quantität
• Regelmäßig reflektieren: Was hat funktioniert, was nicht?

C#, aber nicht dogmatisch

Auch wenn Moemen C# „am meisten“ mag, wird klar: Es geht nicht um Rechthaberei für eine Sprache, sondern um das passende Werkzeug für den Use Case. Diese Haltung erdet Diskussionen – und öffnet die Tür für pragmatische Teams, in denen Expertise vor Eitelkeit steht.

Ein realistisches Bild vom Backend

Was uns an Moemens Erzählung überzeugt, ist die Bodenständigkeit. Kein „Silver Bullet“, kein Hype‑Talk. Stattdessen:

• APIs zuerst denken
• Design mit Stakeholdern klären
• Services betreiben und skalieren
• Codequalität sichern
• Security ernst nehmen
• POCs für Entscheidungsfindung einsetzen
• Microservices beobachtbar machen
• Weiterlernen als Gewohnheit pflegen

Diese Themen definieren den Alltag von Backend‑Teams weit besser als jedes Schlagwort.

Konkrete nächste Schritte für Entwickler:innen

Wer aus Moemens Erfahrungen direkt Handlungen ableiten will, kann mit kleinen, klaren Schritten beginnen:

• Wähle eine Sprache (z. B. C#) und setze ein kleines Service mit einer bewusst designten API um.
• Schreibe das API‑Design als Spezifikation nieder und hole Feedback ein – bevor du implementierst.
• Implementiere Endpunkte und lege von Anfang an Wert auf Lesbarkeit, Tests und Erweiterbarkeit.
• Plane, welche Metriken und Logs du brauchst, um das Verhalten deines Services zu verstehen.
• Simuliere Ausfälle (z. B. Zeitüberschreitungen) und beobachte, wie dein Service reagiert.
• Stelle dein Ergebnis in einem Meetup vor oder dokumentiere es in einem Blogpost – Feedback schärft dein Denken.

Diese Mini‑Projekte entsprechen genau dem POC‑Gedanken, den Moemen betont. Sie machen Theorie messbar – und Lernfortschritt sichtbar.

Bildung ist Mittel, nicht Zweck

Ob Bachelor, Bootcamp oder Selbststudium: Am Ende zählt, dass du kontinuierlich Kompetenzen aufbaust. Moemen unterstreicht, dass heute „buchstäblich alles von zu Hause“ möglich ist. Das entzaubert die Ausrede fehlender Zugänge – und rückt die Verantwortung fürs eigene Lernen in die erste Reihe.

Schlussgedanken: „Be curious“ als Berufsethos

Wenn wir Moemens Story auf einen Nenner bringen, dann diesen:

• Erschaffe bewusst: Denke APIs als Verträge, bevor du Code schreibst.
• Handle verantwortlich: Qualität, Sicherheit und Betrieb sind Teil deiner Definition of Done.
• Lerne stetig: Prüfe Trade‑offs, baue POCs, bleib neugierig.

Die Botschaft ist so einfach wie anspruchsvoll. Doch gerade diese Einfachheit hilft, im Rauschen der Tech‑Welt Kurs zu halten. Für alle, die Backend ernst nehmen, ist das ein nordsternähnlicher Rat – aus der Praxis, für die Praxis.

• 

  

  Florian Matusek, Product Group Director at Genetec

  Product Group Director bei Genetec Florian Matusek erzählt im Interview über die Aufgaben des Teams und woher der Spitzname "Wrecking Crew" für die Abteilung kommt.

  Jetzt ansehen
• 

  

  Stephan Sutor, Product Group Director at Genetec

  Product Group Director bei Genetec Stephan Sutor spricht im Interview über Domain Driven Design und wie dieses Prinzip im Team angewandt wird.

  Jetzt ansehen

• 

  

  Ilia Gutu, Mobile Developer at Genetec

  Ilia Gutu von Genetec erzählt im Interview über seinen Werdegang, angefangen mit Delphi, über Umwege im Embedded Development bis hin zu seiner aktuellen Arbeit als Mobile Developer und gibt Tipps, wie man am Besten up to date bleibt.

  Jetzt ansehen
• 

  

  Rafal Dabek, Back End Developer at Genetec

  Rafal Dabek von Genetec erzählt im Interview wie er zum Programmieren gekommen ist, was das Spannende an seiner aktuellen Arbeit ist und spricht darüber, was seiner Meinung nach wichtig für Beginner ist. Mehr zum Team von Genetec: https://devjobs.at/team/genetec devjobs.at IT Career Days Playlist: https://www.youtube.com/playlist?list=PLxwoARCP1-pStxUV52y__-iN43N8BMJ2P

  Jetzt ansehen
• 

  

  Spandana Kanadam Ravindranath, Computer Vision Developer at Genetec

  Spandana Kanadam Ravindranath von Genetec redet im Interview über ihre ersten Berührungspunkte mit dem Programmieren, was ihre aktuelle Arbeit als Computer Vision Developer umfasst und gibt Tipps für Leute, die ebenfalls in diesem Berufsfeld starten möchten.

  Jetzt ansehen