Logo fiskaly GmbH

fiskaly GmbH

Startup

Kostas Plakidas, Back End Developer bei fiskaly

Description

Kostas Plakidas von fiskaly spricht im Interview über seinen Werdegang – angefangen bei Turbo Pascal bis hin zu seiner aktuellen Arbeit – und gibt Tipps für Anfänger.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In 'Kostas Plakidas, Back End Developer bei fiskaly' schildert Kostas Plakidas seinen Weg vom 16‑jährigen Turbo‑Pascal‑Tüftler über Elektrotechnik und ein Ph.D.-Studium in Informatik in Österreich bis zum Backend-Entwickler bei fiskaly, wo er vor allem mit Go sowie Java/TypeScript auf der Google Cloud Platform arbeitet. Er wechselte aus der eher theoretischen Forschung (u. a. Python, R) in die Industrie, um praxisnahe Herausforderungen zu lösen und an einer Cloud-Fiskalisierung zu bauen, die Belege kryptografisch signiert und so Steuerbetrug bekämpft. Er beschreibt die operative Komplexität mit Edge Cases, zertifizierten Komponenten und langwieriger Rezertifizierung, die Architektur-Trade-offs und „Detektivarbeit“ erfordert; sein Rat: durch Ausprobieren lernen, offen und kooperativ bleiben – Quereinsteiger aus verschiedensten Disziplinen können erfolgreich sein.

Von Turbo Pascal zu Cloud-Fiskalisierung in Go: Die Entwicklerreise von Kostas Plakidas, Back End Developer bei fiskaly GmbH

Ein Entwicklerporträt aus erster Hand

In unserer devstory mit dem Titel „Kostas Plakidas, Back End Developer bei fiskaly“ nimmt uns Speaker Kostas Plakidas von der fiskaly GmbH mit auf eine Reise, die so viele Entwicklerinnen und Entwickler kennen: neugieriges Tüfteln am heimischen PC, ein Studium voller Sprachen und Paradigmen, der Schritt in die Forschung – und schließlich die Entscheidung für ein produktionsreifes Umfeld, in dem reale Probleme gelöst werden. Seine Geschichte vermittelt, wie aus spielerischer Neugier eine belastbare technische Haltung wird: pragmatisch, lösungsorientiert und stets lernbereit.

Wir fassen die Stationen, Denkweisen und Lehren zusammen, die uns in diesem Gespräch besonders hängen geblieben sind – mit Blick darauf, was Software Engineers daraus für ihren eigenen Weg mitnehmen können.

Die ersten Zeilen Code: Neugier, Spiele und Turbo Pascal

Alles beginnt bei Kostas mit einer einfachen Frage: Wie funktionieren die Dinge eigentlich, die ich am PC nutze? Mit 16 Jahren, als bereits einige Spiele auf dem Rechner liefen, fällt ihm eine Installationsdiskette von Turbo Pascal in die Hände – der Funke springt über. Er beginnt zu „spielen“ – zuerst kleine Anwendungen, testweise, um auszuloten, „was in meinem Home PC möglich ist“.

  • Erste Werkzeuge: Turbo Pascal
  • Motivation: das Innenleben von Software hinterfragen
  • Lernmodus: Ausprobieren, kleine Programme, pragmatisches Tüfteln

Diese Frühphase ist typisch für viele Entwicklerkarrieren: Ohne formale Struktur, aber mit viel intrinsischer Motivation entsteht der Grundstein – konkrete, sichtbare Ergebnisse befeuern die nächste Lernschleife.

Studienjahre: Vom Elektrotechnik-Start zur Informatik

Kostas beginnt sein Studium als Elektroingenieur. Doch das große Ganze weist früh in eine andere Richtung: Programmiersprachen sind nicht nur „die Zukunft“ – sie beflügeln auch andere Disziplinen. An der Universität arbeitet er mit C++, Java, Fortran, VHDL und Assembly. Damit öffnet sich der Blick auf Paradigmen und Abstraktionsebenen, die später das architektonische Denken prägen sollen.

„Ich habe sehr bald bemerkt, dass Software und Programmierungssprachen nicht nur die Zukunft sind. Sie haben allen anderen Wissenschaften geholfen.“

Diese Einsicht führt zur Neuorientierung: Entscheidung für Computerwissenschaften und Informationswissenschaften. Theorie, Mathematik, Algorithmen, Architekturkonzepte – das Studium liefert robuste mentale Modelle. Gleichzeitig bleibt Kostas Realist: Theorie allein genügt nicht.

Griechenland, Österreich, Ph.D. – und dann: Industrie

Nach einiger Zeit Berufserfahrung in Griechenland zieht es Kostas nach Österreich, um dort den Ph.D. in Computerwissenschaften zu machen. Gegen Ende des Promotionsvorhabens tritt ein Impuls in den Vordergrund, der seinen weiteren Kurs bestimmt: zurück in die Industrie.

Die Gründe sind bodenständig und klar. Forschung ist „sehr lustig“, nutzt Sprachen wie Python und R und erzeugt wertvolle Ideen – doch sie bleibt tendenziell „abstrakt und theoretisch“. Der Wunsch, etwas „anstrengendes“ zu tun, echte Probleme zu lösen und sich bewusst Herausforderungen auszusetzen, wird zur Triebfeder.

„Ich wollte wirklich zurück in die Industrie und etwas tun, das mehr anstrengend ist, wo ich Dinge lernen kann, Probleme lösen kann und Herausforderungen stellen kann.“

Der nächste Schritt: Kostas kommt zur fiskaly GmbH und startet dort als Backend-Entwickler.

Warum fiskaly GmbH? Lernen, Vielfalt, echte Wirkung

Kostas benennt eine „große Vielfalt“ an Gründen, die ihn zu fiskaly geführt haben. Technische Angebote, unterschiedliche Programmiersprachen, die Möglichkeit, Dinge zu lernen – und die Aussicht, im direkten Zusammenspiel von Anforderungen, Architektur und Betrieb zu wachsen. Eine Aussage, die in seiner Erzählung immer wieder mitschwingt: Lernen geschieht dort, wo es konkrete Zwänge gibt.

  • Vielfältiger Stack: Go als Hauptsprache, außerdem Java und viel TypeScript
  • Cloud-Infrastruktur: Nutzung der Ressourcen der Google Cloud Platform
  • Lernfelder: Architekturentscheidungen, Betrieb, Fehlerszenarien und Edge Cases

Schon an dieser Stelle wird deutlich: Für Kostas bedeutet fachliche Entwicklung, gezielt in Systeme einzutauchen, die reale Konsequenzen haben – Strategien abwägen, Optionen prüfen und dabei die langfristige Wartbarkeit im Blick behalten.

Das Produktfeld: Fiskalisierung als „edle“ Aufgabe

Kern des Produkts bei fiskaly ist die Fiskalisierung. Dahinter steht eine klare Idee: Belege (z.B. Rechnungen) werden digital gestempelt und verschlüsselt, sodass sie im Nachhinein nicht mehr manipuliert werden können. Das schützt vor Steuerbetrug – „eine sehr wertvolle und noble Ursache“.

„Unser Produkt ist Fiskalisierung. Es bietet eine Fiskalisierungssolution, die eine Möglichkeit ist, dass Rechnungen digital gestoppt und gekryptiert sind und sie nicht von jemandem im Nachhinein geändert werden können.“

Diese Aufgabe ist sowohl gesellschaftlich relevant als auch technisch reizvoll. Denn zwischen rechtlichen Anforderungen, Betriebssicherheit und Nutzerfreundlichkeit besteht ein Spannungsfeld, das smarte Architektur verlangt.

Vom lokalen Ansatz zur Cloud – und was dadurch besser (und schwieriger) wurde

Kostas zeichnet den Wandel skizzenhaft nach: Das Produkt für den deutschen Markt entstand ursprünglich als „lokale Lösung“. Neben der Kasse gab es eine zusätzliche Komponente – „sowohl Hardware als auch Software“. In puncto Sicherheit und Wartung: „ein bisschen ein Albtraum“.

Die Konsequenz: Das Konzept wandert in die Cloud – mit dem Ziel, eine „viel elegantere Lösung“ zu schaffen. Dieser Schritt beseitigt Klassen von Problemen (Verteilung, Hardwarevarianten, lokale Pflege), öffnet aber zugleich neue Baustellen: Betrieb in großem Maßstab, verteilte Komponenten, Fehlerbilder über Systemgrenzen hinweg.

  • Lokal: zusätzliche Hardware-/Software-Komponente, hoher Wartungs- und Sicherheitsdruck
  • Cloud: eleganter Ansatz, zentralisierter Betrieb, aber komplexere Systemdynamik

Das bringt Kostas zu einer Formulierung, die hängen bleibt: Die reale Operation ist „ein riesiges Biest“, das über die Zeit „seine eigene Behauptung“ entwickelt – sprich: sein Eigenleben. Mit anderen Worten: Produktion ist nicht bloß Ausführung eines Plans, sondern eine lebendige Situation, in der Unvorhergesehenes die Regel ist.

Debugging als Detektivarbeit: Edge Cases und Systemwissen

In dieser Welt muss man bei Problemen schnell herausfinden, „was los ist“. Kundenseitige Aktionen können zu „unerwarteten“ Effekten führen – also wird Ursachenforschung zur Routine.

„Du musst ein bisschen als Detektiv spielen.“

Die Taktik dahinter ist ebenso schlicht wie anspruchsvoll:

  • Erfahrungen über alle Komponenten sammeln
  • Vorausdenken: Welche Dinge könnten schiefgehen, bevor sie tatsächlich zu Problemen werden?
  • Muster erkennen, Edge Cases einfangen, Rückkopplungen verstehen

Diese Haltung ist ein Markenzeichen reifer Backend-Entwicklung: Troubleshooting nicht als Ad-hoc-Aktion, sondern als strukturierten Prozess begreifen – Hypothesen bilden, Instrumentierung nutzen, sauber kommunizieren und nachvollziehbare Fixes einbringen.

Zertifizierte Komponenten: Wenn der Bug bleibt – und du trotzdem liefern musst

Ein besonderer Dreh in der Fiskalisierung: Manche Komponenten sind zertifiziert. Das heißt, sie sind reguliert und dürfen nicht einfach geändert werden. Wird in einer solchen Komponente ein Fehler gefunden, beginnt ein formaler Ablauf: „eine Anfrage für einen Zertifizierungsprozess“, anschließend „den Zertifizierungsprozess starten“ und alle Schritte „die ein paar Monate dauern können“.

„Das heißt, du kannst sie nicht wirklich anfassen, bis sie zertifiziert sind.“

In dieser Zeit ist der Fehler real – und doch muss das System funktionieren. Genau hier beginnt für Kostas „der Spaß“: Mitten in strikten Anforderungen Wege finden, das Problem in anderen Komponenten zu mitigieren, ohne die Vorgaben zu verletzen.

  • Rahmenbedingungen: strenge Anforderungen an das Systemverhalten
  • Strategie: Fixes und Workarounds außerhalb der zertifizierten Teile
  • Auswirkung: Architektur und Betrieb sind eng verzahnt; Optionen werden nach kurz- und langfristigem Nutzen bewertet

Diese Passagen zeigen deutlich: Architektur ist kein Elfenbeinturm. Sie entsteht aus gelebter Praxis, in der Zwänge navigiert und Kompromisse bewusst gewählt werden.

Architektur als Langstrecke: Heute reparieren, morgen weniger bereuen

Kostas spricht explizit von der Notwendigkeit, „Optionen auf dem Tisch zu haben und sich dazwischen zu wählen“ – „mit Blick auf das, was uns langfristig erlangen wird“. Dieser langfristige Blick spiegelt sich in vielen Aspekten wider:

  • Leichte Änderbarkeit trotz Zertifizierungszwängen
  • Saubere Schnittstellen, die Mitigationen erlauben
  • Polyglotte Umsetzung: Go im Zentrum, flankiert von Java und TypeScript
  • Cloud-Ressourcen gezielt einsetzen (Google Cloud Platform)

Gerade die Kombination aus stark regulierten Bereichen und schneller Produktentwicklung fordert eine robuste, aber flexible Architektur. Kurzfristige Fixes sind erlaubt – solange sie im Konzert mit dem Gesamtsystem spielen und die Weichen für spätere Verbesserungen stellen.

Stack und Werkzeuge: Go im Zentrum, kombiniert mit Java, TypeScript und GCP

Was läuft konkret? Kostas formuliert es klar: „Die meisten unserer Komponenten sind in Go gebaut, aber wir benutzen auch Java, viel TypeScript und natürlich die Infrastruktur und die Ressourcen einer Google Cloud Plattform.“

„Ich könnte da drei, vier Jahre arbeiten, ohne die volle Größe der Optionen und Möglichkeiten zu überleben. Und das ist das Spaß daran.“

Die Aussage transportiert zwei Dinge:

  1. Lernpfade sind zahlreich: Vom Service-Design in Go über APIs und Eventing bis hin zu Observability und Cloud-Ressourcen in der Google Cloud Platform
  2. Freude am Wachsen: Die Fülle an Möglichkeiten ist kein Hindernis, sondern ein Antrieb

Für Backend-Entwicklerinnen und -Entwickler ist das eine Einladung, sich den eigenen Fokus zu suchen – und gleichzeitig über den Tellerrand zu schauen.

Tipps für Einsteiger: Mehr machen, weniger grübeln, offen bleiben

Der Blick zurück auf den eigenen Start führt zu klaren Ratschlägen:

  • Heute gibt es eine Fülle an Ressourcen (Google, Stack Overflow, YouTube). Das Problem ist weniger „wie“ als „wo anfangen?“ – und genau das ist eine Chance. Ausprobieren, vergleichen, den eigenen Bereich finden – Backend, Frontend, Spieleentwicklung – und loslegen.
  • „Es gibt wirklich keine formellen Bedürfnisse, anzufangen, zu entwickeln, ansonsten der Gemeinschaft und der Willen, Dinge auszuprobieren.“
  • Universität liefert Theorie – „Mathematik, Algorithmen und Ideen über die Konzepte von Softwarearchitektur“ – aber: Am Ende zählt Praxis. „Zu Hause auf dem PC sitzen und Dinge ausprobieren.“
  • Langfristig wichtig: Lernbereitschaft, Offenheit, zugeben können, etwas nicht zu wissen, und Zusammenarbeit.

Besonders bemerkenswert ist Kostas‘ Einordnung unterschiedlicher Hintergründe:

„Einige der besten Menschen, mit denen ich gearbeitet habe, kamen aus Bereichen wie orientalischen Studien. Sie machten vorher Arabisch und Sumerisch und dann sagten sie, sie möchten Programmieren. Und sie waren großartig.“

Seine Schlussfolgerung ist klar: Software lässt sich mit nahezu jeder anderen Wissenschaft kombinieren – Geologie, Biologie, Geschichte – „du nennst es“. Entscheidend ist das Mindset.

Konkrete Learnings für Entwicklerinnen und Entwickler

Was lässt sich aus dieser devstory unmittelbar in die tägliche Arbeit übertragen? Aus unserer Sicht sind es vor allem diese Handlungsprinzipien, die Kostas in seinem Werdegang vorlebt:

  • Den inneren „Detektiv“ kultivieren
  • Edge Cases sind normal, nicht die Ausnahme. Beobachten, Hypothesen bilden, systematisch eingrenzen.
  • Breites Systemwissen aufbauen: Datenflüsse, Zustände, Abhängigkeiten, Zertifizierungsgrenzen.
  • Architektur als Optionsmanagement verstehen
  • Änderungen dort ermöglichen, wo regulierte Teile unantastbar sind.
  • Workarounds planen, die Anforderungen respektieren und später in saubere Fixes überführen.
  • Polyglott arbeiten, aber fokussiert bauen
  • Go als Kernsprache – robust, performant – mit Java/TypeScript ergänzen, wo es passt.
  • Die Cloud (Google Cloud Platform) als Werkzeugkasten begreifen: Man nutzt nur, was nötig ist, aber kennt die Optionen.
  • Theorie schätzen, Praxis priorisieren
  • Modelle, Algorithmen, Architekturkonzepte – wichtig.
  • Doch Fortschritt entsteht am Keyboard: Prototypen, Messungen, Iterationen.
  • Lernen als Alltag institutionalisieren
  • „Ich konnte Dinge lernen“ – diese Motivation ist nicht episodisch, sondern kontinuierlich.
  • Reviews, Postmortems, Wissensaustausch – all das nährt die Detektivarbeit und verbessert Entscheidungen.
  • Offenheit als Superkraft
  • Fachfremde Perspektiven bereichern Teams.
  • Die Fähigkeit, nicht zu wissen, ist der Startpunkt für echte Zusammenarbeit.

Was wir aus der Session „Kostas Plakidas, Back End Developer bei fiskaly“ mitnehmen

Die Geschichte von Kostas Plakidas ist weniger ein linearer Karrierefahrplan als eine Haltung zum Entwickeln:

  • Starte mit Neugier und halte sie lebendig.
  • Nutze Theorie – aber lass sie von Praxis prüfen.
  • Baue Systeme so, dass du in realen Zwängen handlungsfähig bleibst.
  • Miss Edge Cases nicht als Störfall, sondern als Lernsignal.
  • Wähle Optionen, die heute helfen und morgen nicht im Weg stehen.

Dass diese Haltung in einem Feld wie der Fiskalisierung besonders gefragt ist, liegt auf der Hand: Zertifizierungen, strenge Anforderungen und reale Betrugsprävention zwingen zu Disziplin. Gleichzeitig eröffnet die Cloud einen eleganten, skalierbaren Weg – sofern man bereit ist, die daraus entstehende Komplexität anzunehmen.

Epilog: Der Spaß am Unerschöpflichen

Kostas‘ Bemerkung, er könne „drei, vier Jahre arbeiten, ohne die volle Größe der Optionen und Möglichkeiten zu überleben“, bringt die Freude am Fach auf den Punkt: Software ist kein abgeschlossenes Terrain. Wer lernen will, findet immer neue Winkel, in denen sich Praxis und Konzept berühren.

Für uns ist das die zentrale Botschaft dieser devstory mit Kostas Plakidas von der fiskaly GmbH: Wähle Umgebungen, in denen du wachsen musst – nicht kannst. Suche Probleme, die dich zwingen, genauer hinzusehen. Und pflege die Mischung aus Klarheit und Geduld, die es braucht, um Systeme zu bauen, die heute funktionieren und morgen noch gestaltbar sind.

„Es ist also immer eine Frage, die Optionen auf dem Tisch zu haben und sich dazwischen zu wählen … mit Blick auf das, was uns langfristig erlangen wird.“

Wer so denkt, macht nicht nur Karriere – er baut Software, die Bestand hat.

Weitere Tech Lead Stories

Weitere Dev Stories