From Flea-Market PC to Data-First Back End: Ismail Hanli (Storyclash) on Curiosity, Code, and the Most Practical Advice for Developers

A concise session with a clear throughline

In the session “Ismail Hanli, Back End Developer bei Storyclash” (Speaker: Ismail Hanli, Company: Storyclash), a direct narrative emerges: early curiosity, steady follow-through, and a deliberate focus on “only data, only code.” The story is familiar—an early start, HTML in school, a memorable puzzle with number systems—yet striking for its consistency. Hanli’s message to aspiring developers is disarmingly simple and powerful: just start, pick a project that matters to you, make mistakes, and let experience do its work.

The spark: a Pentium II from a flea market and an HTML class at school

Sometimes a career starts with a modest artifact. For Hanli, it was a PC bought at a flea market—“a Pentium 2.” He connects that moment to an early structured learning experience: an informatics class in middle school that introduced HTML. The point is not nostalgia but clarity of origin: between ages 10 and 12, he says, it began—and programming has held him ever since.

That combination of accessibility (an affordable machine), structure (a class), and curiosity (trying HTML) becomes a thread through the rest of his story. It shows how low the barrier to entry can be—and how lasting the impact when you stick with it.

Curiosity as a motor: turning hex numbers into shapes

One moment stands out: figuring out “how hex numbers are converted into shapes.” Many of us know that feeling—the first encounter with a problem that sounds abstract but yields to persistence and play. For Hanli, that unlock was a proof point: he could figure it out, others were genuinely excited, and that momentum carried him deeper into programming.

This isn’t just a story beat; it’s a posture. Demystify problems, connect the pieces, and stay with a question until it clicks. For back-end work—where visible interfaces are rare and structural clarity is everything—this mindset pays off.

Today: Back End Developer at Storyclash—“only data, only code”

Hanli works on the Back End team at Storyclash. He describes the work plainly: “We work a lot with data. It’s a dry topic for most people, but it’s exactly my thing.” The image he paints is unambiguously code-centered. No Excel, no constantly present visual interface—just direct interaction with data structures, processing steps, and program logic.

This focus reveals what back end means for him: not “invisible,” but “precise.” Where information is created, merged, and prepared, quality execution and a reliable pipeline matter—along with the kind of interface that lets the frontend do its job.

What “only data, only code” looks like in practice

Hanli doesn’t dive into tools, but he does draw a clear frame: his team aggregates data and performs post-processing—those processing steps that make data usable and analyzable. The goal is to deliver results the frontend can run with so customers see real insights. That tension—deep code focus vs. visible impact downstream—defines the back-end day-to-day.

Anyone working in back end will recognize the classic challenges here: securing data quality, reliably orchestrating processing steps, considering performance, and shaping the interface to let frontend and product teams plug in efficiently. In Hanli’s description there’s an almost refreshing clarity: this isn’t a tools beauty pageant—it’s work on substance. Data in, logic in between, data out.

Data preparation as customer value: aggregation and post-processing

Aggregation and post-processing aren’t just technical terms. In Hanli’s telling, they’re the bridge from raw input to the questions customers actually care about. If you promise insights, you must structure, clean, summarize, and relate raw data. Only then can the frontend visualize in a way that makes sense—and only then does value emerge.

Seen this way, Hanli’s path is remarkably consistent: from early enjoyment in numbers and shapes to daily work with structured processing. The continuity is not about a favorite framework; it’s about a stance on problems—organize things until they take on a clear, workable form.

Why “dry” can be exactly right

People who work with data know the reputation of “dryness.” Hanli calls it out himself but doesn’t treat it as a flaw—instead, as a matter of personal fit. In a climate that often celebrates visible UI, his perspective reminds us: the allure can be in the invisible. With data work, accuracy and downstream effect come first.

That is a powerful cue for developers seeking their place: examine what truly attracts you. Do you enjoy shaping interfaces—or are you drawn to the flows, formats, and processes that make everything stable? Hanli’s path shows how fulfilling a role can be when it aligns with your curiosity.

The most important advice: just start

Hanli’s guidance to newcomers and career changers is pragmatic, encouraging, and notably unglamorous—precisely why it works.

There’s no shortcut here, but there is a path: pick a project, begin, make mistakes, let experience work. The repeated emphasis on “just start” fits the overall story—it’s grounded and consistent.

Turning “just start” into practical steps

Hanli’s advice is clear. From our DevJobs.at editorial vantage point, a few concrete moves can make that advice easier to apply—without promising more than the session conveyed.

• Choose a small, personal project: something that keeps your interest beyond a weekend. Personal relevance supports persistence.
• Limit scope: A clear boundary makes progress visible. If the goal is too big, define the smallest working version first.
• Use free online materials: As Hanli notes, resources on languages and frameworks are abundant. Pick one that fits your learning style and stick with it for a while.
• Treat mistakes as feedback: “Making mistakes” is part of the point. Use them as signals, not verdicts on your potential.
• Keep a learning log: Capture what you tried, what failed, and why. This turns experience into conscious knowledge.
• Reduce friction: Set up an environment that supports fast iteration—short build cycles, simple test data, and scripts for recurring tasks.
• Close the loop to “why”: Regularly ask what value your project creates. That ties back to what Hanli describes—post-processing in service of real customer insights.

These aren’t rigid rules. They echo the stance Hanli models: begin, focus, learn.

Learning through mistakes and experience

Hanli underscores the value of experience. With each pass—whether decoding hex numbers or establishing a data flow—understanding deepens. This is where the tricky question “What can you do, what shouldn’t you do?” finds practical answers. Experience resolves it over time, not theoretically, but through repeated encounters with edge cases, bottlenecks, and false assumptions.

For anyone entering the back end, that’s a crucial signal: best practices are useful, but experience translates them into judgment. You learn where to flex them, where to harden them, and when to break them on purpose.

For aspiring back-end developers: orientation drawn from Hanli’s path

What Hanli shares suggests several orientation points—not a checklist of his tools, but thematic rails for your own development:

• Data orientation: enjoyment of structured thinking, numeric representations, and formats. The early “hex numbers” moment captures that impulse.
• Code-centeredness: willingness to work with abstractions without constant visual payoff. “Only data, only code” is a clear marker.
• Processing mindset: aggregation and post-processing as a basic pattern—prepare data so the frontend can attach and customers can gain real insights.
• Precision over show: joy in the “dry” means detail work and robustness take precedence.
• Learning stance: “just start,” iterate, accept mistakes, derive what works and what doesn’t from experience.

If these resonate with you, Hanli’s path illustrates how coherent a back-end role can be—especially if you define your work not by what’s visible, but by the chain of impact from raw data to insight.

What teams can take from Hanli’s code-first focus

Hanli’s description also suggests useful lessons for teams. If you take the back end seriously, you protect developers’ ability to work directly with data and code—without unnecessary intermediaries. In practice, that implies:

• Clean interfaces between back end and frontend: Prepared data should be “frontend-ready,” enabling customers to see insights—just as Hanli outlines.
• Clear ownership: Aggregation and post-processing need accountable stewardship—not fuzzy handoffs that dilute responsibility.
• Respect for “invisible” work: The absence of a UI sheen doesn’t mean the absence of value. On the contrary—the foundation is built here.
• Invested learning paths: Institutionalizing “just start”—through internal projects, learning time, or pairing—turns Hanli’s advice into a team practice.

Again: no tool parade. The core is a posture that gives structure to the work. The results show up when data flows run reliably and insights consistently land at the frontend.

Lines that stick

A few lines from Hanli’s session carry well because they distill the essentials:

• “Since then I’ve basically never let go of programming.” — Continuity over hype.
• “Only data, only code all day.” — Concentration on what matters in back end.
• “You won’t even see an Excel sheet.” — A clear boundary that creates focus.
• “Aggregate and do post-processing as preparation for our frontend data.” — The bridge to product value.
• “Just start … make mistakes … experience wins out.” — A three-step learning stance.

These aren’t slogans; they’re working principles. And they’re accessible—to beginners, career changers, and teams alike.

Conclusion: curiosity, clarity, consistency

The session “Ismail Hanli, Back End Developer bei Storyclash” is brief but tells a straight story: an early start, a formative unlock, a role that is deliberately centered on data and code, and a piece of advice that works as both accelerator and compass: start.

Here’s what we’re taking away:

• Begin where your curiosity is strongest—it’s resilient and lasts.
• Find your fit—what’s “dry” to some can be exactly right for you.
• Think in chains of impact—from raw data to insight.
• Turn mistakes into learning—experience doesn’t grow in a textbook.
• Keep it simple—and get going.

Ismail Hanli (Storyclash) shows how a straight path through tech can emerge when curiosity pulls and experience supports. For anyone who feels at home in back end and data—or wants to get there—this is an invitation to take the first step today.

• 

  

  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.

  Watch now

• 

  

  Boris Bosiljcic, Full Stack Developer bei Storyclash

  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.

  Watch now