From Aha Moment to Dual Role: How Katja Hammer at Doka GmbH Blends Software Development and Requirements Engineering

A beginning that wasn’t love at first sight—and why that matters

From our DevJobs.at editorial vantage point, the most instructive career stories are often the quiet, grounded ones. In the session “Katja Hammer, Software Developer bei Doka” (Speaker: Katja Hammer, Company: Doka GmbH), the developer walks us through a path that shows how motivation emerges not always at the start, but when the learning context, the problems, and the sense of impact finally click.

Katja is candid about her early experience: she started programming “as part of [her] education at an IT‑focused HTL,” but:

The turning point comes in the third year of school, when the focus shifted to a different programming language. That’s when she felt a true “aha moment,” and programming “became really fun.” It’s more than a mood change. It marks the point where curiosity and confidence align—a pattern we recognize in many developer journeys.

The role of education: Foundations that open doors

Katja completed a HTL with a specialization in media technology. That detail grows in importance as her story unfolds. On the one hand, a technical school equips students with solid fundamentals. On the other, a media‑driven focus opens the door to user‑facing thinking early on. This bridge becomes relevant later when she starts exploring UI/UX design.

Her education was a starting line, not a finish. Those fundamentals enabled her to move into practice quickly after graduation, which is exactly what happened in her first role.

Joining Doka: Impact through internal tools

After graduating, Katja “found a job at Doka relatively quickly” and began working on an internal calculation tool. Internal tools rarely make it to glossy slides, yet they power productivity in many companies. Working on them puts you close to the organization’s inner workings: business logic, data flows, release practices—and, crucially, the immediate impact of software on everyday work.

Over time, “other programs were added” to her scope. That modest remark carries weight. Multiple systems mean diverse stakeholders and different requirements—great conditions for developing problem‑solving range. That’s how professional maturity grows: not only through language or framework choices, but through exposure to varied contexts.

Opening toward UI/UX: Design meets engineering

This year, an opportunity emerged for Katja to “try [herself] in UI, UX design.” Her media‑technology foundation fits naturally here, bringing a sensitivity for user interfaces that goes beyond technical correctness to include accessibility and coherence.

What’s notable is that this isn’t a category switch; it’s an extension. Modern teams often expect end‑to‑end responsibility and tight collaboration between engineering and design. When a developer takes steps toward user experience, feedback loops shrink—and she sees why certain requirements exist. This connection mirrors Katja’s current team role.

In the IT Sales & Operations team: Two responsibilities, one goal

Katja situates herself clearly: she’s “part of the Sales and Operations team in IT” and has “primarily two tasks.”

1) Software development—end to end:

• Specify requirements together with business stakeholders
• Program and implement those requirements
• Handle software releases and ongoing evolution

2) Requirements engineering—as a partner to the business:

• Get pulled into projects by the business units
• Help define and sharpen the IT requirements

This dual role is a standout theme in her story. It underscores that value creation in software doesn’t stop at the code line. Understanding the domain and the language of the business yields better requirements—and solutions that actually fit.

Proximity to the business: Where clarity in requirements is born

When Katja says the business can “bring [her] in as a partner,” it reflects a collaboration model we see in effective teams. The goal is to be involved early—not just after a fully written spec appears. Joint specification is a quality lever.

• Early conversations reduce misunderstandings and rework.
• Shared definitions surface implicit assumptions.
• Business learns what’s technically sensible; engineers learn what’s mission‑critical.

Her phrasing—“I help the business define the IT requirements”—captures that impact. Good requirements don’t emerge in a vacuum; they result from facilitated, focused conversations.

Paths into software: There are several, and that’s a strength

A central motif in Katja’s story is that there isn’t only one path into software development. She maps the spectrum—from learning through “tutorials on the internet” to “courses, school, or university” with a mentor‑like structure. She is careful not to hand out a one‑size‑fits‑all recommendation:

For her, the HTL path was “a good way.” The decisive accelerant was the environment at Doka: “Thanks to [her] colleagues” she could quickly “consolidate and expand” what she had learned. The broader message is universal: foundational knowledge plus a practice setting that deepens it accelerates growth.

The underrated lever called “team”: Learning happens in context

When Katja talks about consolidating and expanding knowledge, we hear the interplay of feedback, pairing, code reviews, and pragmatic project pressure. That’s how theory turns into practice: understanding requirements, releasing safely, talking to business partners—competences that don’t grow in textbooks alone.

Her path also illustrates the value of spaces for exploration. The chance to dabble in UI/UX is one such space. Taking responsibility at the user interface fosters more holistic software decisions.

On setbacks and prejudice: Persistence is part of the plan

Katja doesn’t gloss over the harder parts. Her advice is clear:

That’s not a platitude. Anyone learning new technologies or facilitating business conversations will make mistakes, correct assumptions, and revisit decisions. In those moments, team culture decides much: Is it safe to fail? Is learning enabled? Katja’s call for confidence and persistence is also a call for teams and organizations to build an environment that supports it.

Practical insights for developers

Several actionable takeaways emerge from her story:

• Create opportunities for aha moments: Try different languages, paradigms, and problem types. Often it’s a shift in perspective that ignites motivation.
• Get close to the domain: Work with business on the requirement—not just on the implementation. Quality and speed both improve.
• Build on foundations: Solid education (formal or self‑taught) is a springboard. The key is how quickly you apply it in real projects.
• Lean on your team: Colleagues are learning accelerators. Ask for feedback, seek pairing, read and discuss code.
• Translate between worlds: Requirements engineering isn’t an “extra,” it’s core to modern software work. Combining both disciplines delivers outsized value.
• Normalize friction: Setbacks are signals, not stigmas. Adjust your learning path rather than giving up.

A closer look at the dual role: Why it’s so valuable today

Katja’s day‑to‑day spans both the “how” (implementation, releases) and the “what” (requirements). In our view, this combination is a smart response to the complexity of today’s IT landscapes:

• Requirements are rarely complete: Developers who can challenge assumptions propose solutions that are coherent both technically and functionally.
• Development benefits from context: Being present at requirement definition eliminates blind spots during implementation.
• Releases are calmer: Closer proximity to users leads to better feature slicing and fewer surprises in production.

The fact that Katja performs this work in a Sales & Operations context shows where software often yields the strongest leverage: close to the business, inside the processes that create value daily.

Internal tools as a growth engine

Katja’s start on an internal calculation tool demonstrates how steep learning curves form in real teams:

• Clear utility: Every improvement shows up in a department’s daily work.
• Fast feedback: Users are practically “in‑house”; releases take effect immediately.
• Broad scope: From business logic to data to UI—internal applications often span the entire stack.

With that, “just internal” becomes a career accelerant, both technically and communicatively.

The role of design sensibility: UI/UX as a bridge to users

The opportunity to try UI/UX is more than a personal interest—it signals how product work is conceived today. Even when developers don’t own design, sensitivity to user interfaces helps steer better decisions in code:

• Clarity: Good interfaces demand good domain models.
• Priority: User needs trump technical elegance.
• Coherence: Consistent UX requires consistent architectural thinking.

Katja’s media‑technology background underpins that sensibility.

Selecting learning paths: Fit over dogma

Katja’s refusal to prescribe a single learning path is refreshing. Whether tutorials, courses, school, or university—the right choice depends on personal learning style, and on the environment where you apply what you learn. Her journey through a HTL shows how practice‑oriented structure plus application can compound impact—especially when colleagues actively support growth.

For anyone considering a move into software, a simple plan emerges:

1) Start with experiments: Small exercises, tiny projects, varied languages and frameworks.

2) Add structure if needed: If self‑learning is tough, pick courses or a school that provides cadence and feedback.

3) Seek practice: Projects—internally, via internships, or in your first role—turn knowledge into skill.

4) Stay open: Interests can shift. Just like Katja’s focus shift sparked her “aha moment.”

Partnering with the business: Turning requirements into a team sport

When Katja describes herself being brought in to help “define IT requirements,” that looks like this in practice:

• Establish shared language: Clarify domain terms, use examples, define acceptance criteria.
• Surface conflicts early: What matters most? What can wait? What dependencies exist? What release cadence makes sense?
• Build commitment: When business and engineering frame requirements together, both understanding and accountability grow.

Quality begins at the requirement, not only in code.

The thread that ties it together: Confidence, context, growth

Summarizing Katja’s path, a pattern emerges:

• Confidence: Persist through a rocky start until the “aha moment” arrives.
• Context: Engage with real problems early—internal tools, real users, concrete requirements.
• Growth: Extend your role—from implementation to requirements work to user perspective.

This trio makes careers resilient and relevant. It explains how software professionals not only keep pace but steadily amplify their impact.

What teams can learn from Katja Hammer’s example

• Open side doors: Enable lateral explorations like UI/UX exposure—it pays off in product quality.
• Bring engineers into conversations early: The sooner engineering meets the business need, the tighter the solution.
• Cultivate learning environments: Pairing, reviews, mentoring—these accelerate consolidation of fundamentals.
• Respect learning styles: There’s no single correct path; fit and opportunities for practice are what count.

Closing: A clear, human path into a tech career

“Katja Hammer, Software Developer bei Doka” underscores what shapes a robust developer trajectory. Not a flawless start, but steady movement: from fundamentals to practice, from implementation to requirements, from technology to user perspective. Alongside the mindset to not be discouraged by setbacks or prejudice.

For us, that’s the encouraging message of this session with Speaker: Katja Hammer (Company: Doka GmbH): Your path can be imperfect. What matters is staying curious, taking responsibility—and seizing the moment when obligation turns into genuine enthusiasm.

• 

  

  Ronni Bjelosevic, DevOps Team Lead bei Doka

  DevOps Team Lead bei Doka Ronni Bjelosevic gibt im Interview einen Überblick über den Aufbau der Teams im Unternehmen, was dort neue Mitarbeiter erwartet und mit welchen Technologien gearbeitet wird.

  Watch now
• 

  

  Benjamin Schauer, Group Leader Digital Operation Tools bei Doka

  Group Leader bei Doka Benjamin Schauer umreißt im Interview die Organisation des Teams für Digital Operation Tools, was dort technologisch spannend ist und wie das Recruiting und Onboarding gestaltet ist.

  Watch now

• 

  

  Matthias Schmutzer, Mobile Developer bei Doka

  Matthias Schmutzer von Doka spricht im Interview über seinen Einstieg ins Software Development, mit welchen Aufgabenbereichen er in seiner aktuellen Arbeit zu tun hat und gibt Ratschläge für Leute, die selbst gerne mit Development starten möchten.

  Watch now
• 

  

  Michael Hahn, Corporate Software Architect bei Doka

  Michael Hahn von Doka spricht im Interview über seine analogen Anfänge im Programmieren, was die Aufgaben seines aktuellen Berufes umfassen und gibt Tipps für Neueinsteiger.

  Watch now