enjoy IT GmbH

Established Company

Show all Videos

Thomas Hochgatterer, Back End Developer bei enjoy IT

Thomas Hochgatterer von enjoy IT gibt im Interview Einblicke in seinen Werdegang mit dem Prorammieren, wie sich sein Arbeitsalltag als Back End Developer gestaltet und gibt Tipps für Neueinsteiger.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In "Thomas Hochgatterer, Back End Developer bei enjoy IT," Speaker Thomas Hochgatterer traces his path from a middle-school programming elective (Pascal at 14) through the HTL für EDV & Organisation and a business informatics degree to backend development. He outlines his role processing data behind the scenes, enabling manipulation, integrating interfaces, and delivering data to frontends; he joins projects from effort estimation through development and coordinates continuously with frontend teams. His advice: start with programming fundamentals using simple scripting languages, progress to object-oriented concepts (for him from Visual Basic Script to Java), and learn by doing to find your direction.

From Pascal at 14 to Back-End at enjoy IT: The Developer Journey of Thomas Hochgatterer

Why this devstory matters

In our DevJobs.at series, we focus on real developer journeys—no hype, no shortcuts. In this session, we follow “Thomas Hochgatterer, Back End Developer bei enjoy IT” as he traces a clear, grounded path: an elective programming class in middle school, HTL in EDV and Organisation, a business informatics degree, hands-on web work during his studies, and finally a role he genuinely enjoys in the back end at enjoy IT GmbH.

What stood out to us in Thomas Hochgatterer’s account is its steady cadence: learn fundamentals, stay curious, pick up practice early, and let direction emerge from doing. There’s no dramatic pivot or instant mastery—just consistent movement from the basics to building and maintaining the systems that make software work.

First lines of code: An elective, curiosity, and Pascal

Thomas’ entry into programming began with a simple decision—sign up for a programming elective without knowing exactly what to expect:

“We had a programming elective. I just signed up. I didn’t really know what was coming. … I think we started with Pascal. I was about 14 years old.”

Pascal isn’t a fashionable beginner’s language today, and that’s precisely the point: the first language is a vehicle for thinking. Variables, control flow, small programs—once you grasp these, you have a foundation that transfers. Thomas kept going because that foundation sparked interest rather than intimidation.

HTL as foundation: EDV, organisation, and the basics

Curiosity led Thomas to the HTL for EDV and Organisation, where structure and practice came together. One detail he emphasizes is how effective it was to start with a scripting language:

“You try to learn the basics first, generally in programming. … I would recommend starting with simple scripting languages where you just go through things step by step. For me, that was Visual Basic Script at the beginning in HTL.”

This is refreshingly pragmatic. Beginners don’t need complex toolchains; they need short feedback loops. Scripting languages keep the cycle—idea, code, result—tight. For Thomas, Pascal and then Visual Basic Script served as on-ramps to concepts. The vehicle can vary; the destination is the same: understanding.

University: Business informatics and first web experience

After HTL, Thomas started a business informatics degree and, importantly, combined theory with practice:

“During my studies I also gained a bit of experience on the side—as a web developer. I also did some frontend work there.”

That early exposure to real-world constraints matters. Building web projects introduces practical concerns that textbooks often gloss over—deadlines, data flow, and coordination. The fact that Thomas touched the front end “partly” was no detour; it broadened his perspective. Later, in the back end, that empathy for frontend needs becomes an asset.

Finding home in the back end

Over time, Thomas gravitated toward the back end:

“Somehow I ended up in the back end, and I really like it.”

In a field with “so many possibilities” (as he puts it), direction often emerges through accumulated experience rather than upfront design. Back-end work resonates if you care about data, integrations, interfaces, and reliability. For Thomas, this wasn’t a dramatic epiphany but a natural evolution—from scripting to object-oriented thinking to the discipline that keeps systems running.

What back end means to Thomas: Data, interfaces, reliability

Thomas describes the essence of his work with welcome clarity:

“Basically, as a back-end programmer you make sure to process data in the background, enable people to manipulate data, connect interfaces, and then make [that] available to a front end or other interfaces.”

We read three pillars in this description:

Prepare data: structure, consistency, and reconciling information from different sources.
Enable manipulation: create, update, and delete through well-defined functions and endpoints—safely and predictably.
Connect and provide interfaces: integrate systems and expose your own system to others, often to front ends or other services.

Note what’s missing: buzzwords. By focusing on fundamentals, Thomas highlights the real promise of back-end work—making everything else possible.

Project role: From effort estimation to ongoing alignment with the front end

A practical dimension Thomas highlights is his involvement from the very start of a project:

“I’m basically involved from the beginning. I start with effort estimation. We think together about how we’ll implement it, how long we’ll need. And then it goes straight into the development phase as part of a project team. … We have ongoing alignments, including with the frontend developers, and that’s how our day-to-day runs.”

Two insights stand out:

Back-end work begins well before the first line of code. Understanding the problem, estimating complexity, and weighing options prevents costly detours. Early involvement lets you surface risks and shape APIs that won’t box the team in later.
Ongoing collaboration with the front end is a prerequisite, not a preference. Requirements translate to schemas, endpoints, and error scenarios. When both sides stay aligned, the result isn’t just technically correct—it fits the use case.

Learning path and advice: Start simple, go step by step, add OOP

Thomas’ learning arc forms a pattern we see repeatedly among solid practitioners:

“You try to learn the basics first, generally in programming. … I would recommend starting with simple scripting languages where you go through things step by step. … I then continued with Java. That’s where object orientation came in.”

Behind this is a clear progression:

Start with scripting: short loops, quick wins, and focus on logic over tooling.
Add object orientation: once the basics are grounded, OOP opens doors to larger structures—classes, encapsulation, abstraction, reuse.
Let practice guide direction: “In day-to-day work you really learn which direction it should go. There are so many possibilities.” Learning is not linear; it’s guided by interest, opportunity, and feedback.

What we at DevJobs.at took away from the session

From our conversation with “Thomas Hochgatterer, Back End Developer bei enjoy IT,” four messages stick:

Curiosity leads to direction: one elective course can set a trajectory. Persist, and you’ll find your domain—Thomas’ is the back end.
Foundations beat features: basics first—scripting and step-by-step thinking, then OOP. With that base, new tools are easier to place.
Back end is interface work and teamwork: data quality, integrations, and collaboration with the front end shape real product outcomes.
Join projects early: effort estimation and shared planning prevent dead ends and align expectations for everyone.

Practical takeaways for aspiring back-end developers

Thomas’ story yields clear, actionable steps—no shortcuts, just steady progress:

Start small on purpose: pick a simple scripting language with fast feedback. Practice loops, conditions, and functions. Keep the edit–run–understand cycle short.
Build routine: solve small problems repeatedly and explain to yourself what your code does. Treat errors as feedback.
Learn OOP with a language that makes sense to you: Thomas mentions Java as the point where OOP “came in.” Use classes and objects to model everyday problems.
Combine practice with theory: like Thomas’ web work during university, side projects anchor concepts in real requirements, especially valuable when you later coordinate with front ends.
Train interface thinking: for every function, ask what goes in, what comes out, and what can fail. This mindset prepares you for back-end realities where interfaces are central.
Practice collaboration: plan communication with front-end developers and stakeholders from the start. Early alignment prevents later friction.
Participate in estimation: being part of effort estimation sharpens your sense of complexity and helps the team set realistic goals.
Allow yourself to choose a direction: “There are so many possibilities.” If data flow, integrations, and reliability motivate you, the back end may be your home.

The quiet appeal of the back end: Why “in the background” isn’t invisible

Thomas describes back-end work as happening “in the background.” That isn’t anonymity—it’s a mark of reliability. When back ends are well designed, users don’t notice them because everything just works. Data is consistent, interfaces speak the same language, and systems remain coherent.

It’s also a mindset: the focus is not surface but substance. Preparing data, enabling manipulation, and providing interfaces creates the foundation upon which experiences and products are built. The fact that it remains largely unseen is precisely why it matters so much.

Quotes to remember

Several lines from Thomas serve as simple, durable anchors:

“We started with Pascal. I was about 14 years old.”

“For me, it was Visual Basic Script at the beginning in HTL. … I then continued with Java. That’s where object orientation came in.”

“As a back-end programmer you process data in the background … connect interfaces … and make [that] available to a front end.”

“I start with effort estimation … we think together about how we’ll implement it, how long we’ll need.”

“There are so many possibilities, and for me it just became back-end development.”

“Somehow I ended up in the back end, and I really like it.”

These aren’t slogans; they outline a progression. They also encourage persistence: if you keep moving, you’ll sharpen your profile—without a grand master plan, but with a solid grasp of fundamentals and teamwork.

Conclusion: A dependable path—step by step to the back end

The devstory of “Thomas Hochgatterer, Back End Developer bei enjoy IT” isn’t about headline-grabbing tech stacks. It’s a credible blueprint for a sustainable career:

start early and stay curious,
put fundamentals before flash,
mix practice with theory,
choose and deepen your direction,
take responsibility across the project lifecycle—from estimation to collaboration.

For us at DevJobs.at, this is the kind of path that lasts. It turns code into quality, interfaces into connections, and projects into products that simply work. Or, in Thomas’ own words, you end up where “you really like it”—and that’s where you become most valuable to your team.

More Dev Stories