I finished my Master's in March 2026. And honestly, my first reaction was not celebration. It was something closer to quiet relief mixed with a strange feeling of "wait, that's it?"
Two and a half years. A thesis. Countless late nights. A part-time job running alongside it. And then one day, it was done.
Now that I have had some time to sit with it, I want to write about what this programme actually was, not the official version you read on a university website, but what it felt like from the inside.
Why I chose this programme
When I was looking for a master's, I knew one thing clearly: I did not want to sit in a classroom and study theory for two years. I had already been working. I had already built things. What I wanted was a programme that would push my thinking further, not just add bullet points to my CV.
Global Software Development at Hochschule Fulda caught my attention because it was entirely in English, which immediately felt right. It was international. It was applied. And it had a very specific focus on distributed systems and modern software at scale which is the kind of systems I was actually working with, or wanted to work with.
I also liked that it was not trying to be everything. It had a clear identity. And that clarity was something I trusted.
The courses that actually changed how I think
Not every module hits equally. That is just the reality of any programme. But a few of them genuinely shifted something in how I approach problems.
Cloud Computing was one of them. Before that course, I understood the concept of cloud infrastructure at a surface level. After it, I started thinking differently about trade-offs, cost, scalability, failure modes, security. I began asking "what happens when this breaks?" more than "how do I build this?" That shift matters more than I expected.
Distributed Applications was another. Once you start thinking seriously about services talking to each other across networks, you realise that most of what makes software hard is not the code itself. It is the coordination. The architecture. The decisions you make before you write a single line.
Test-Oriented Development stuck with me too but not because it was technically the hardest module, but because it reframed how I think about quality. Testing is not a phase you do at the end. It is a way of thinking from the beginning. That sounds obvious when you say it, but it takes a while to actually feel it in practice.
And then there were modules like Intercultural Project Management and User-Centered Development that some people might dismiss as "soft." I did not. Working across cultures is genuinely difficult. Communicating clearly to someone who thinks and works differently than you is a skill. I am glad the programme took it seriously.
The part nobody warns you about
Doing a master's while working part-time is hard in a way that is difficult to describe until you are in it.
There were weeks where I was debugging a Power Automate flow at work, trying to understand a distributed systems paper in the evening, and drafting thesis sections on weekends. It was not glamorous. Some weeks I was just surviving.
But I chose this approach deliberately. I wanted the theory and the practice to happen at the same time. And looking back, that decision was right even when it was exhausting. Concepts from the programme would show up directly in my work. Problems from work would suddenly make sense through something I had just studied. The two reinforced each other in ways that would not have happened if I had studied in isolation.
I chose this approach because I wanted to build real understanding, not just academic knowledge. And I think it worked because I can look at something I built at work and trace a direct line back to something I learned in the programme.
The thesis
This was the hardest and most meaningful part.
I chose to write about quality assurance for AI-based copilots and agents. The reason was simple: I was working with these systems at WEPA Digital, and I kept running into the same problem. How do you actually test an AI agent? How do you know it is reliable? How do you measure fairness, robustness, security not just accuracy?
Traditional QA frameworks are built for deterministic systems. AI agents are not deterministic. They hallucinate. They behave differently depending on context. They can be manipulated. The standard approaches just do not cover this properly, and I found that gap genuinely interesting.
So I built a framework. A proper one with a test matrix, standardised test cases, a Python-based test manager, an evaluation engine, structured logging, and automated reporting. I implemented it across two environments: Azure AI and Copilot Studio.
The Azure AI side worked well. FastAPI backend, Azure OpenAI integration, automated pipelines. Clean and testable.
Copilot Studio was a different story. API constraints, authentication barriers, limited programmatic access, full automation was simply not possible. So I adapted. I built a hybrid model where test cases were generated and structured automatically, then executed manually in Microsoft Teams, with results fed back into the reporting system. Not ideal. But realistic. And I think that honesty about limitations made the thesis stronger, not weaker.
The conclusion I kept coming back to: systematic QA for AI is not optional. It is a necessity. We just do not have all the tools yet. That felt like an honest and important thing to say.
What studying internationally actually meant
I have lived in Tunisia, Bahrain, and Germany. So the international aspect of this programme was not new territory for me. But it still added something.
When you work and study with people from genuinely different backgrounds, you start noticing how much of what you assume is universal is actually just familiar. The way you structure an argument. The way you give feedback. The way you handle disagreement. None of that is universal. And once you see it, you cannot unsee it.
This made me a better communicator. A more careful listener. Slightly more patient than I used to be.
Looking back
I am not going to pretend the master's was perfect. Some modules felt disconnected from what I was actually doing in the industry. Some deadlines were brutal for no obvious reason. There were moments where I genuinely questioned whether the effort was worth it.
But the overall arc? Yes. It was worth it.
Not because of the degree itself though that matters too. It was worth it because of the way it changed how I think. I approach problems differently now. I ask better questions. I am more comfortable with uncertainty and more disciplined about how I work through it.
I went in wanting to become a better software engineer. I came out thinking more like a systems engineer, someone who cares not just about whether something works, but about why it works, and what happens when it does not.
That shift is what I will carry forward.