From School Elective to Data Science: Julian Deleja-Hotko (enjoy IT) on Projects, Practice, and the Joy of Coding

A grounded developer journey that keeps things simple—and effective

In the session “Julian Deleja-Hotko, Software Developer bei enjoy IT,” we follow a concise yet insightful path: first code at school, a practical Bachelor’s degree, early work experience, and a next step into a Data Science master’s program. What stood out to us at DevJobs.at is Julian’s clarity. He turns experience into practical principles that anyone can apply.

His journey crystallizes into three straightforward messages:

• Start early and keep going: discover interest at school, deepen it through study, gain work experience, and continue learning.
• Think in projects, not task lists: set a concrete goal, figure out how to get there, and actually ship something.
• Joy matters: “Wenn es keinen Spaß macht, dann hat alles keinen Sinn.” If there’s no joy, it defeats the purpose.

Between those pillars lies a workable posture for modern software work: a clear end-to-end process, the courage to build and iterate, and the insight that durable learning is powered by genuine curiosity.

First steps: an Informatics elective, C# and Python at 16

Julian begins with a concrete starting point: “Ich habe … in der Schule … das Wahlpflichtfach Informatik … drei Jahre mit C-Sharp und Python … Da war ich so 16.” From this, three practical takeaways emerge:

1. Institutional entry points matter: A school elective can open the door. It doesn’t have to start with a hackathon; sometimes it’s simply the structure and continuity of a class.
2. Multi-year exposure compounds: Three years are enough to move from “Hello, World” to building things with intent—especially across two complementary languages: C# for strongly typed, object-oriented structure; Python for pragmatic scripting and prototyping.
3. Early sense of agency: “That really appealed to me.” Understated, yes, but often the decisive turning point: once you see your code producing tangible results, you’ve crossed from theory into craft.

To us, this is the first strong lesson: you don’t need much to get started—just a clear environment, beginner-friendly tools, and the chance to practice consistently. Confidence grows from that consistency.

Studying and working: Business Informatics as a bridge

“When it came to choosing a degree, I thought, that’s actually something—let’s continue. Then I started a Bachelor’s in Business Informatics and have finished it already.” That choice connects technology with real-world application. Business Informatics sits squarely between engineering and domain needs. It mirrors what Julian later says about software: begin by conceptualizing, clarify what the customer actually needs, implement, introduce, test, fix, and maintain. It’s a natural fit.

He also started working during his studies: “I began working alongside it to gain some professional experience.” That line says a lot about priorities: learn with a view to practice. Combining study and work sharpens relevance. Which lectures translate into projects? Where does theory diverge from production? You learn faster when you ask these questions early.

By the time of the session, the Bachelor is finished, and the Data Science master’s has just started. Continuity, then specialization—without detours. Each step sets up the next.

What software development entails: from concept to ongoing care

“Also wir entwickeln Software … Das fängt … mit konzeptualisieren … wie sollte es am Schluss ausschauen, was will der Kunde eigentlich. … Wie kann man das tatsächlich umsetzen. Dann setzt man es tatsächlich um. … Einführen. … Tests entwickelt, Tests durchgeführt. … Fehler … finden … lösen. … Laufend pflegen und laufend aktuell halten.”

In plain words, Julian maps the full product lifecycle. Here’s how we parse the flow he describes:

1) Conceptualize: clarify outcome and needs

• “What should it look like in the end?” A clear end picture prevents teams from building in the dark. It anchors scope discussions: which features matter now, and what can wait?
• “What does the customer actually want?” Without real need, software becomes an exercise in cleverness. Early stakeholder understanding is the bedrock of good engineering.

2) Plan the approach and implement

• “How can we actually implement this?” Between desire and delivery lie architecture, technology choices, data models, and integrations. Turning the what into the how is the essence of engineering.
• “Then you actually build it.” Delivery is code that is readable, testable, and maintainable—communication for your future self and your team, not just instructions for a compiler.

3) Introduce, test, and assure quality

• “You have to introduce it.” Introduction is more than deployment. It means taking users along, fitting the solution into real processes, and incorporating feedback.
• “Tests are developed and conducted.” Tests aren’t an afterthought. They formalize how the system should behave. Without tests, change is risk; with tests, change is controlled improvement.

4) Find and fix defects

• “Errors will occur … you have to find them … and fix them.” Bugs aren’t exceptions; they’re inevitable. The better you detect, prioritize, and resolve them, the more trustworthy your product becomes—while teaching you about your system and assumptions.

5) Maintain and keep it current

• “Continuously maintain and keep it up to date.” Software ages—dependencies, security, platforms. Maintenance is not overhead; it’s a core workstream. Make it explicit, and you stabilize development.

We appreciate the simplicity of this arc—concept, plan, implement, introduce, test, fix, maintain. It is broadly applicable regardless of methodology or toolchain, and therefore easy to embed in day-to-day practice.

How to learn effectively: projects over to-do lists

“It’s actually pretty irrelevant how you get into it—whether you study, do an apprenticeship, or teach yourself. What’s important, especially if you’re starting on your own, is to look for a concrete project. Don’t just copy tasks and tick off a list. Decide: this is what I want to build, this is what I want to achieve—then figure out how to do it and actually deliver something.”

That’s a direct critique of purely tutorial-driven development. Exercises and drills are useful to learn syntax and idioms, but learning becomes durable when tied to a goal you care about. Three reasons why project orientation works:

1. Context beats isolated knowledge: A concrete outcome forces you to connect language, frameworks, data, and deployment. That connective tissue is what teams rely on.
2. Real decision points: A project makes you weigh trade-offs. What’s must-have versus nice-to-have? Which dependencies do you really need? Those decisions shape your engineering judgment.
3. Outcomes motivate: “Actually deliver something.” Results are visible and usable—hence open to critique. Feedback drives improvement.

Our suggestion to newcomers, inspired by Julian’s stance: pick a project that interests you and that you’ll personally use. Write down what “done” looks like. Define what will be usable within two weeks. Stay flexible with tools if they get in your way—change them for the outcome, not for novelty.

Joy as a metric: take motivation seriously

“It doesn’t matter how you do it—but if it’s not fun, then it makes no sense.” Simple on the surface, this is an important prioritization. Joy isn’t a luxury; it’s an early-warning system. If the fun is chronically missing, something foundational is off: the goal, the environment, the collaboration, or the balance between ambition and capability.

Practically, this means the things you enjoy are often the ones worth deepening. Passion and persistence are linked. When learning is enjoyable, you tolerate setbacks, experiment more, and build deeper competence faster. In projects, this shows up as staying with a problem until it’s solved—and finding that extra bit of quality that makes a difference.

This doesn’t mean every day is easy. Julian explicitly mentions testing, fixing errors, and ongoing maintenance—phases that rarely feel glamorous. But those tasks need an inner motor. Without it, development becomes mechanical. With it, engineering remains craft and creation.

The throughline: continuity, relevance, and outcomes

If we overlay Julian’s milestones—school, a Bachelor in Business Informatics, early work experience, a new Master’s in Data Science—with his principles—projects, joy, and end-to-end responsibility—a clear throughline emerges:

• It starts with a real entry point (a school elective), crosses a bridge to application (Business Informatics), and becomes anchored in practice (work during studies).
• It develops into a specialization aligned with interest (Data Science), without losing the basics (software as an end-to-end process from concept to maintenance).
• It’s powered by a learning posture that is outcome-oriented (projects) and motivation-aware (joy).

It’s not flashy—and that’s the strength. It’s a pattern that others can adopt. Sustainable progress is less about big leaps and more about consistent steps.

Practical prompts for newcomers

Based on Julian’s points, here are concrete steps you can apply—whether you study, apprentice, or self-learn:

• Choose a project with personal utility: If you will use it yourself, you’re more likely to stick with it.
• Define a clear end picture: Write down what it should look like when done. A simple mockup is enough.
• Limit the first scope: What can be usable in two weeks? Everything else is a second iteration.
• Plan tests from day one: At least for the core functionality. Tests are your safety net.
• Actually introduce it: Share with others, collect feedback. A “release” is more than a local build.
• Track bugs and learn from them: Errors are normal. They teach you about assumptions and edges.
• Keep a small changelog: Record what changed and why. It improves accountability and quality.

These points mirror the process Julian outlines—translated into steps for your personal learning project.

For students: fold in work experience early

Julian started working during his studies “to gain professional experience.” If you’re studying, that’s a strong lever:

• Translate theory into practice: You quickly see what carries over now, not later.
• Sharpen learning direction: Practice shows what you should learn next—concretely, not abstractly.
• Build a portfolio: Early projects, even small ones, demonstrate that you can deliver—a crucial signal for entry-level roles.

Not everyone can invest many hours every week. Even short stints—during semester breaks, for example—raise your learning curve significantly.

Language choices: C# and Python as an early combination

Julian explicitly mentions C# and Python as his first languages. Without adding details beyond that, the pairing says a lot: structured, typed development on one hand; fast, flexible scripting on the other. Experiencing both early makes it easier to judge when problems call for rigor and when they call for speed—a balance you negotiate in every project.

For newcomers, that can serve as a guideline: learn one language that forces clean structure, and one that enables quick prototyping. It’s not either/or; it’s sharpening your tools for different jobs.

Data Science as a complementary next step

“I’ve finished the Bachelor and have just started a Master’s in Data Science.” Julian doesn’t add more detail—but the direction is clear: data skills expand the reach of software work. Data makes software measurable, personalizable, and adaptive. If you can both build systems and understand data, you can create impact in product functionality and in data-driven improvement.

Crucially, Data Science benefits from the same principles Julian highlights: project orientation, careful introduction, testing, a healthy bug-fixing culture, and ongoing maintenance. Data projects need that discipline just as much as classic application development.

Plain words, real leverage

What we appreciate most in Julian’s contribution is the reduction to essentials—no buzzwords, no shortcuts. From our perspective, three durable insights stand out:

• Product thinking beats tool-first thinking: “What does the customer actually want?” is the first question—not which framework to pick.
• Responsibility doesn’t end at commit: Introduction, testing, bug fixing, and maintenance are not “support”—they are software development.
• Motivation is a metric: “If it’s not fun, it makes no sense.” Joy indicates whether you’re on a path you can sustain long enough to master.

Quotable moments

To anchor the core points, here are the phrases—as Julian says them—that shaped our takeaways:

These aren’t a manual; they’re a compass. They help answer practical questions: What’s the next sensible step? How do we measure progress? How do we know we’re still on the right path?

Closing: A devstory that encourages focus and steady progress

“Julian Deleja-Hotko, Software Developer bei enjoy IT” is a short but pointed devstory: early school exposure, an application-oriented Bachelor in Business Informatics, hands-on work during studies, and a new Master’s in Data Science. Over that, a simple, robust approach to building software—from concept to maintenance.

For developers at any stage, the lessons are clear:

• Choose your entry path—study, apprenticeship, or self-learning—and keep going.
• Learn through projects, not endless exercises.
• Think about introduction, testing, bug fixing, and maintenance from day one.
• Use joy as your compass—it is the most reliable driver of sustained mastery.

From our DevJobs.at editorial vantage point, that’s the strength of this session: not shortcuts, but orientation. A reminder that good software work blends clarity, persistence, and curiosity—qualities you can cultivate, one step at a time.

• 

  

  Stefan Weinzettel, Bid Manager bei enjoy IT

  Stefan Weinzettel von enjoy IT berichtet im Interview über seinen Weg in das Bid Management, wie er in seiner Rolle im Unternehmen mit Developern zusammenarbeitet und gibt Tipps für Einsteiger.

  Watch now
• 

  

  Joachim Waldl, Front End Developer bei enjoy IT

  Joachim Waldl von enjoy IT gibt im Interview einen Einblick in seinen Werdegang zum Programmieren, einen Überblick in seine aktuelle Arbeit im Front End Development und schließlich Tipps für Beginner.

  Watch now
• 

  

  Thomas Hochgatterer, Back End Developer bei enjoy IT

  Thomas Hochgatterer von enjoy IT gibt im Interview Einblicke in seinen Werdegang mit dem Prorammieren, wie sich sein Arbeitsalltag als Back End Developer gestaltet und gibt Tipps für Neueinsteiger.

  Watch now
• 

  

  Christof Amtmann, Project Manager bei enjoy IT

  Christof Amtmann von enjoy IT spricht im Interview darüber, wie er über Umwege zum Project Management gekommen ist, was seine aktuelle Arbeit umfasst und gibt Tipps für Neueinsteiger.

  Watch now
• 

  

  Oktay Akgül, Lead Developer bei enjoy IT

  Oktay Akgül von enjoy IT erzählt im Interview wie er zum Programmieren gekommen ist, wie sich dann der Weg bis zu aktuellen Arbeit als Lead Developer gestaltet hat und gibt Tipps für Neueinsteiger.

  Watch now
• 

  

  Thomas Hintersteiner, Software Architect bei enjoy IT

  Thomas Hintersteiner von enjoy IT erzählt im Interview über seinen Weg – angefangen von der HTL bis hin zu seiner aktuellen Arbeit – und gibt Tipps für Personen die selbst mit dem Programmieren anfangen möchten.

  Watch now