Arbeitsplatz Bild enjoy IT GmbH

Julian Deleja-Hotko, Software Developer bei enjoy IT

Description

Julian Deleja-Hotko von enjoy IT redet im Interview über seine Anfänge mit dem Programmieren, was er in seiner aktuellen Arbeit macht und was seiner Meinung nach für Neueinsteiger wichtig ist.

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

Video Zusammenfassung

In "Julian Deleja-Hotko, Software Developer bei enjoy IT" schildert Speaker Julian Deleja-Hotko seinen Weg vom Schulwahlpflichtfach Informatik (C# und Python) über den Bachelor in Wirtschaftsinformatik und erste Berufserfahrung bis zum aktuellen Master in Data Science. Bei enjoy IT GmbH beschreibt er den kompletten Software-Lifecycle vom Konzept über Implementierung, Testen und Fehlerbehebung bis zur Einführung und laufenden Pflege. Sein Rat: Der Einstieg kann über Studium, Lehre oder autodidaktisch erfolgen – entscheidend sind ein konkretes Projekt, sichtbare Ergebnisse und Freude am Tun.

Vom Wahlpflichtfach zur Data Science: Julian Deleja-Hotko (enjoy IT) über Projekte, Praxis und die Freude am Programmieren

Ein klarer, bodenständiger Karrierepfad – und warum er funktioniert

In der Session „Julian Deleja-Hotko, Software Developer bei enjoy IT“ begleitet uns der Entwickler durch eine kompakte, aber aufschlussreiche Reise: von den ersten Zeilen Code in der Schule über das Bachelorstudium und die ersten Berufsjahre bis zum Masterstart in Data Science. Was uns bei DevJobs.at besonders aufgefallen ist: Julians Weg ist geradlinig, praxisnah und konsequent – und er verdichtet seine Erfahrungen zu einfachen, umsetzbaren Prinzipien.

Seine Quintessenz lässt sich in drei Leitsätze fassen:

  • Früh beginnen und dranbleiben: Interesse in der Schule entdecken, im Studium vertiefen, parallel Berufserfahrung sammeln, und anschließend weiterlernen.
  • In Projekten denken statt Aufgabenlisten abzuarbeiten: „Dass man sich wirklich etwas überlegt: Das will ich machen, das will ich erreichen … und tatsächlich was außerbringt.“
  • Freude als Kompass: „Wenn es keinen Spaß macht, dann hat alles keinen Sinn.“

Zwischen diesen drei Leitplanken entfaltet sich eine Haltung zur Softwareentwicklung, die vieles zusammenbringt, was Entwicklerinnen und Entwickler im Alltag beschäftigt: ein klares Vorgehen im Projekt, der Mut zum Tun, und die Einsicht, dass nachhaltiges Lernen vor allem dann gelingt, wenn es von echter Neugier getragen ist.

Die ersten Schritte: Wahlpflichtfach Informatik, C# und Python

Julian beginnt konkret: „Ich habe zum ersten Mal zum Programmieren angefangen in der Schule, da hat es das Wahlpflichtfach Informatik gegeben … Das habe ich dann drei Jahre mit C-Sharp und Python programmiert. Da war ich so 16.“ Drei Aspekte stechen heraus:

  1. Institutioneller Einstieg: Ein Schulwahlfach als Türöffner. Es zeigt, wie wichtig niederschwellige Zugänge sind – nicht jeder fängt mit einem Hackathon an; manchmal reicht ein Stundenplan mit Platz für Experimente.
  2. Mehrjährige Kontinuität: Drei Jahre sind genug Zeit, um vom reinen „Hello, World“ in ein produktiveres Mindset zu wachsen – besonders in zwei Sprachen, die sich gut ergänzen: C# als stark typisierte, objektorientierte Sprache; Python als pragmatisches Werkzeug für Skripting, Prototyping und Datenarbeit.
  3. Frühe Selbstwirksamkeit: „Das hat mir eigentlich recht gefallen.“ Hinter dieser Understatement-Formulierung steckt oft der entscheidende Kippmoment: Wer mit 16 merkt, dass Programmieren nicht nur Theorie ist, sondern greifbare Ergebnisse erzeugt, hat sein Fundament gelegt.

Für uns ist das die erste zentrale Beobachtung: Es braucht nicht viel – nur ein klar umrissenes Umfeld, einfache Werkzeuge und die Chance, über mehrere Jahre hinweg in die Praxis zu finden. Aus dieser Beständigkeit wächst Selbstvertrauen.

Studienwahl und Arbeitsstart: Wirtschaftsinformatik als Brücke

„Als es dann um die Studiumswahl ging, habe ich mir dann gedacht, das war eigentlich schon etwas, machen wir weiter. Dann habe ich ein Bachelorstudium in Wirtschaftsinformatik angefangen und abgeschlossen inzwischen auch schon.“ Hier sehen wir die bewusste Verbindung von Technik und Anwendung. Wirtschaftsinformatik ist keine reine Informatik, aber auch kein reiner Businesszweig – sie ist die Brücke. Sie passt zu dem, was Julian später über Softwareentwicklung sagt: am Anfang konzeptualisieren, verstehen, was der Kunde will, und das Ergebnis in reale Abläufe einführen. Genau dafür ist Wirtschaftsinformatik prädestiniert.

Parallel beginnt er zu arbeiten: „Ich habe dann währenddessen zum Arbeiten angefangen, damit ich auch ein bisschen Berufserfahrung sammeln kann.“ Ein Satz, der viel über Prioritäten aussagt: Lernen, ja – aber mit Blick auf den Einsatz in der Praxis. Die Kombination aus Studium und Job schärft den Sinn für Relevanz: Welche Inhalte aus Vorlesungen tragen in Projekten? Wo klaffen Lücken zwischen Theorie und Alltag? Wer diese Fragen früh stellt, lernt gezielter.

Zum Zeitpunkt des Gesprächs ist der Bachelor abgeschlossen, der Master in Data Science gerade gestartet. Kontinuität und Weiterentwicklung in einem: vom allgemeinen Einstieg über die anwendungsnahe Brücke zur Spezialisierung in Daten. Es ist kein Zickzackkurs, sondern ein Weg, auf dem jeder Schritt den nächsten vorbereitet.

Was Softwareentwicklung ausmacht: Vom Konzept bis zur laufenden Pflege

„Also wir entwickeln Software, wie der Name schon sagt. Das fängt ganz am Anfang an. Wir konzeptualisieren einmal, wie wollen wir das machen, wie sollte es am Schluss ausschauen, was will der Kunde eigentlich. Dann überlegt man sich, wie kann man das tatsächlich umsetzen. Dann setzt man es tatsächlich um. Man muss dann natürlich das Ganze auch noch pflegen, man muss das Ganze einführen. Es können dann auch Tests entwickelt, Tests durchgeführt. Dann werden natürlich Fehler aufkommen, die muss man auch finden, die muss man dann auch wieder lösen. Dann muss man es natürlich laufend pflegen und laufend aktuell halten.“

Diese Aufzählung beschreibt in einfacher Sprache den gesamten Lebenszyklus eines Softwareprodukts – von der Idee bis zur Wartung. Wir brechen das – aus der Perspektive dessen, was Julian anspricht – in konkrete Arbeitsschritte herunter:

1) Konzeptualisieren: Zielbild und Bedarf klären

  • „Wie sollte es am Schluss ausschauen?“: Ein klares Ergebnisbild verhindert, dass Teams im Dunkeln bauen. Es lenkt Diskussionen: Welche Funktionen sind wirklich nötig? Was ist ein guter erste Release?
  • „Was will der Kunde eigentlich?“: Ohne tatsächlichen Bedarf wird Software zum Selbstzweck. Das frühe Verständnis für Stakeholder und Anwendungsfälle ist die Basis für gutes Engineering.

2) Lösungsweg und Umsetzung planen

  • „Wie kann man das tatsächlich umsetzen?“: Zwischen Willen und Wirklichkeit liegen Architektur, Technologien, Datenmodelle und Integrationen. Der Transfer vom „Was“ zum „Wie“ ist der Kern des Engineerings.
  • „Dann setzt man es tatsächlich um“: Hier zählt Fokus auf Funktionalität, Lesbarkeit und Nachvollziehbarkeit. Code ist nicht nur für Maschinen. Er ist auch Kommunikationsmittel im Team – heute und morgen.

3) Einführen, testen und Qualität sichern

  • „Man muss das Ganze einführen“: Einführung heißt mehr als Deployment. Es bedeutet, Nutzerinnen und Nutzer mitzunehmen, Prozesse anzupassen und Rückmeldungen aufzunehmen.
  • „Es können dann auch Tests entwickelt, Tests durchgeführt“: Tests sind keine Kür am Ende. Sie sind Bestandteil des Verständnisses, wie das System funktionieren soll. Ohne Test ist eine Änderung ein Risiko, mit Test ist sie eine kontrollierte Verbesserung.

4) Fehler finden und beheben

  • „Fehler … muss man auch finden … und wieder lösen“: Fehler sind kein Ausnahmefall, sondern Normalität. Wer Bugs systematisch aufspürt, priorisiert und behebt, erhöht die Vertrauenswürdigkeit des Produkts – und lernt dabei über das System, das Verhalten der Nutzer und die Grenzen der eigenen Annahmen.

5) Laufende Pflege und Aktualität

  • „Laufend pflegen und laufend aktuell halten“: Software altert – Abhängigkeiten, Sicherheitsanforderungen, Plattformen. Pflege ist nicht „Nebenbei“, sie ist ein eigener Arbeitsstrom. Wer sie planbar macht, stabilisiert die Entwicklung.

Diese Linie – Konzept, Planung, Umsetzung, Einführung, Test, Fehlerbehebung, Pflege – ist uns in ihrer Schlichtheit sympathisch. Sie ist universell anwendbar, unabhängig von Methodik und Toolchain. Genau deshalb ist sie anschlussfähig: Teams können sie in ihren Alltag übersetzen, egal ob sie zwei Leute sind oder zwanzig.

Lernen, aber richtig: Projekte statt Aufgabenlisten

„Es ist eigentlich relativ wurscht, wie man dazu kommt. Also ob man jetzt studiert, ob man Lehr macht, ob man es auch selbst beibringt. Wichtig ist … gerade wenn man es selbst anfängt, dass man wirklich ein konkretes Projekt … sucht. Dass man nicht einfach irgendwelche Aufgaben nachmacht, so eine Liste abarbeitet, sondern dass man sich wirklich etwas überlegt: Das will ich machen, das will ich erreichen … und tatsächlich was außerbringt.“

Das ist eine deutliche Absage an reines „Tutorial-Driven Development“. Es spricht nichts gegen Lernplattformen oder Übungen – sie sind nützlich, um Syntax, Grundmuster und kleine Bausteine zu lernen. Aber Lernen wird erst dann stark, wenn es in ein selbst gewähltes Ziel mündet. Drei Gründe, warum Projektorientierung wirkt:

  1. Kontext statt Inselwissen: Wer ein konkretes Ergebnis anstrebt, verknüpft Wissen über Sprache, Frameworks, Daten und Deployment. Diese Verknüpfung ist das, was später in Teams zählt.
  2. Reale Entscheidungspunkte: Ein Projekt zwingt dazu, abzuwägen. Was ist Must-have, was nice-to-have? Welche Abhängigkeiten brauche ich wirklich? Diese Entscheidungen bilden das Denken aus.
  3. Ergebnisorientierung: „Tatsächlich was außerbringt“ – das Ergebnis motiviert. Es ist sichtbar und benutzbar, damit auch kritisierbar. Feedback treibt Verbesserung.

Für uns ist das zugleich ein Angebot an Einsteigerinnen und Einsteiger: Wählt ein Projekt, das euch interessiert, aber euch nicht überfordert. Setzt euch ein klares Zielbild. Definiert, was ihr in zwei Wochen funktional haben wollt. Und nehmt euch den Freiraum, Technik zu wechseln, wenn sie nicht passt – nicht um der Technik willen, sondern für das Ergebnis.

Freude als Taktgeber: Motivation ernst nehmen

„Es ist eigentlich egal, wie man es macht, aber wenn es keinen Spaß macht, dann hat alles keinen Sinn.“ Dieser Satz wirkt simpel, ist aber eine ernsthafte Prioritätenansage. Freude ist kein Luxus; sie ist eine zuverlässige Frühwarnung. Wenn der Spaß dauerhaft fehlt, stimmt meist etwas Grundlegendes nicht: das Ziel, der Rahmen, die Zusammenarbeit, oder die Balance zwischen Anspruch und Fähigkeiten.

Ihre praktische Konsequenz: Das, was Spaß macht, ist oft das, was sich lohnt zu vertiefen. Leidenschaft und Ausdauer hängen zusammen. Wer mit Freude lernt, hält Rückschläge besser aus, probiert mehr aus und baut in kürzerer Zeit tiefere Kompetenz auf. In Projekten spiegelt sich das so: Man bleibt am Problem, bis es gelöst ist. Man findet das kleine Extra an Qualität, das den Unterschied macht.

Natürlich heißt das nicht, dass jeder Tag leicht ist. Auch Julian beschreibt Testen, Fehler finden und Beheben sowie laufende Pflege – Phasen, die selten „glamourös“ sind. Aber gerade diese Aufgaben brauchen den inneren Motor. Ohne ihn verkommt Entwicklung zur Abarbeitung. Mit ihm bleibt sie Handwerk und Gestaltung zugleich.

Der rote Faden: Kontinuität, Praxisbezug, Ergebnisorientierung

Wenn wir Julians Stationen – Schule, Bachelor in Wirtschaftsinformatik, berufliche Praxis, Master in Data Science – mit seinen Prinzipien – Projekte, Freude, End-to-End-Verantwortung – zusammendenken, ergibt sich ein roter Faden:

  • Es beginnt mit einem realen Zugang (Wahlpflichtfach) und führt über die Brücke zur Anwendung (Wirtschaftsinformatik) in den praktischen Einsatz (berufliche Tätigkeit).
  • Es setzt sich fort in einer Spezialisierung, die zum eigenen Interesse passt (Data Science), ohne die Grundlagen aus dem Blick zu verlieren (Softwareentwicklung als Prozess von der Idee bis zur Pflege).
  • Es wird getragen von einer Lernhaltung, die auf Ergebnis zielt (Projekt) und auf Motivation achtet (Freude).

Das Bild ist nicht spektakulär – und gerade dadurch umso hilfreicher für alle, die ihren Weg planen. Es zeigt: Stabiler Fortschritt entsteht weniger durch spektakuläre Sprünge als durch konsequente Schritte.

Praktische Anregungen für Einsteigerinnen und Einsteiger

Angeregt durch Julians Aussagen haben wir konkrete Schritte gesammelt, die du sofort anwenden kannst – unabhängig davon, ob du studierst, eine Lehre machst oder dir Programmieren selbst beibringst:

  • Wähle ein Projekt mit persönlichem Nutzen: Etwas, das du selbst verwenden willst, erhöht die Chance, dranzubleiben.
  • Definiere ein sichtbares Zielbild: Schreib auf, „wie es am Schluss ausschauen“ soll. Ein Screenshot-Mockup reicht.
  • Begrenze den ersten Scope: Was ist in zwei Wochen nutzbar? Alles andere ist zweite Iteration.
  • Plane von Anfang an Tests ein: Mindestens für die Kernfunktionalität. Tests sind dein Sicherheitsnetz.
  • Führe dein Projekt wirklich ein: Zeig es anderen, hol Feedback. Ein „Release“ ist mehr als ein lokales Build.
  • Notiere Bugs und lerne daraus: Fehler sind normal. Meistens lehren sie dich etwas Zentrales über deine Annahmen.
  • Pflege ein kleines Changelog: Halte fest, was du geändert hast. Es schärft deinen Blick für Qualität und Verantwortlichkeit.

Diese Punkte spiegeln genau das wider, was Julian als Prozess beschreibt – nur heruntergebrochen auf das persönliche Lernprojekt.

Für Studierende: Arbeitserfahrung früh integrieren

Julian hat „währenddessen zum Arbeiten angefangen, damit ich auch ein bisschen Berufserfahrung sammeln kann“. Wenn du studierst, ist das ein starker Hebel. Warum?

  • Theorie in Praxis übersetzen: Du erkennst schneller, welche Inhalte sofort tragen.
  • Lernrichtung schärfen: Praxis zeigt, was du als Nächstes lernen solltest – nicht abstrakt, sondern konkret.
  • Portfolio aufbauen: Frühe Projekte, auch kleine, belegen, dass du liefern kannst – entscheidend bei Berufseinstiegen.

Nicht jeder kann jede Woche viele Stunden investieren. Aber schon punktuelle Tätigkeiten – etwa in vorlesungsfreien Zeiten – verbessern deine Lernkurve erheblich.

Die Rolle von Sprachen: C# und Python als frühe Kombi

Julian nennt explizit C# und Python als erste Sprachen. Ohne weitere Details zu vertiefen, zeigt die Kombination zwei Perspektiven: strukturierte, typisierte Entwicklung auf der einen Seite; schnelle, flexible Umsetzung auf der anderen. Wer diese Spannweite früh erlebt, versteht später leichter, warum manche Probleme nach Strenge verlangen und andere nach Tempo – eine Balance, die in Projekten ständig verhandelt wird.

Für Einsteigerinnen und Einsteiger kann das eine Leitlinie sein: Lerne eine Sprache, die dich zu sauberer Struktur zwingt, und eine, die dir schnelle Prototypen ermöglicht. Es geht nicht um „entweder oder“, sondern um Werkzeugschärfe für unterschiedliche Aufgaben.

Data Science als nächster Schritt

„Ich habe jetzt den Bachelor fertig und habe jetzt das Masterstudium in Data Science gerade angefangen.“ Mehr sagt Julian dazu nicht – und doch ist die Richtung klar: Datenkompetenz erweitert den Wirkungskreis der Softwareentwicklung. Daten machen Anwendungen lernfähig, personalisiert, messbar. Wer Software entwickeln und Daten verstehen kann, kann Wirkung in beiden Welten entfalten: in funktionaler Produktentwicklung und in datengetriebener Verbesserung.

Für alle, die mit dem Gedanken spielen: Der Schritt in Data Science ist kein Bruch, sondern eine Ergänzung. Er profitiert stark von den Prinzipien, die Julian betont: Projektorientierung, saubere Einführung, Tests, Fehlerkultur, Pflege. Datenprojekte benötigen diese Disziplin genauso wie klassische Anwendungsentwicklung.

Einfache Worte, klare Wirkung

Uns beeindruckt an Julians Beitrag die Reduktion auf das Wesentliche. Keine Buzzwords, keine Abkürzungen – dafür klare Schritte und eine deutliche Haltung. Aus unserer Sicht liegen darin drei dauerhaft tragfähige Einsichten:

  • Produktdenken schlägt Technikdenken: „Was will der Kunde eigentlich?“ ist die erste Frage, nicht die Wahl des Frameworks.
  • Verantwortung endet nicht beim Commit: Einführung, Tests, Fehlerbehebung und Pflege gehören zum Job – sie sind nicht „Support“, sie sind Softwareentwicklung.
  • Motivation ist Messgröße: „Wenn es keinen Spaß macht, dann hat alles keinen Sinn.“ Freude ist der Indikator, ob du gerade das Richtige tust – und ob du es lange genug tun wirst, um wirklich gut zu werden.

Zitate, die hängen bleiben

Zur besseren Orientierung fassen wir die Kernsätze zusammen, die diese Haltung prägen – jeweils so, wie Julian sie formuliert:

„Wir konzeptualisieren einmal, wie wollen wir das machen, wie sollte es am Schluss ausschauen, was will der Kunde eigentlich.“

„Dann überlegt man sich, wie kann man das tatsächlich umsetzen. Dann setzt man es tatsächlich um.“

„Es können dann auch Tests entwickelt, Tests durchgeführt … Fehler … muss man auch finden … und wieder lösen.“

„Dann muss man es natürlich laufend pflegen und laufend aktuell halten.“

„Es ist eigentlich relativ wurscht, wie man dazu kommt … Wichtig ist … dass man wirklich ein konkretes Projekt … sucht.“

„Dass man nicht einfach irgendwelche Aufgaben nachmacht … sondern … tatsächlich was außerbringt.“

„Wenn es keinen Spaß macht, dann hat alles keinen Sinn.“

Diese Sätze sind kein Handbuch – aber ein zuverlässiger Kompass. Sie helfen, Entscheidungen im Kleinen zu treffen: Was ist jetzt der nächste sinnvolle Schritt? Woran messe ich Fortschritt? Wie erkenne ich, dass ich auf dem richtigen Weg bin?

Fazit: Ein devstory, die Mut macht – und den Fokus schärft

„Julian Deleja-Hotko, Software Developer bei enjoy IT“ ist eine kurze, aber prägnante devstory: Ein früher Start in der Schule. Ein anwendungsnahes Studium. Berufserfahrung bereits während des Studiums. Ein Master in Data Science als nächster Schritt. Und darüber gelegt: eine praktische Anleitung zur Softwareentwicklung vom Konzept bis zur Pflege.

Für Entwicklerinnen und Entwickler – egal ob am Anfang oder mittendrin – liegen die Botschaften auf der Hand:

  • Finde deinen Zugang – Schule, Studium, Lehre oder Selbststudium – und halte die Linie.
  • Lerne in Projekten, nicht in Aufgabenlisten.
  • Denke die Einführung, Tests, Fehlerbehebung und Pflege von Beginn an mit.
  • Miss deinen Kurs an der Freude am Tun – sie ist der verlässlichste Antrieb.

Aus unserer DevJobs.at-Perspektive ist genau das die Stärke dieser Session: Sie liefert keine Abkürzung, sondern Orientierung. Und sie erinnert daran, dass gute Softwareentwicklung zugleich Klarheit, Ausdauer und Neugier braucht – Eigenschaften, die man kultivieren kann, Schritt für Schritt.

Weitere Dev Stories