Vom Clan-Forum zur Interaktionsschicht: Die Entwicklerreise von Boris Bosiljcic (Storyclash)

Ein DevJobs.at-Recap der Session „Boris Bosiljcic, Full Stack Developer bei Storyclash“

In der Session „Boris Bosiljcic, Full Stack Developer bei Storyclash“ zeichnet sich ein klarer roter Faden ab: echte Probleme lösen, Konzepte lernen, Neugier bewahren. Wir haben Boris zugehört und eine Entwicklergeschichte erlebt, die im Jugendzimmer beginnt und heute in einer Full-Stack-Rolle mündet, in der Datenvisualisierung, Produkt-Schnittstellen und Performance-Tuning aufeinandertreffen. Es ist eine Story, die ohne Buzzwords auskommt, weil sie durch Substanz, Pragmatismus und den Willen, Dinge wirklich zum Laufen zu bringen, überzeugt.

Boris’ Weg beginnt früh: mit 12 oder 13, beim Spielen und dem gemeinsamen Aufbau einer kleinen Online-Community mit Freund:innen. Daraus entsteht ein Bulletinboard, das er eigenständig betreut, erweitert und immer weiter in Richtung echter Use-Cases bringt – bis hin zu einer ersten selbstgebauten Lösung für Terminplanung mit rudimentärem PHP, viel Googeln und Trial-and-Error. Genau dort spürt er zum ersten Mal dieses sehr typische Entwicklergefühl: selbst ein Problem gelöst zu haben, das vorher niemand für einen gelöst hat. Später folgt weitere Praxis, unter anderem mit IRC-Boards – häufig in Python.

Heute arbeitet Boris als Fullstack Developer bei Storyclash. Sein Team baut die Interaktionsebene für Kund:innen: die Oberfläche, auf der Daten visualisiert, abgefragt und genutzt werden. Dabei arbeitet er eng mit den Bereichen Datenbanken und Datenakquise zusammen – und ebenso eng mit dem Produktteam, das Prototypen und Wireframes liefert, die er und sein Team dann in reale, benutzbare Features verwandeln. Was ihn daran besonders reizt: die Vielfalt – vom letzten Millisekündchen in einer SQL-Abfrage bis zur pixelgenauen Frontend-Komponente, wie sie sich der oder die Designer:in vorgestellt hat.

In diesem Recap halten wir fest, was wir von Boris’ Weg und seinen Aussagen mitnehmen – geradlinig, praxisnah und direkt auf den Entwickleralltag übertragbar.

Die ersten Schritte: Von der Community zum ersten eigenen Feature

Boris schildert seine Anfänge so, wie sie viele kennen: Er spielte Games, gründete mit Freund:innen einen „Clan“ und brauchte Infrastruktur, um sich zu organisieren. Es begann mit einem Bulletinboard, das er selbst betreute und mit Modulen erweiterte – unter anderem, um Informationen aus dem TeamSpeak-Server sichtbar zu machen. Eine Zeit, die von Neugier und Experimentierfreude geprägt war.

Als der Clan professioneller wurde und man Trainings und „Clan Wars“ planen musste, stieß die Standardsoftware an Grenzen. Der Wendepunkt: Es gab nichts Fertiges für die genaue Organisationslogik, die sie brauchten. Also nahm Boris ein vorhandenes Kalendermodul und „hackte“ es mit einfachem PHP dorthin, wo es einen echten Mehrwert lieferte.

Was in diesem Moment passiert, beschreibt er als grundlegendes Erfahrungsmuster: die Erkenntnis, aus eigener Kraft eine Lösung geschaffen zu haben, die es vorher nicht gab – und die verwendet wird. Dieses Gefühl prägt seine Sichtweise bis heute.

Im Anschluss baute er weiter an Tools und Skripten rund um Kommunikations- und Community-Infrastruktur, häufig in Python. Es sind genau diese kleinen, konkreten Projekte, die Konzepte andocken lassen: Datenflüsse verstehen, Schnittstellen verbinden, einfache Datenmodelle, erste Automatisierungen. Und vor allem: die Verbindung von „brauchen“ und „bauen“.

Heute bei Storyclash: Interaktionsschicht, Datenvisualisierung, Produktnähe

Boris beschreibt seine aktuelle Rolle als Fullstack Developer bei Storyclash präzise entlang der Aufgabe: Kund:innen auf einer Interaktionsebene Daten zu visualisieren und sie damit arbeiten zu lassen. Dieses „Interface zwischen Mensch und Daten“ ist der Ort, an dem Business- und Produktideen sichtbar und benutzbar werden.

Das impliziert mehrere Kooperationsachsen:

• Zusammenarbeit mit Teams rund um Datenbanken und Datenakquise: Daten müssen verlässlich, schnell und in geeigneter Form verfügbar sein.
• Enge Abstimmung mit dem Produktteam: Prototypen und Wireframes werden angeliefert; das Engineering-Team übersetzt sie in reale Komponenten und Features.

Diese Brückenfunktion ist typisch für Full-Stack-Arbeit: Anforderungen verstehen, Detaillösungen im Frontend entwickeln, Abhängigkeiten im Backend managen und Performance sowie UX im Blick behalten.

Abwechslung im Full-Stack-Alltag: Von Millisekunden bis Pixeln

Was Boris an seiner Arbeit besonders schätzt, ist die Vielfalt. Er zeichnet ein sehr klares Bild von zwei Polen, zwischen denen er täglich navigiert:

• Performance-Arbeit an SQL-Abfragen: Es geht um Latenzen im Millisekundenbereich, die über Qualität und Nutzbarkeit entscheiden.
• Frontend-Feinschliff: „Pixelgenau“ bedeutet, das vom Design intendierte Erlebnis präzise zu realisieren.

Aus unserer Sicht ist genau diese Spannweite essenziell für Produktteams, die datengetriebene Interfaces bauen: Anwender:innen brauchen verlässliche Geschwindigkeit und visuelle Klarheit – und sie vertrauen darauf, dass hinter der Oberfläche ein System performant arbeitet.

Herausforderung Breite: Wissen teilen, Stärken nutzen

Die Kehrseite der Vielfalt: Man muss in vielen Feldern gut genug sein, um fundierte Entscheidungen zu treffen und qualitativ zu liefern. Boris formuliert das als eine der „Schwierigkeiten“ des Jobs. Gleichzeitig liegt darin eine Teamstärke: individuelle Präferenzen werden zu Wissensquellen für alle.

Wir lesen darin eine pragmatische Form von Peer-Learning. Nicht als formalisiertes Programm, sondern eingebettet in die Arbeit: Wer in einem Bereich besonders tief drin ist, macht den Rest des Teams schneller – durch Empfehlungen, kritische Fragen, kurze Einführungen. Davon profitieren Codequalität, Tooling-Entscheidungen und die gemeinsame Sprache im Team.

Lernphilosophie: Echte Probleme vor Tutorials

In Boris’ Ratschlag an Einsteiger:innen steckt der Kern seiner eigenen Reise: Statt generischen Tutorials lieber an realen Problemen arbeiten. Das Ziel ist, etwas zu bauen, das wirklich verwendet wird – sei es von einem selbst oder vom eigenen Umfeld.

Er nennt Beispiele, die bewusst niedrigschwellig sind und dennoch echtes Lernen erzwingen:

• Eine Browser-Erweiterung, die YouTube-Links speichert.
• Eine Arduino-gesteuerte Lampe, die „Eintritt frei“ oder „Eintritt verboten“ signalisiert.

Der Clou: Die konkrete Technologie ist zweitrangig. Wichtiger sind die Konzepte, die man sich dabei erarbeitet. Diese lassen sich in andere Sprachen und Stacks übertragen.

Diese Haltung trägt auch durch technologische Wechsel: Viele Sprachen, viele Tools – und immer wieder der gleiche Rhythmus aus Einarbeiten, Best Practices finden, sich auf dem Laufenden halten.

Praxisnahe Leitlinien – was wir konkret mitnehmen

Aus Boris’ Aussagen lassen sich klare, anwendbare Leitlinien ableiten, ohne das Gesagte zu überdehnen:

1. Starte mit einem echten Use-Case.

• Suche dir ein Problem, das dich stört oder das in deinem Umfeld existiert. Baue etwas, das du danach wirklich benutzt.

1. Lerne Konzepte, nicht nur Syntax.

• Datenstrukturen, Zustandsmanagement, Schnittstellen, Performance – dieses Wissen überlebt einzelne Tools und Sprachen.

1. Ertrage die Lernkurve – Trial-and-Error ist Teil des Wegs.

• Googeln, ausprobieren, scheitern, anpassen: Genau so entsteht funktionierende Software.

1. Verbinde Backend-Performance und Frontend-Präzision.

• Millisekunden in SQLs sind genauso wichtig wie „pixelgenau“ im UI – Nutzer:innen spüren beides.

1. Pflege Teamwissen über Vorlieben.

• Lass diejenigen, die für einen Bereich brennen, den Rest mitziehen – Empfehlungen und kurze Demos skalieren das Team.

1. Arbeite produktnah.

• Prototypen und Wireframes sind nur der Anfang; die eigentliche Leistung entsteht in der Umsetzung zur robusten Funktion.

1. Halte die Tool-Diskussion pragmatisch.

• Technologien sind Mittel zum Zweck. Entscheidend ist, was du mit ihnen lernst und baust.

1. Bleib am Ball: Best Practices, Podcasts, Blogs.

• Kontinuierliches Lernen ist keine Option, sondern Notwendigkeit – und heute besser zugänglich denn je.

Wie sich diese Prinzipien im Alltag greifen lassen

Wir haben Boris’ Erfahrungen auf ein paar typische Entwicklungssituationen gemappt – nicht als zusätzliche Aussagen, sondern als Ableitungen davon, wie „echte Probleme zuerst“ praktisch aussehen kann:

• Nebenprojekt mit unmittelbarem Nutzen: Baue eine kleine Automatisierung oder Visualisierung, die dir täglich hilft (z. B. Links, Notizen, Erinnerungen). Entscheidend ist, dass du sie wirklich benutzt und dadurch Schwachstellen entdeckst.
• Performance im Blick behalten: Wenn ein Feature gut aussieht, aber langsam reagiert, lohnt sich es, Abfragen zu prüfen. Denk in Millisekunden – nicht aus Perfektionismus, sondern aus Respekt vor der Zeit der Nutzer:innen.
• Design ernst nehmen: „Pixelgenau“ ist kein Selbstzweck, sondern Ausdruck davon, dass du die Visualisierungssprache des Produkts respektierst. Nimm das Design als Spezifikation ernst.
• Wissensaustausch entkoppelt von Formalität: Statt immer nur formale Knowledge-Sharing-Sessions zu planen, reichen oft kurze, situative Erklärungen – „Schau, so lösen wir das jetzt – deshalb“.
• Konzepte in den Vordergrund: Egal ob du eine Datenquelle anzapfst, eine UI-Komponente baust oder eine Abfrage optimierst – formuliere für dich selbst, welches Konzept dahintersteckt. Dieses mentale Modell ist später übertragbar.

Zitate, die hängen bleiben

Einige Aussagen von Boris sind prägnant genug, um sie als Arbeitsmotto mitzunehmen:

Sie beschreiben eine Lernbewegung, die nicht aufhört: von der ersten PHP-Bastelei über Python-Skripte bis zur heutigen Interaktionsschicht mit Datenvisualisierung – immer mit demselben inneren Kompass.

Full-Stack als Brückenarbeit

Wenn wir Boris’ Beschreibung seiner Rolle zusammenziehen, ergibt sich ein Bild von Full-Stack-Entwicklung als Brückenarbeit:

• Brücke zwischen Daten und Nutzer:innen: Datenvisualisierung und Interaktionsdesign verbinden.
• Brücke zwischen Produkt und Technik: Prototypen/Wireframes in lauffähige, belastbare Features überführen.
• Brücke zwischen Teamdisziplinen: Datenakquise, Datenbanken, Frontend- und Backend-Engineering zusammenführen.
• Brücke zwischen Tempo und Qualität: Geschwindigkeit optimieren und gleichzeitig Designabsicht präzise umsetzen.

Diese Brückenarbeit funktioniert, wenn man die richtigen Fragen stellt: Wofür wird das Feature gebraucht? Welche Daten fließen wann wohin? Wo liegen die Latenzen? Was sieht der Mensch? Und was davon ist wirklich kritisch? Aus Boris’ Praxisbeispielen spricht genau diese Haltung.

Ein Weg, der für viele offensteht

Bemerkenswert an der Geschichte ist, wie zugänglich der Einstieg ist. Ohne große Vorlaufzeit, aber mit echtem Bedarf – Community, Spiele, Kommunikation – entsteht ein Raum, in dem „bauen“ naheliegend ist. Daraus ergibt sich eine Lernspirale: etwas Nützliches erstellen, direktes Feedback bekommen, verbessern, Konzepte verinnerlichen, Neues dazulernen. Diese Schleife gilt auch heute noch – und sie ist kompatibel mit jedem Tech-Stack.

Die Beispiele, die Boris nennt (Browser-Erweiterung, einfache Hardware-Anwendung), sind bewusst niedrigschwellig. Sie öffnen Türen, statt Hürden aufzubauen. Genau deshalb funktionieren sie als Lernvehikel.

Fazit: Was die Session für Entwickler:innen bedeutet

Die Session „Boris Bosiljcic, Full Stack Developer bei Storyclash“ verdichtet in wenigen klaren Aussagen, was nachhaltiges Entwickeln ausmacht:

• Lerne an echten Problemen – nicht an künstlichen Aufgabenstellungen.
• Verinnerliche Konzepte – sie tragen über Tools und Sprachen hinweg.
• Balanciere Performance und Präzision – Millisekunden und Pixel zählen.
• Baue Brücken – zwischen Produkt, Daten und Design.
• Teile Wissen – Vorlieben im Team sind ein Hebel für bessere Entscheidungen.
• Bleib neugierig – Best Practices, Podcasts und Blogs sind dein Brennstoff.

Für uns bei DevJobs.at ist das die Art von Entwicklergeschichte, die motiviert, weil sie realistisch ist: kein Shortcut, keine Abkürzung, kein Mythos. Stattdessen das, was gute Softwareteams täglich tun – Probleme identifizieren, sie in funktionsfähige Lösungen übersetzen und dabei voneinander lernen.

Boris’ Weg vom Clan-Forum zum Full-Stack bei Storyclash zeigt, wie weit man kommt, wenn man die richtigen Fragen stellt und konsequent baut. Und er erinnert daran, dass der wichtigste Schritt oft der erste ist: ein Problem zu wählen, das es wirklich wert ist, gelöst zu werden.

• 

  

  Ismail Hanli, Head of Data Acquisition bei Storyclash

  Head of Data Acquisition von Storyclash Ismail Hanli gibt im Interview Einblicke in die verschiedenen Devteams mit deren Technologien und was neue Bewerbungen im Unternehmen erwartet.

  Jetzt ansehen

• 

  

  Ismail Hanli, Back End Developer bei Storyclash

  Ismail Hanli von Storyclash spricht im Interview über seine Anfänge im Programmieren, was seine Aufgaben im Back End Team umfassen und gibt Empfehlungen für Einsteiger.

  Jetzt ansehen