From Computer Science Fundamentals to .NET Craft: The Journey of Marek Dusecina, Senior Full Stack Engineer at ANKÖ (Auftragnehmerkataster Österreich)

A grounded dev story with clear principles

In the session “Marek Dusecina, Senior Full Stack Engineer bei ANKÖ,” the developer from Auftragnehmerkataster Österreich shares a career arc that is refreshingly straightforward: less spectacle, more substance. Marek talks in milestones and competencies, not exaggerated drama. That makes his story especially practical for engineers.

He studied computer science, worked as a developer at a German company during his studies, traveled for work to Germany where he improved his German language skills, and after graduating moved to Austria. Since 2013, he has been at ANKÖ, focusing on .NET web applications. His scope: extending existing products, building new ones, and, as he puts it, doing “bugfixing or hotfixing” when needed. He positions himself as a bridge who must “always discuss what still needs to be done” and verify that tasks are complete and well understood before moving to effort estimation and coding. His learning route runs from HTML to JavaScript and PHP, then to C#, Node.js, with Java and Python also in the mix. Personally, he favors C# and the Microsoft ecosystem. And he underscores a bedrock point: “Computer science studies are a good foundation.”

Early practice, steady growth, language skills

Marek begins with a curiosity about safe programming languages: “After I started my studies, I was interested in safe programming languages.” He also moved quickly into real-world work: “During my studies I took a job as a developer at a German company.” This intertwines practice and theory—often the fastest route to meaningful progress.

Professional experience also improved his communication: “I took a business trip to Germany and there I got to know the German language better.” For us, this is a quiet but important element of his story: projects and team contact don’t just change the code; they change the developer. Communication expands alongside technical capability.

Arriving in Austria: continuity over disruption

“After graduation I moved to Austria. It was the same job at ANKÖ.” Marek values continuity. He changes countries, not careers. “I have been at ANKÖ since 2013 and I know ANKÖ from the beginning.” The remark conveys long-term commitment. What emerges is a developer profile built on depth: understanding systems, carrying products forward, and consolidating knowledge in-house.

The .NET web focus: extending, creating, and owning the craft

His focus is explicit: “I take care of .NET web applications. We extend existing products or we develop new products.” In that short description sits the double logic of professional software: maintenance and innovation. Extending means migrations, compatibility, and the awareness that users rely on stability. New products require exploration and sound architecture under uncertainty.

He also names the less glamorous but critical part of the craft: “This business sometimes includes bugfixing or hotfixing.” That is routine and responsibility combined. Hotfixes demand fast and safe decisions; bugfixing demands careful reproduction and a willingness to challenge old assumptions.

Communication as structure: the bridge mindset

A centerpiece of Marek’s day-to-day is being a bridge: “I am like an interface between the protagonist and developer. I must always discuss what else needs to be done, whether the task is complete and well understood.”

The sequence he outlines is a hallmark of professional product work:

• Clarify: Is the task complete and well understood?
• Estimate: What effort is realistic?
• Implement: Only code after clarity and estimation.

There’s no dogma here, just craft. This order produces reliability for teams and stakeholders alike.

Learning as a path: HTML to C#—and beyond

“Computer science studies are a good foundation. You start with an easier language. You could say it’s HTML, although it’s not a programming language, but it’s easy to understand. Then you get into JavaScript, PHP, and slowly C#, Node.js, and then maybe you also see Java, which is well known today, or Python.”

Marek isn’t chasing hype; he’s tracing a path. Start simple, move into actual programming in the web, and then cross into languages with stronger typing and OOP.

His preference lines up with his work on .NET web applications. But the recommendation remains open: explore, then choose. The sequence matters more than an early, arbitrary choice.

Goals and projects: from e-shops to a Rubik’s cube

“You should also have a goal, for example what you can program.” Marek gets specific: he “started with e-shops.” He also built “small programs like a calculator or a Rubik’s cube.” These examples show how learning translates into action: e-commerce logic, forms, sessions, small algorithms—and, for the Rubik’s cube, possibly state modeling and transformations.

The core message is simple: goals make learning concrete. Small projects create momentum. This is how capabilities stack: end-to-end thinking from UI to logic, error handling, and turning an idea into working software.

The profile underneath: math, stress resilience, OOP, independence

Asked what mattered, Marek is concrete:

• “I had good mathematical thinking.”
• “I was very stress-resistant.”
• “I had an interest in object-oriented programming.”
• “I was independent, and it’s very important for me to work independently.”

This is a quiet but convincing portfolio. Mathematical thinking supports abstraction and a sense of complexity. Stress resilience stabilizes hotfixes and release pressure. OOP interest dovetails with .NET development. Independence ensures tasks get shepherded across the finish line.

Editorial takeaways: practical guardrails for developers

Grounded in Marek’s statements, we see clear guardrails for sustainable growth:

1. Foundation before framework: computer science fundamentals outlast technology cycles.
2. Learn in stages: HTML as a door-opener; JavaScript/PHP for programming practice; then C# or another strongly typed/OOP language.
3. Choose a focus: “For me C-Sharp was the best”—depth creates reliability and trust.
4. Build projects, not just follow tutorials: e-shops, small tools, even a Rubik’s cube program—what matters is end-to-end learning.
5. Communicate first: “I must always discuss… whether the task is complete…”—clarify before estimation and implementation.
6. Embrace the unglamorous: “Bugfixing or hotfixing” is part of the job. Owning it makes you steadier.
7. Cultivate personal strengths: math sense, stress resilience, OOP interest, independence.

The team role: bridging as a quality multiplier

When Marek calls himself “like an interface between the protagonist and developer,” he’s pointing at a posture: responsibility doesn’t end at your editor. Structuring requirements avoids waste. Tying estimates to well-defined work protects quality and timelines.

You don’t need a formal title to exercise this influence. Simply ask the right questions early: Is the task complete? Is the goal clear enough to estimate? What dependencies exist? Only then is it time for “effort, estimation, and programming.”

.NET web applications: stable craft, real constraints

Marek positions himself in the .NET web world. From his brief description, the usual contours are evident—without inventing further detail:

• Existing products: legacy, evolution, stability.
• New products: exploration, clean structure, solid baselining.
• Fixes: “bugfixing or hotfixing”—constant quality assurance.

The glue is his communication routine. Clarify first, then estimate, then build. This triad is valuable in any stack; in mature .NET environments, it is often decisive.

Learning by seeing—and then choosing

What we like about Marek’s learning advice is how measured it is. “Start with an easier language… HTML… then JavaScript, PHP… slowly C#, Node.js… maybe also see Java… or Python.” No gimmicks, no 30-day shortcuts. Build, compare, understand.

The preference that follows is equally frank: “For me C-Sharp was the best; it was from the Microsoft family.” Learning eventually needs a choice—not to shut doors, but to build depth. If you try to be everything at once, you risk being responsible for nothing. Focus makes you useful.

Small projects, big leverage

“Small programs like a calculator or a Rubik’s cube.” These examples are deliberately unspectacular. That’s their power. Small projects lower barriers and shorten feedback loops. They train system thinking, testability, and the translation of an idea into function.

Step by step, the leap to larger efforts—an e-shop—becomes feasible. If you can model a calculator cleanly, you can structure business logic. If you can represent a Rubik’s cube and its transformations, you’re rehearsing state and transitions: skills that recur across backends, validation, and data flow.

Traits that carry: stress resilience and independence

Two traits Marek highlights matter tremendously in real systems: stress resilience and independence. Both are vital in “hotfixing” moments. When time is tight and systems are pressing, calm, structured action is worth more than ornate framework knowledge. Independence means not waiting for someone else to slice the task or solve the problem. In his words: working “independently” is “very important.”

Concrete steps for newcomers and career shifters

From Marek’s path, we extract actionable, transcript-aligned steps:

• Start with HTML to grasp structure and semantics. Move to JavaScript and PHP to build programming muscle.
• Choose a stronger-typed/OOP language (e.g., C#) if .NET web work appeals. Also “see” Java or Python to compare and decide.
• Set goals. Build small projects: a shop, a form system, a “calculator.” If it intrigues you, model a “Rubik’s cube.” The point is to stock your toolbox.
• Practice communication. Borrow Marek’s filter: is the task complete? Do I understand it well enough to estimate?
• Expect fixes. Accept that bugfixing and hotfixing are part of the profession—train reproduction, documentation, and calm.
• Shape your profile: nurture mathematical thinking, learn OOP properly, train stress resilience, work independently.

One line that sticks: quality is a process

If we sum up Marek’s perspective, it’s this: quality is the product of order. He orders tasks, he orders learning steps, he orders implementation. Clarify, estimate, program—this is his quality anchor.

It’s an unflashy line—and powerful. It marks the difference between motion and progress.

Closing: a quiet, durable developer narrative

The session “Marek Dusecina, Senior Full Stack Engineer bei ANKÖ” shows that a developer career doesn’t need to be loud to be effective. Marek builds on fundamentals, focus, and responsibility. He works on .NET web applications, extends the existing, creates the new, fixes issues when needed, and asks the right questions before starting.

“For me C-Sharp was the best,” he says—a commitment to a focus. “Computer science studies are a good foundation”—a commitment to fundamentals. And: “I was independent”—a commitment to posture.

For us, that is the essence of this dev story from Auftragnehmerkataster Österreich: structured learning, clear communication, and reliable execution. It’s how you stay on course—like Marek—since 2013 and beyond.

• 

  

  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.

  Watch now

• 

  

  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.

  Watch now

• 

  

  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.

  Watch now