Programming as a Way of Thinking: The Developer Journey of Maximilian Haider (Denovo GmbH) — from HTL and a 2D Game to React, TypeScript, and NestJS

A conversation that sticks

In the session “Maximilian Haider, Full Stack Developer bei Denovo” (Speaker: Maximilian Haider, Company: Denovo GmbH), we encounter a path that resonates with developers at every stage: early curiosity, persistence, the joy of visible results—and the clear conviction that programming is, above all, a way of thinking. At DevJobs.at, we listened closely and distilled the key milestones, challenges, and practical lessons shared in this talk.

Maximilian tells his story without theatrics but with disarming authenticity. From the first 2D platformer he built with his younger brother at age twelve, to five years at HTL Villach and a deliberate move toward high-level development, to a full-stack role at Denovo where developers enjoy decision-making autonomy, carry responsibility, and meet regularly in a “Tech-Café” to exchange ideas. He also notes his civilian service in Lienz and the move to Graz in search of a “cool job.” Running through it all is a recurring theme: stick with it, learn with self-motivation, and sharpen your thinking.

Early spark: When curiosity becomes action

Maximilian’s technical interest didn’t appear out of thin air. From childhood on, he was “very technically enthusiastic,” as he puts it. Craftwork appealed to him less; instead, he had a powerful role model in his orbit: an uncle who was a successful programmer and consultant at Coca-Cola GmbH in Vienna. That proximity demystified the profession and made the goal tangible.

A second decisive catalyst came from hands-on exploration: at twelve, he and his younger brother sat down with a game engine (he no longer remembers which one) and built a “small 2D platformer, Jump & Run.” More than a childhood project, it offered the first clear feedback loop: I can imagine something, structure it, and make it run. Seeing an idea come alive on the screen—that sticks.

Two familiar building blocks of many developer journeys appear here: a nearby role model—and a self-initiated side project that turns curiosity into action. Together they lead to the place where real capability grows: doing the work.

HTL Villach: Breadth as foundation, focus as compass

At 14, Maximilian joined the HTL in Villach—five years he “successfully completed.” Those school years were broad: C, C#, JavaScript, Android, PHP, JSF—“really everything,” as he emphasizes. What might look like an eclectic mix is, in truth, a sturdy base on which specialization can grow.

Meanwhile, a personal compass emerged. Maximilian realized “relatively quickly” that high-level development fit him. He values “visual feedback” and enjoys design—seeing what he makes. That self-knowledge maps to today’s preferences: in the frontend, he feels at home in the TypeScript world, “happy in React”; in the backend, he “likes Node with NestJS.”

The lesson we note: breadth opens doors; focus creates depth. And stack choices flow not just from trends but from one’s way of working. If visual feedback is what motivates you, the frontend is a natural field; add the backend when you want end-to-end understanding. This is how full-stack can form organically.

Civil service, roots, and a deliberate move

After HTL came civilian service in Lienz, his hometown. Then he moved to Graz “in search of a cool job.” The sequence is straightforward and telling: fulfill obligations, keep roots, then expand your radius. It marks the transition from protected learning contexts into practice.

Full Stack at Denovo: Beyond the “code monkey” cliché

Asked what developer work at Denovo feels like, Maximilian draws a clear picture. He immediately dismisses the cliché of the “code monkey” who “types over some code for eight hours” and goes home. Instead, day-to-day work is integrative: from planning and refinement to technical support for Product Owners—“everything is included.”

A defining feature is decision-making autonomy. Developers have “full decision-making power” over which tools to use and how to use them. That invites experimentation, learning, and joint deliberation.

The “Tech-Café” as a living culture of discourse

Once or twice a week, teams meet in a “Tech-Café.” They discuss current topics, problems and solutions, introduce new technologies, and consider “pros and cons.” This rhythm institutionalizes what many teams long for: ongoing exchange that happens proactively rather than only in the heat of project delivery.

The effect is twofold: knowledge spreads, and decisions gain quality through shared reflection. This freedom, however, also calls for responsibility—a point Maximilian addresses directly.

Freedom requires responsibility: Proposals that have “hand and foot”

Where developers propose technologies and shape decisions, responsibility follows: you should have “really thought it through” before bringing something in. Shipping “something unconsidered” isn’t how things are done. That stance aligns with production-grade practice: decisions are promises to teammates and users, and they deserve depth.

That applies to technology choices and to process.

Scrum in practice: Estimation, commitments, getting better

Maximilian describes “involvement in the Scrum process” as a daily exercise in responsibility. The recurring challenge is meeting sprint commitments—and correctly estimating effort. As developers we “tend to under- or overestimate.” The good news: “you definitely get better at it over time.”

Our take: estimation isn’t innate talent; it’s skill, forged by repetition, feedback, and team reflection. The Tech-Café contributes by spreading models and experiences that reduce uncertainty.

“Programming is a way of thinking”: The core of Maximilian’s philosophy

Perhaps the most striking statement: programming isn’t a weekend workshop; it’s a way of thinking. It requires you to “stick with it,” bring “self-motivation,” and recognize that “90 percent” of programming happens “in your head.” He means the logical and analytical processes we structure and then implement in code.

From this perspective, language choice is secondary—at least at the beginning. Maximilian suggests not fixating too early on a particular language; the thinking matters more. Teams feel this truth daily: if you master patterns, abstractions, and systematic reasoning, new stacks get easier.

Education helps—but isn’t required

Maximilian went to HTL to learn programming. Still, he’s clear that formal education is “not necessary.” It offers an “extremely good foundation,” but “nowadays there are so many resources” to teach yourself. The deciding factor is motivation—and owning a project you truly want to finish.

This isn’t an argument against school; it’s a call for ownership: learning is possible if the spark is there and you keep at it. What helps is a concrete use case.

Start with your hobbies: Turn problems into projects

Maximilian recommends picking a topic you care about outside of programming—“some hobby.” He offers fishing as an example: build an app to record which fish you caught. The pattern is universal: choose a small, genuine process you care about and build a tool for it.

This approach has outsized learning benefits. It forces you to walk the whole path—from idea through data modeling, input, presentation, persistence, to finishing. That last step matters most: finishing sharpens priorities, trains scope management, and gives you the success experience that propels the next learning loop.

From high-level comfort to full-stack competence

Maximilian favors high-level development with visible feedback. Frontend with React and TypeScript, backend with Node and NestJS—these environments enable quick iteration and immediate results. Working this way develops product sensibility early: how does an interface behave? How do data flow? How does performance feel?

Full-stack emerges organically here—not as a badge, but as the outcome of wanting to understand things end to end, from UI to API. Practically, that means recognizing connections and shaping deliberate interfaces—the opposite of “code monkey” work.

Autonomy as a learning engine

The “full decision-making power” developers have at Denovo is more than a pleasant work condition—it’s a learning engine. Choosing means justifying. Justifying deepens understanding. The weekly Tech-Café cements this cycle: you bring something, show it, discuss pros and cons, and then decide together whether to adopt it.

Teams looking for similar outcomes can draw three simple principles from Maximilian’s account:

• Create spaces for judgment: regular forums to test, compare, and decide.
• Make responsibility visible: the proposer helps drive adoption—expect proposals to have “hand and foot.”
• Cultivate results-orientation: only what holds up in practice stays; everything else remains an experiment.

These principles aren’t tool-agnostic platitudes; they frame how you engage with tools. They make development resilient.

Learning to estimate: Why uncertainty is normal—and gets better

The tendency to under- or overestimate is no character flaw; it reflects complexity. Maximilian’s point that it “definitely gets better over time” is encouraging. Experience comes from comparing plan to reality, from team reflection—what was missing?—and from becoming aware of risk.

In practice, questions help: Where are we inexperienced? Where is the biggest unknown? What can we prototype early? A forum like the Tech-Café shines here because it layers perspectives: does someone cover our blind spots? Are there prior experiences in the team? Learning from many heads is the fastest way to reduce estimation error.

Keep at it, don’t cut corners: The ethos behind competence

Against the lure of shortcuts, Maximilian sets a clear stance. Programming isn’t something you “sit down for one afternoon” or attend “a few seminars” and then can do. Instead: “stick with it.” This persistence doesn’t have to be grim; it’s fueled by genuine interest—by finding joy in creating, understanding, and improving.

We see a mature view of competence here: it arises when interest, repetition, and real outcomes converge. That’s why side projects are so powerful—they’re self-motivated and results-oriented.

Concrete guidelines for newcomers and teams

From Maximilian’s remarks, we extract practical guidance for both newcomers and teams:

For newcomers

• Start with your own use case: pick a hobby or everyday process you truly care about. Build a tiny tool for it.
• Prioritize thinking tools over tool identity: early on, language choice is secondary. Logic, structure, and clean reasoning matter more.
• Seek visible feedback: if visible results motivate you, use interfaces and small apps as your learning ground. It sustains momentum.
• Finish what you start: narrow scope and ship. Finishing drives the most learning.
• Learn continuously: not “one afternoon” or “a seminar,” but regular practice. Small dose, high frequency.

For teams and organizations

• Anchor decision-making autonomy: let developers propose and adopt tools—with the expectation that proposals have “hand and foot.”
• Institutionalize exchange: formats like a “Tech-Café” let you reflect on solutions, problems, and new tech together.
• Treat process involvement as core: planning, refinement, and technical support aren’t side tasks; developers are part of the entire value stream.
• View estimation as a learning path: mistakes are normal. With transparency and feedback, estimation quality improves over time.

These aren’t abstract ideals; they mirror the living practice Maximilian describes. They braid autonomy, responsibility, and learning into a robust development routine.

Quotes we took away

• “As a developer … you do much more than you might think at the beginning.”
• “We … have … full decision-making power over what we use.”
• “You don’t want to ship anything unconsidered.”
• “You have the challenge of meeting the sprint commitment.”
• “Programming … is … a way of thinking … 90 percent … happens in your head.”
• “I … am … absolutely not of the opinion that any kind of education is necessary.”
• “If I go fishing … I’d like to write an app to record the fish I’ve caught … and stick with it until it’s finished.”

Each line marks an anchor in the talk: role, responsibility, process, mindset, entry point—clear, concise, and practical.

Conclusion: A path that encourages

“Maximilian Haider, Full Stack Developer bei Denovo” reveals a developer journey that encourages because it’s relatable. A role model in reach, a self-built game, five years of broad learning, a deliberate affinity for high-level work with visible feedback—and a professional routine that treats developers as co-creators: with decision-making autonomy, reflection formats like the Tech-Café, and the responsibility to make thoughtful choices and honor commitments.

The backbone of this story is a recurring idea Maximilian emphasizes: programming is a way of thinking. If you cultivate that thinking—logical, analytical, structured—and keep at it, you’ll find your path. Whether on the foundation of HTL or self-taught: resources abound, but there’s only one reliable engine—self-motivation paired with projects you actually finish.

Our takeaway: start with something that matters to you. Work visibly, learn in exchange, decide deliberately—and stick with it. Step by step, that’s how careers form that don’t just serve technology but shape reality. Exactly as Maximilian Haider showed in his story.

• 

  

  Managing Infrastructure At Scale

  Lukas Korl von Denovo gibt in seinem devjobs.at TechTalk Einblicke in die Arbeitsweise, wie das Unternehmen mehrere hundert Server für viele unterschiedliche Projekte betreibt.

  Watch now

• 

  

  Mattias Rauter, Managing Partner von Denovo

  Managing Partner von Denovo Mattias Rauter gibt im Interview Einblicke in die Devteams, wie das Recruiting und Onboarding abläuft und mit welchen Technologien gearbeitet wird.

  Watch now

• 

  

  Jacqueline Rinnhofer, Full Stack Developerin bei Denovo

  Jacqueline Rinnhofer von Denovo spricht im Interview über ihre späten Anfänge in der IT bis hin zur aktuellen Arbeit im Full Stack Development und gibt Tipps für Neueinsteiger.

  Watch now
• 

  

  Tobias Stangl, Mobile Developer bei Denovo

  Tobias Stangl von Denovo redet im Interview über seinen frühen Einstieg in die Software Entwicklung bis hin zum aktuellen Job als Mobile Developer und gibt Tipps für Anfänger

  Watch now
• 

  

  Michael Haar, Full Stack Developer bei Denovo

  Michael Haar von Denovo teilt im Interview seine Erfahrungen als Quereinsteiger ins Full Stack Development und was seiner Meinung nach wichtig für Anfänger ist.

  Watch now