Storyclash
Boris Bosiljcic, Full Stack Developer bei Storyclash
Description
Boris Bosiljcic von Storyclash erzählt im Interview darüber, wie er über ein Hobby Projekt zu seinem aktuellen Beruf gekommen ist und gibt Tipps für Anfänger.
By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.
Video Summary
In “Boris Bosiljcic, Full Stack Developer bei Storyclash,” speaker Boris Bosiljcic recounts starting as a teenager through a gaming clan—setting up a bulletin board and hacking a PHP calendar for clan wars and trainings—then moving to early IRC work in Python that gave him his first sense of creating original solutions. At Storyclash he builds the customer interaction layer, collaborates with data and product teams, and shifts from SQL performance tuning to pixel‑perfect frontend components within a culture of sharing strengths. His advice: tackle real problems instead of tutorials, build something useful, focus on transferable concepts over languages, and stay current via best practices, podcasts, and blogs.
From Clan Forums to the Interaction Layer: The Developer Journey of Boris Bosiljcic (Storyclash)
A DevJobs.at editorial recap of “Boris Bosiljcic, Full Stack Developer bei Storyclash”
“Boris Bosiljcic, Full Stack Developer bei Storyclash” is a story about solving real problems, learning core concepts, and staying curious. Listening to Boris, we followed a trajectory that starts in a teenager’s room and leads to a full-stack role where data visualization, product collaboration, and performance tuning meet. It’s a practical, no-frills path powered by curiosity and the drive to make things actually work.
Boris started early—around 12 or 13—playing games and building a small online community with friends. That turned into setting up and maintaining a bulletin board and extending it with modules, including integrations to surface who was on their TeamSpeak server. Eventually, organizational needs outgrew the default software. Planning trainings and “Clan Wars” required something that didn’t exist out of the box. So he took a calendar module and, using rudimentary PHP, a lot of Googling, and plenty of trial and error, hacked it into something they could really use. That was the moment he felt the distinctive developer accomplishment: shipping a solution to a problem no one had solved for him before. He’s still proud of it. Later came more tooling for IRC boards—often in Python.
Today, Boris works as a full-stack developer at Storyclash. His team builds the customer interaction layer: the place where data is visualized, queried, and put to work. He collaborates closely with database and data acquisition teams, and just as closely with the product team, which delivers prototypes and wireframes that engineering turns into real, shippable features. What he enjoys most is the variety—one day squeezing the last milliseconds out of an SQL query, the next day crafting view components in the frontend to match the designer’s intent, pixel by pixel.
This recap captures what we learned from Boris—plain, actionable, and grounded in developer reality.
Getting started: From community needs to the first real feature
Boris’ origin story will resonate with many developers. He played games, started a “clan” with friends, and needed infrastructure to organize everything. It began with a bulletin board he maintained and augmented with modules—like showing who was on their TeamSpeak server. It was a time fueled by curiosity and experimentation.
“We decided to set up a bulletin board, and I maintained it and kept installing modules… to, for example, show the people on our TeamSpeak server…”
When the clan got more serious and planning trainings and “Clan Wars” became essential, the default software hit a wall. The turning point: there was no off-the-shelf solution for their exact coordination needs. So Boris took a calendar module and pushed it further with simple PHP.
“…with the most rudimentary PHP I tried to hack it together, with a lot of Googling and a lot of trial and error…”
He describes the feeling as formative: realizing he had built something that solved a problem no one had solved for him—a sense of accomplishment that still matters to him today.
“…that was the first time I created something where no one had solved the problem for me beforehand… I’m still proud of it.”
He continued building tools for IRC boards, often in Python. These small, concrete projects are where concepts stick: understanding data flows, connecting systems, thinking about basic data models and simple automations. Most importantly, they link “needing” to “building.”
Full stack at Storyclash: Interaction layer, data visualization, product alignment
Boris defines his current role at Storyclash precisely by its purpose: delivering the interaction layer on which customers visualize data, query it, and do their work.
“We develop our tool, which is the interaction layer for our customers—in other words, we visualize the data that our customers then query and work with.”
This means coordinating on multiple axes:
- Working with teams focused on databases and data acquisition: data must be reliable, fast, and shaped for the product’s needs.
- Working closely with the product team: prototypes and wireframes come in; engineering turns them into real components and features.
“The product team develops prototypes and wireframes, and we then implement them.”
This is classic full-stack bridge work: turning requirements into concrete UI, managing backend dependencies, and staying mindful of both performance and UX.
The daily mix: Milliseconds and pixels
What Boris values most is the variety. He paints a vivid contrast between two typical poles of his day-to-day:
“You might spend a day writing SQLs, trying to squeeze the last milliseconds out of a source; the next day you do something completely different—write view components in the frontend and make sure they are pixel perfect, just as the designer envisioned.”
- Performance on SQL queries: shaving milliseconds makes a real difference to quality and usability.
- Frontend precision: “Pixel-perfect” means delivering the designer’s intended experience without compromise.
For teams building data-driven interfaces, this dual focus is essential. Users need speed and visual clarity, and they trust that behind the surface sits a system that performs.
The challenge of breadth: Share strengths, lift the team
The flip side of variety is the need to be competent across a wide spectrum. Boris names that as one of the difficulties of the job. At the same time, it’s a team advantage: individual preferences become shared expertise.
“Of course, everyone has preferences, but I think that’s where we can score. The person with those preferences often explains to others what the latest and greatest is and what should be used.”
We see this as organic peer learning—embedded in the work rather than formalized as a program. Whoever goes deep in a particular area lifts the rest of the team through recommendations, clarifying questions, and quick introductions. The benefits are clear: better code quality, better tooling choices, and a shared vocabulary.
Learning philosophy: Real problems over generic tutorials
Boris’ advice to newcomers mirrors his own trajectory: start with a real problem, not a contrived tutorial. Build something you’ll actually use.
“I would look for a problem that’s a real problem… I wouldn’t start with some stupid tutorial doing the thousandth to-do list, but something you can use afterwards.”
His examples are intentionally accessible yet force meaningful learning:
- A Chrome extension that saves YouTube links.
- An Arduino-controlled lamp that signals “entry allowed” or “entry forbidden.”
The key: the specific technology is secondary. What matters are the concepts you internalize, which transfer across languages and stacks.
“It’s important to learn the concepts and teach them to yourself. They’re transferable to any programming language.”
This attitude carries through technology shifts. Boris mentions he has worked with several languages in his life, and when something new appears, you simply learn it—supported by best practices, podcasts, and blogs.
“…when something new comes out, you have to teach it to yourself anyway, and there are best practices, podcasts, blogs…”
Practical takeaways we’re bringing back to the team
We can distill Boris’ points into concrete, developer-ready guidance without adding anything he didn’t imply:
- Start with an authentic use case.
- Pick a problem in your real life or team. Build something you will actually use.
- Learn concepts, not just syntax.
- Data modeling, state management, interfaces, performance—these outlast specific tools and languages.
- Expect a learning curve—trial and error is normal.
- You’ll Google, try, fail, and refine. That’s how working software is made.
- Balance performance and precision.
- Milliseconds in SQL and pixel-perfect UI both matter—to the user and to the product.
- Leverage team preferences.
- Let those with a strong preference in an area guide others. It accelerates decisions and improves quality.
- Work close to product.
- Prototypes and wireframes are starting points; the real value is in turning them into robust features.
- Keep tool debates pragmatic.
- Technology is a means. What you learn and ship with it is what counts.
- Keep learning: best practices, podcasts, blogs.
- Continuous learning isn’t optional; it’s how you stay effective.
How these principles play out day to day
Mapping Boris’ insights to typical developer situations shows how “real problems first” translates into action:
- Build a small, useful side tool: An automation or visualization you’ll touch every day (for links, notes, reminders). Regular use will reveal what actually matters—and what to fix next.
- Keep an eye on performance: If a feature looks good but feels slow, check your queries. Think in milliseconds—not as a perfectionist tick, but out of respect for your users’ time.
- Treat design as specification: Pixel-perfect isn’t vanity; it’s honoring the product’s visual language and intent.
- Share knowledge informally: You don’t always need formal sessions. Quick, contextual explanations—“Here’s how we solve this, and why”—can scale team expertise.
- Surface the concept behind the change: Whether wiring a data source, crafting a UI component, or tuning a query, articulate the underlying concept to yourself. That mental model transfers.
Quotable moments
Some lines from Boris are sticky enough to serve as day-to-day mottos:
“…the first time I created something where no one had solved the problem for me beforehand…”
“I would look for a problem that’s a real problem…”
“It’s important to learn the concepts…”
“…there are best practices, podcasts, blogs…”
Together they outline a learning pattern that never ends—from early PHP tinkering and Python work around IRC boards to today’s interaction layer and data visualization—guided by the same internal compass.
Full stack as bridge work
Taken together, Boris’ role reads as a set of bridges:
- Bridge between data and people: visualize data and shape interaction.
- Bridge between product and engineering: turn prototypes/wireframes into working, resilient features.
- Bridge across disciplines: connect data acquisition, databases, frontend, and backend concerns.
- Bridge between speed and polish: optimize latency and deliver design intent faithfully.
These bridges hold when you ask the right questions: What is the feature for? What data flows where and when? Where are the latencies? What does the user actually see? And which of these is critical? From Boris’ examples, that mindset clearly underpins his work.
A path open to many
What stands out is how accessible the entry point can be. With minimal upfront formality but a real need—community, games, communication—you get a context where “build it” becomes the obvious next step. From there, a learning loop takes over: create something useful, get direct feedback, improve, internalize concepts, add new tools. This loop still works today—and it’s compatible with any stack.
The examples Boris mentions (a browser extension, a simple hardware signal) are deliberately low-friction. They open doors rather than raise hurdles. That’s why they make great learning vehicles.
Conclusion: What this session gives developers
The session “Boris Bosiljcic, Full Stack Developer bei Storyclash” distills a few core habits that make developer growth sustainable:
- Learn by tackling real problems, not artificial exercises.
- Internalize concepts; they outlive tools and languages.
- Balance performance and polish—milliseconds and pixels both matter.
- Build bridges—across product, data, and design.
- Share what you prefer and know—let it lift the team.
- Keep the engine running with best practices, podcasts, and blogs.
For us at DevJobs.at, this is the kind of developer story that motivates because it’s grounded: no shortcuts, no myths. Just the daily craft of identifying problems, translating them into working software, and learning from each other along the way.
Boris’ journey—from a clan forum to full stack at Storyclash—shows how far you can get by asking the right questions and building consistently. And it underscores that the most important step is often the first: choosing a problem worth solving.
