Vom Informatikstudium zum .NET-Profi: Die Laufbahn von Marek Dusecina, Senior Full Stack Engineer bei ANKÖ (Auftragnehmerkataster Österreich)

Kontext: Eine nüchterne, praxisnahe Dev-Story

In der Session „Marek Dusecina, Senior Full Stack Engineer bei ANKÖ“ zeichnet der Entwickler von Auftragnehmerkataster Österreich eine bodenständige, geradlinige Karriere nach – ohne Showeffekte, aber mit klaren Prinzipien. Was sofort auffällt: Marek denkt in Lernpfaden, Routinen und Verantwortlichkeiten. Er erzählt nicht in großen Anekdoten, sondern in Stationen und Kompetenzen. Gerade deshalb wirkt seine Dev-Story für uns bei DevJobs.at besonders greifbar – und lehrreich.

Marek hat Informatik studiert, früh neben dem Studium in einem deutschen Unternehmen gearbeitet, ist nach dem Abschluss nach Österreich gezogen und seit 2013 bei ANKÖ in der .NET-Welt zu Hause. Sein Arbeitsfeld: Webapplikationen – weiterentwickeln, neu entwickeln, und immer wieder auch „Bugfixing oder Hotfixing“. Er beschreibt sich selbst als Schnittstelle, die „immer diskutieren“ muss, ob Aufgaben vollständig und verständlich sind, bevor Aufwand geschätzt und programmiert wird. Seine Lernempfehlung reicht von HTML über JavaScript und PHP hin zu C#, Node.js, Java und Python. Persönlich setzt er auf C# und das Microsoft-Ökosystem. Und als Fundament betont er: „Informatikstudium ist eine gute Grundlage.“

Vom Campus in die Praxis: Früher Einstieg, Lernkurve, Sprachen

Marek beginnt seine Geschichte mit einer Neugier auf sichere Programmiersprachen: „Nach Beginn meines Studiums habe ich mich um sichere Programmiersprache interessiert.“ Gleichzeitig geht er früh in die Praxis: „Schon während Studium habe ich bei einem deutschen Unternehmen einen Job wie Entwickler angenommen.“ Damit verknüpft er Lernen und Arbeiten – eine Konstellation, die vielen Entwicklerinnen und Entwicklern hilft, Theorie und Praxis sinnvoll ineinander zu verschränken.

Zur Praxis gehört bei ihm auch Bewegung: „Da habe ich auch die Dienstreise nach Deutschland unternommen und da habe ich auch die deutsche Sprache besser kennengelernt.“ Für uns ist das ein leiser, aber wichtiger Punkt in seiner Story: Projekte, Reisen und Teamkontakte verändern nicht nur den Code, sondern auch die eigene Kommunikationsfähigkeit. Dass er die Sprache „besser kennengelernt“ hat, verbindet Technik- und Soft-Skill-Lernen in einem Schritt.

Ankommen in Österreich: Kontinuität statt Umbruch

„Nach dem Studium bin ich nach Österreich umgezogen. Gleicher Job war ich beim ANKÖ.“ Marek setzt auf Kontinuität: Er wechselt das Land, aber nicht seinen Beruf. 2013 beginnt er bei ANKÖ – Auftragnehmerkataster Österreich – und bleibt. „Ich bin seit 2013 bei ANKÖ und ich kenne ANKÖ von Anfang an.“ Dieser Satz transportiert Verbundenheit und Langfristigkeit. Für uns zeigt sich hier ein Entwicklungsweg, der nicht von häufigen Arbeitgeberwechseln lebt, sondern von Tiefe: Systeme verstehen, Produkte begleiten, Wissensinseln stabilisieren.

.NET-Webapplikationen als Kern: Weiterentwicklung, Neuentwicklung, Verantwortung

Sein Fokus ist klar: „Ich kümmere mich um die .NET-Webapplikationen. Wir entwickeln die bestehenden Produkte weiter oder wir entwickeln neue Produkte.“ Hinter diesem Satz steckt mehr als nur Tech-Stack. Weiterentwickeln heißt Bestandspflege, Migrationspfade, Abwärtskompatibilität, und das Bewusstsein, dass Nutzerinnen und Nutzer auf Stabilität angewiesen sind. Neuentwicklung bedeutet Exploration, Architekturentscheidungen, Iteration.

Marek benennt auch die weniger glamourösen, aber entscheidenden Teile des Jobs: „Zu diesem Business gehört manchmal auch Backfixing oder Hotfixing.“ Hier klingt Routine an – und Verantwortung. Hotfixing verlangt schnelle, sichere Entscheidungen. Bugfixing braucht Sorgfalt, Reproduzierbarkeit, und oft die Fähigkeit, „alte“ Annahmen kritisch zu hinterfragen.

Kommunikation als Struktur: Zwischen Stakeholder und Entwicklung

Ein zentraler Punkt seiner Arbeitsweise: „Ich bin wie eine Schnittstelle zwischen Protagonist und Entwickler. Ich muss immer diskutieren, was noch zu tun ist, ob die ganze Aufgabe vollständig und gut zu verstehen ist.“ Für uns ist das der Dreh- und Angelpunkt seiner Rolle. Anforderungen klären, Lücken identifizieren, Unklarheiten auflösen – bevor Team und Code loslaufen.

Die Abfolge, die Marek schildert, ist prototypisch für professionelle Produktentwicklung:

• Klärung: Ist die Aufgabe vollständig und verständlich?
• Aufwandsschätzung: Wie groß ist der Effort, was ist realistisch?
• Umsetzung: Erst programmieren, wenn Klarheit und Schätzung stehen.

Diese Ordnung führt zu Verlässlichkeit. In Mareks Worten liegt keine Methodendogmatik, sondern Handwerk. Er beschreibt ein Muster, das Teamkommunikation und Planung zusammenbindet.

Lernpfade statt Abkürzungen: Von HTML bis C# und darüber hinaus

„Informatikstudium ist eine gute Grundlage. Man beginnt mit leichterer Sprache. Man kann sagen, es ist HTML, obwohl es keine Programmiersprache ist, aber es ist leicht zu verstehen. Dann kommt man drinnen mit JavaScript, PHP und langsam mit C-Sharp, Node.js und dann sieht man vielleicht auch Java, das ist heute gut bekannt, oder Python auch.“

Marek zeichnet hier bewusst keinen Hype-getriebenen Weg. Stattdessen: grundlegend anfangen, über Web-Basics in die Programmierung hineinwachsen, dann die Brücke zu typisierten Sprachen schlagen und schließlich den eigenen Schwerpunkt finden.

Dass er C# betont, fügt sich zu seinem Arbeitsumfeld in .NET-Webapplikationen. Seine Empfehlung bleibt dennoch offen: Wer lernt, darf vieles „sehen“ – Java, Python, Node.js – und dann entscheiden. Wichtig ist der Pfad, nicht die Abkürzung.

Ziele setzen und Projekte bauen: Vom E‑Shop zum Rubik’s Cube

„Man soll auch ein Ziel haben, zum Beispiel, was man programmieren kann.“ Marek wird dabei konkret: Er hat „mit E-Shops angefangen“. Dazu kommen „so kleine Programme wie Calculator oder Rubikwürfel“. Diese Beispiele zeigen, wie Lernen in Aufgaben übersetzt wird: E-Commerce-Logik, Formvalidierungen, Sessions, kleine Algorithmen – und bei einem Rubik’s Cube-Projekt möglicherweise Zustandsdarstellungen und Transformationen.

Seine Botschaft ist schlicht: Ziele machen Lernen greifbar. Kleine Projekte erzeugen Momentum. Und genau diese Mischung baut Kompetenzen auf, die in der Praxis zählen: Durchgängiges Denken von UI bis Logik, Fehlerbehandlung, und das Überführen einer Idee in ein funktionierendes Artefakt.

Das Profil dahinter: Mathe, Stressresistenz, OOP, Selbstständigkeit

Auf die Frage, was für ihn wichtig war, bleibt Marek konkret:

• „Ich habe ein gutes mathematisches Denken gehabt.“
• „Ich war sehr stressresistent.“
• „Ich habe auch ein Interesse für Objektorientierungsprogrammierung, objektorientiertes Programmieren.“
• „Ich war selbstständig und das ist für mich sehr wichtig, selbstständig zu arbeiten.“

Damit zeichnet er ein Kompetenzprofil, das auffällig unaufgeregt ist – und genau deshalb überzeugend. Mathematisches Denken hilft bei Abstraktion, Komplexitätsgefühl, Datenstrukturen. Stressresistenz stabilisiert im Hotfixing und im Release-Druck. OOP-Interesse zahlt auf .NET-Entwicklung ein. Selbstständigkeit sorgt dafür, dass Aufgaben nicht versanden, sondern verlässlich über die Ziellinie kommen.

Was wir als Redaktion mitnehmen: Leitplanken für die Praxis

Aus Mareks kompakten Aussagen lassen sich klare Leitplanken formulieren – ohne etwas hineinzuinterpretieren, was nicht gesagt wurde:

1. Fundament vor Framework: Ein Informatikstudium (oder solide Grundlagenarbeit) schafft Denkmodelle, die Technologiezyklen überdauern.
2. Lernen in Etappen: HTML als Türöffner, JavaScript/PHP für die Programmierpraxis, dann C# oder andere Sprachen mit stärkeren Typ- und OOP-Konzepten.
3. Schwerpunkt setzen: „Für mich war C-Sharp das Beste“ – Spezialisierung schafft Tiefe und macht dich zum verlässlichen Ansprechpartner.
4. Projekte, nicht nur Tutorials: E-Shops, kleine Tools, auch Spielereien wie ein Rubik’s-Cube-Programm – Hauptsache, du übst Ende-zu-Ende.
5. Kommunikation zuerst: „Ich muss immer diskutieren, was noch zu tun ist…“ – Anforderungen klären, dann schätzen, dann umsetzen.
6. Realismus in der Produktpflege: „Bugfixing oder Hotfixing“ gehört dazu. Wer das akzeptiert, arbeitet stabiler und gelassener.
7. Persönliche Stärken kultivieren: Mathegefühl, Stressresistenz, OOP-Interesse, Selbstständigkeit – diese Eigenschaften tragen.

Die Rolle im Team: Brückenbau als Qualitätshebel

Wenn Marek sich „wie eine Schnittstelle zwischen Protagonist und Entwickler“ beschreibt, steckt darin eine Haltung: Verantwortung endet nicht im eigenen Editorfenster. Wer Anforderungen strukturiert, vermeidet Blindleistung im Team. Wer Aufwandsschätzungen an eine verständliche Aufgabe bindet, schützt Qualität und Termine.

Diese Schnittstellenkompetenz ist nicht an Titel gebunden. Auch ohne formelle Product-Owner- oder Lead-Rolle kann man die Qualität der Zusammenarbeit erhöhen – indem man die richtigen Fragen stellt: Ist die Aufgabe vollständig? Ist das Ziel messbar? Welche Abhängigkeiten existieren? Erst dann lohnt es, „Effort, Schätzung“ und Umsetzung anzugehen.

.NET-Webapplikationen: Handwerk, das Bestand hat

Marek verortet sich klar im .NET-Web-Umfeld. Aus seiner Beschreibung lesen wir die typischen Spannungsfelder dieser Arbeit heraus – ohne weitere Details erfinden zu müssen:

• Bestandsprodukte: Legacy-Bestand, Weiterentwicklung, Stabilität.
• Neuprodukte: Exploration, saubere Struktur, solide Basis.
• Fixes: „Backfixing oder Hotfixing“ – und damit ständige Qualitätssicherung.

Gemeinsam gehalten wird das von der Kommunikationsroutine, die er skizziert. Erst klären, dann schätzen, dann bauen. Dieser Dreischritt ist in jeder Technologie wertvoll – in größeren .NET-Umgebungen aber besonders, weil viele Komponenten über Jahre hinweg gewachsen sind.

Lernen als Weg: Von Sprache zu Sprache – und dann zu sich selbst

Was wir an Mareks Lernvorschlag schätzen, ist seine Bodenständigkeit. „Man beginnt mit leichterer Sprache… HTML … dann … JavaScript, PHP … langsam … C-Sharp, Node.js … vielleicht auch Java … oder Python.“ Kein Überfliegen, kein „in 30 Tagen zum Guru“. Stattdessen: aufbauen, vergleichen, verstehen.

Dazu passt, dass er seinen Favoriten klar benennt: „Für mich war C-Sharp das Beste, es war von der Microsoft-Familie.“ Der Satz zeigt: Am Ende braucht Lernen eine Entscheidung. Nicht, um sich für immer festzulegen, sondern um echte Tiefe aufzubauen. Wer alles ein bisschen kann, kann selten Verantwortung für ein System übernehmen. Wer einen Schwerpunkt wählt, wird greifbar – für Kolleginnen, für Stakeholder, für das Produkt.

Kleine Projekte, großer Effekt: Warum „Calculator“ und „Rubikwürfel“ zählen

„Das waren so kleine Programme wie Calculator oder Rubikwürfel.“ Diese Beispiele wirken bewusst unspektakulär. Genau darin liegt ihr Wert. Kleine Projekte machen die Hürden niedrig und die Feedbackschleifen kurz. Sie trainieren Denken in Systemen, Testbarkeit, und das Umsetzen einer Idee in Funktionalität.

Der Schritt zu größeren Vorhaben – etwa ein E-Shop – wird dadurch greifbar. Wer einen Taschenrechner sauber modellieren kann, kann Geschäftslogik strukturieren. Wer einen Rubik’s Cube modelliert, trainiert Zustände und Transformationen – Fähigkeiten, die in Backend-Logik, Validierung und Datenfluss immer wieder gebraucht werden.

Eigenschaften, die tragen: Stressresistenz und Selbstständigkeit

Marek nennt zwei Aspekte, die in echten Systemen unbezahlbar sind: Stressresistenz und Selbstständigkeit. Beides ist im „Hotfixing“-Moment entscheidend. Wenn ein System drückt, wenn Zeit knapp wird, dann sind kühle, strukturierte Entscheidungen wertvoller als alle Framework-Finessen. Selbstständigkeit bedeutet, nicht darauf zu warten, dass jemand anderes die Aufgabe schneidet oder das Problem löst. In Mareks Worten: „…das ist für mich sehr wichtig, selbstständig zu arbeiten.“

Konkrete Impulse für Nachwuchs- und Quereinstieg

Aus Mareks Weg lassen sich konkrete Schritte ableiten, die sich 1:1 umsetzen lassen – ohne die Grenzen seiner Erzählung zu überschreiten:

• Starte mit HTML, um Struktur und Semantik zu verstehen. Geh dann zu JavaScript und PHP, um echte Programmierpraxis zu sammeln.
• Wähle danach eine stärker typisierte Sprache wie C# als Schwerpunkt, wenn dich Webapplikationen im .NET-Umfeld reizen. Alternativ: Java oder Python „sehen“ und vergleichen.
• Setze Ziele. Baue konkrete Projekte: einen kleinen Shop, ein Formularsystem, einen „Calculator“. Wenn es dich reizt, modellier einen „Rubikwürfel“ – Hauptsache, du füllst deinen Werkzeugkasten.
• Übe Kommunikation. Stell dir Mareks Fragen: Ist die Aufgabe vollständig? Verstehe ich sie gut genug? Kann ich den Aufwand realistisch schätzen?
• Rechne mit Fixes. Akzeptiere, dass Bugfixing und Hotfixing Teil des Jobs sind – und trainiere dafür Reproduzierbarkeit, Dokumentation, und Gelassenheit.
• Achte auf dein Profil: Pflege mathematisches Denken, lerne OOP sauber, trainiere Stressresistenz, arbeite selbstständig.

Ein Satz, der bleibt: Qualität ist ein Prozess, kein Ereignis

Wenn wir Mareks Darstellung auf einen Nenner bringen, dann diesen: Qualität entsteht aus Ordnung. Er ordnet Aufgaben, er ordnet Lernschritte, er ordnet die Umsetzung. Erst klären, dann schätzen, dann programmieren – dieser Ablauf ist sein Qualitätsanker.

Dieser Satz klingt unspektakulär – und ist genau deshalb stark. Er ist der Unterschied zwischen Aktionismus und professioneller Produktentwicklung.

Schluss: Eine leise, aber tragfähige Dev-Story

Die Session „Marek Dusecina, Senior Full Stack Engineer bei ANKÖ“ zeigt: Man muss keine laute Karriere erzählen, um nachhaltig Wirkung zu erzielen. Marek präsentiert eine Laufbahn, die auf Fundament, Fokus und Verantwortung baut. Er arbeitet an .NET-Webapplikationen, entwickelt Bestehendes weiter, schafft Neues, fixt Fehler, wenn es nötig ist, und stellt die richtigen Fragen, bevor es losgeht.

„Für mich war C-Sharp das Beste,“ sagt er – ein Bekenntnis zu einem Schwerpunkt. „Informatikstudium ist eine gute Grundlage“ – ein Bekenntnis zum Fundament. Und: „Ich war selbstständig“ – ein Bekenntnis zur Haltung.

Für uns ist das die Essenz dieser Dev-Story von Auftragnehmerkataster Österreich: Wer strukturiert lernt, klar kommuniziert und verlässlich handelt, bleibt – wie Marek – auf Kurs. Seit 2013 und darüber hinaus.

• 

  

  Zwei-Faktor-Authentifizierung und ID Austria

  Dominik Zimmel von ANKÖ demonstriert in seinem devjobs.at TechTalk wie die Produkte funktionieren, an denen das Unternehmen arbeitet.

  Jetzt ansehen

• 

  

  Patrick Osika, IT-Leiter bei ANKÖ

  Patrick Osika von ANKÖ spricht im Interview über den Aufbau des IT Teams im Unternehmen, den Ablauf des Bewerbungsprozesses und gibt Einblicke in die technologischen Challenges.

  Jetzt ansehen

• 

  

  Dominik Zimmel, Product Owner bei ANKÖ

  Dominik Zimmel von ANKÖ spricht im Interview über seine Reise bis hin zur Arbeit als Product Owner, wie sein Arbeitsalltag aussieht und gibt nützliche Tipps für Anfänger.

  Jetzt ansehen