From Languages to Databases: How Manuel Reichstamm at DBConcepts GmbH builds iterative, maintainable software

An unexpected entry into tech

Watching the session “Manuel Reichstamm, Database Developer bei DBConcepts,” one thing stands out immediately: Manuel did not begin as a tech die-hard. He completed a general AHS with a focus on languages and admits he wasn’t particularly excited about technology at first. What he did have was curiosity and openness: he was “always a bit open to all sorts of things.”

The turning point was serendipity. He “came across a HTL Kolleg,” which he describes as a mix of business and computer science. That mix became his springboard. Instead of an abstract curriculum, he learned early on how technical decisions intersect with business processes—a perspective that resonates throughout his current work.

C as the foundation, databases as the spark

His formal programming journey started “classically with C.” Beginning with C often means learning to think precisely, to model data deliberately, and to focus on essentials. It’s a demanding foundation that pays off later.

The real spark came in year two: “in the second year there was already a focus on databases. And back then I already thought this could interest me longer term.” For many developers, that’s the moment when theory meets concrete structure: model data, enforce consistency, optimize queries, represent real processes. Databases are precisely where technology and business meet—and that’s the cross-section Manuel works on today at DBConcepts GmbH.

Practice over fiction: teachers from industry

Equally formative was the way he learned. Manuel recalls projects that were “very practice-oriented,” thanks to teachers “coming from the field.” These were not “wild fictitious examples,” but tangible, realistic scenarios. That difference is powerful: when examples feel real, relevance clicks, and motivation follows. As he puts it, “it was so practice-oriented that I thought this is pretty exciting and the area really interests me.”

From an editorial perspective, that’s a core lesson for technical education: practice accelerates learning. It also creates a sense of agency—what I build today solves a real problem tomorrow.

A deliberate choice: a job in the database world

By the end of his program, Manuel had made up his mind: “that’s why I decided to look for a job in the database area and fortunately I found one.” This wasn’t a shot in the dark. It was grounded in experience, curiosity, and concrete practice. His verdict is unequivocal: “I definitely haven’t regretted it.”

This signals more than technology preference. It shows he has found a mode of working that fits: close to the problem, close to the customer, with a focus on quality over the full lifecycle.

What a Database Developer really does at DBConcepts GmbH

Say “database developer,” and many think of SQL, stored procedures, schema design. At DBConcepts GmbH, Manuel’s role spans far more—and most notably: it is customer-facing.

From process to software: developers in the customer conversation

Work doesn’t begin in the IDE. It begins with understanding:

• “align precisely with the customer on what processes the customer has”
• “and how we can develop this in software so that the processes are easier for the customer”

This is requirements work as a team sport—not delegated to a separate consulting layer. Manuel stresses: “we as developers are not just in the background where some consultant tells us what the customer needs, but we are also the ones who align with the customer.”

That direct line between engineers and the domain is a quality marker. It shortens feedback cycles, minimizes misunderstandings, and deepens understanding of real user pain points.

Iterative delivery instead of a big bang

Manuel describes an incremental approach as standard operating procedure:

This is pragmatic, low-risk delivery: early value, early feedback, less friction. Especially for data-heavy systems, iteration is essential—data models and analytics tend to reveal their true behavior only under real-world use.

Ownership beyond go-live: maintainability by design

A second principle stands out: ownership across the entire lifecycle.

Continuity forces good engineering. Knowing you’ll be the one maintaining the solution changes how you build it:

• “how do we actually develop things so that they are as maintainable as possible for us”
• “we continue working with them in the end and we have to still understand them”

This is a strong statement for maintainability as a guiding principle. It’s not about short-term acceptance—it’s about systems you can still understand in a year or two.

Three principles we distilled from the session

Manuel’s story surfaces repeatable patterns. From our DevJobs.at vantage point, we see three principles that teams can adopt:

1) Developers should meet the domain directly

• Direct conversations reduce friction and translation loss.
• Domain knowledge grows inside the team, not only in documentation.
• Decisions become traceable because they rest on real processes.

2) Deliver in work packages, not in one sweep

• Small, testable units are the best feedback drivers.
• Changes surface early, before they become painful.
• Trust grows through regular, usable increments.

3) Treat maintainability as a project goal

• “We have to understand this later”: architecture, naming, testing, and documentation turn into investments, not overhead.
• Iteration enables maintainability to be built and verified over time.
• Post-go-live maintenance creates learning loops: yesterday’s build reveals today’s edge cases—tomorrow you’re better.

Degree optional. Grit required.

A third thread in Manuel’s journey is his view on formal education. He’s explicit:

What matters more is attitude and persistence:

• “the necessary stamina and heart to really read into the subject”
• “it may be depressing a few times at the beginning … but solutions often appear when you don’t expect them”

He also points to the wealth of learning resources: “in our world there are plenty of opportunities … you can learn a lot through self-study.”

For newcomers, that’s an invitation. Learning is accessible—but it requires perseverance. Especially in data engineering and database development, where abstractions can feel heavy at first, building understanding through small wins is key.

From calculator to product idea: project-based learning that sticks

Manuel gets very concrete about how to begin. First learn the basics, then implement a small practical example end-to-end. The classic:

Why does this work? Because it contains the genetic code of real software—without the noise:

• Validate input (is it a number?)
• Separate logic (operations and error cases)
• Present output clearly
• Extend in steps (multiplication, division, memory, history)

From there you can generalize a path into database development:

1) Choose a tiny, concrete domain problem.

2) Identify the data: entities, attributes, relationships.

3) Draft a minimal data model—keep it deliberately simple.

4) Wire it to a small app—CRUD is enough for a start.

5) Expand in increments, collect feedback, adapt the model.

It’s the same approach Manuel describes at work—just recast as a learning loop. Build, test, adapt. Turn practice into understanding.

Why Manuel’s approach improves engineering quality

His way of working contains several quality levers:

• Early domain understanding: process semantics guide better data models.
• Iteration over perfectionism: reduce risk step by step.
• Maintainability as a first-class concern: naming, structure, and clear responsibilities become investments because “we have to still understand it later.”
• Real feedback cycles: users and processes change; iterative handovers are the antidote to never-ending projects.

Practical moves for aspiring database developers

Translating Manuel’s principles into day-to-day habits, we suggest:

• Talk to users before you draw the schema. Understand the process first.
• Start your data model small. Let real use cases grow it.
• Plan in work packages. Make each iteration testable by the customer.
• Build for maintainability early. Favor clarity over cleverness.
• Prioritize feedback after each partial delivery. Bake changes into the next iteration.
• Practice via small projects. From a calculator to a tiny app with persistence—step by step.

These moves are not theory. They reflect the working reality Manuel lays out—and they apply regardless of programming language or database engine.

The quiet success factor: small doses of self-belief

Manuel acknowledges how frustrating early steps can be—and how solutions sometimes show up “when you don’t expect them.” Anyone who has learned to program will recognize this pattern. The countermeasure is a process you can trust:

• Frame the problem, cut it down, solve incrementally.
• Allow breaks and perspective shifts.
• Return, verify, continue.

The way Manuel and the team at DBConcepts GmbH structure projects—“in different work packages,” handing over partial increments, testing, and adjusting—implements exactly such a process. It protects against overwhelm by inserting learning and usefulness into the cadence of delivery.

Iteration and maintainability: two sides of one coin

Many teams treat “delivery” and “maintenance” as separate phases—build first, clean up later. Manuel’s perspective flips that. If you know you’ll maintain the solution, you design for maintainability today. If you deliver in iterations, you build and validate maintainability continually—not in a wishful, late-stage hardening sprint.

This coupling is especially valuable for database-heavy systems. Requirements evolve; data models must adapt. Maintainability starts in the initial customer conversation, continues in the structure of work packages, and becomes real in operations—where “we have to still understand it.”

Our takeaway from “Manuel Reichstamm, Database Developer bei DBConcepts”

Manuel’s journey shows there are many ways into software. What matters is the willingness to engage with real problems, to learn iteratively, and to carry responsibility beyond go-live. Three lines echo in our notes:

• “not just rigid development” — engineers belong in the customer conversation.
• “structure into work packages” — small deliveries build clarity and trust.
• “as maintainable as possible” — those who maintain tomorrow build better today.

For us, this is the essence of modern database development: practice, iteration, ownership. And for anyone starting out, Manuel offers a simple on-ramp: begin small, keep at it, learn by doing. Even a calculator can be the first step on a long and rewarding path.