A path that wasn't exactly straightforward: From special education to embedded software
HKA alumnus Dennis Griebler on bold career changes, instructive setbacks, and a fascination with technical problem solving
From working with people to working with microcontrollers: Dennis Griebler's career path is anything but conventional. After almost completing his studies in the social sciences, he decided to make a radical new start at Karlsruhe University of Applied Sciences (HKA). Today, he works as an embedded software engineer. In this interview, he explains why doubts are part of life, how a grade of “5.0” became a turning point, and what makes studying at HKA so special.
HKA: Mr. Griebler, looking at your résumé, it's striking that your path to computer science wasn't a straight line. You originally came from a completely different direction. What was your original vision?
Dennis Griebler (DG): That's right, my path wasn't linear. After graduating from high school, I had a clear idea: I wanted to “do something with people.” I was interested in education and psychology. To test this out, I completed a federal voluntary service program at a specialist clinic. I enjoyed the work of the psychologists and social educators there, so I enrolled to study special education/inclusion studies in Görlitz.
You studied that for three years. When did the break come?
DG: On paper, I found the course exciting, but the real catalyst for change was my semester abroad in Australia. At the time, I wanted to know how special education works internationally, as it is a discipline from the German-speaking world. In Australia, I was suddenly torn out of my familiar environment. Without the influence of the people at home who might have encouraged me to continue on this path, I was able to reflect freely.
There, I realized that I am inherently much more interested in technical problems and their solutions than in providing special education support to people. This is a very honorable and heartfelt profession, but I simply couldn't imagine doing it for 40 years. I lacked the technique.
Nevertheless, breaking off after three years is a big step. What moved you back then?
DG: I had two very strong beliefs at the time. Firstly: "I need a straight CV - whatever I start, I'll finish." Secondly, I saw doubt as a bad thing. I thought you had to rise above doubt and just get on with it. Today I see it differently. Doubts are sometimes important indicators. Back then, however, it was a tough battle against my own upbringing and the expectation that I shouldn't fail. But the realization that my strengths lie elsewhere was stronger in the end.
Why did you choose Karlsruhe University of Applied Sciences for your new start?
DG: For one thing, there was the regional connection. I come from the Southern Palatinate. Kaiserslautern and Karlsruhe were close by. But the decisive factor was the information material from the HKA. There was a teaser video for Business Informatics that highlighted the special features of the university: very small groups and close contact with the lecturers. This is exactly what I had already appreciated in Görlitz and wanted to keep. I didn't want to go to an anonymous mass university. The practical relevance was also extremely important to me. My first degree course was very theoretical at times and I often realized during the practical phases that it didn't fit. I wanted to go to a university where what I learned was directly related to my future job.
You then completed a Bachelor's degree in Business Informatics and a Master's degree in Computer Science here at the HKA. Was there an "aha moment" during your studies that showed you: This is the right place for me?
DG: Yes, absolutely. Business informatics is a very broad field with many different career options. The "click" moment came in the "Software Architecture" lecture with Professor Jürgen Zimmermann. That's where I decided: I would become a software developer.
However, it was a bumpy start. In the third semester, I worked part-time as a warehouse worker at Mercedes-Benz in Germersheim, doing shift work. As a result, I missed more than half of the software architecture lectures. With Mr. Zimmermann, the slides were barely comprehensible without the spoken word. I tried to memorize the slides and failed with a straight 5.0. I had expected at least a 3.0 and was shocked.
How did you deal with this setback?
DG: The next semester, my job as a warehouse worker was over and I changed my learning strategy. Professor Zimmermann had a concept in which you realize a larger software project piece by piece using many tools of modern software development. I didn't copy the available sample solution, but made the effort to implement the project myself in order to understand why these tools were needed. Suddenly it "clicked" and my enthusiasm for software design and development was there. The practical application was the key. I then passed the repeat exam with a 1.0. So it was worth it.
Let's take a look at your Master's thesis. What is the background to this?
DG: The automotive industry is undergoing a change in which vehicle development is increasingly being viewed from a software perspective instead of the traditional hardware perspective. Software is seen as an important competitive factor. It can be expanded and modified quickly and can also be offered to customers after the car has been purchased, for example. As software runs on hardware, the interlocking between the two is a decisive factor in how well these extensions and changes can be implemented and how long this takes. The aim is to completely decouple software from hardware. This means that the software can be developed independently of any specific hardware and does not need to know which hardware it will later run on.
Traditionally, however, software in the automotive industry is very strongly tied to the hardware - especially software that is embedded in control units. Control units are small hardware components (e.g. a door control unit) that are connected to sensors (e.g. power window switches) and actuators (e.g. power window motors) and perform certain control, monitoring and regulation tasks (e.g. electrically raising the window on the driver's side). There is still research potential here, particularly in how to make this software in control units more flexible, i.e. how to make it more independent of the hardware.
So what was the content of your final thesis?
DG: I approached this research potential from an architectural perspective. The central question was: How must software for control units be structured and linked together so that hardware and software are completely decoupled from each other and become more flexible? You can see a rough representation of the architecture I developed in the image [referenzarchitektur.jpg]. In this picture you can see five rectangles that are connected to each other. These five rectangles are my proposal on how to divide software for control units at the highest level. Each rectangle has a specific functional responsibility in the picture. For example, the lowest rectangle, the switching domain, is responsible for switching between the rectangles above it. The connection between two rectangles describes the provision of functionality (round circle) or the use of functionality (open, semi-circular circle). In my work, I have worked out the inner structure of these rectangles and begun to clearly define the functionality behind the round circles.
My proposed architecture is general in nature, independent of any specific product, and represents a reference architecture. This means that it can be consulted as a template in specific software development projects to get an idea of how to structure control unit software and what the interfaces (connections between the rectangles) should look like. The promise behind the architecture is that it supports the development of flexible, hardware-independent control unit software. However, since vehicle software is very complex, numerous laws and standards must be observed, and various other factors play a role, my proposed architecture is not currently practical and is in a preliminary stage. Open tasks include, for example, the integration of IT security aspects and the continuation of the interface specification.
DG: SEGGER is a provider of software tools and hardware solutions specifically designed for the development, debugging and testing of embedded systems. Imagine a functional computer in the form of a small chip - such chips are found in many "intelligent" devices today. These chips are not as powerful as modern laptops, but they are inexpensive, small and often specialized. Among other things, my company provides tools with which customers can get their software onto these chips, verify them and search for errors. My job deals with the questions: How does developed software get from the customer's PC to the chip? And if software is running on the chip, how can a customer look inside the chip to see what is really happening there? Efficiency and speed are very important in answering these questions and are a huge competitive advantage.
When you think about your day-to-day work, what role does creativity play in such a technical profession?
DG: Creativity becomes important when standard solutions no longer work. When there is no ready-made solution, you have to think "outside the box". It's often about making trade-offs. A solution that is as secure as possible may be slower or more difficult to maintain. The exciting part is finding creative ways to increase security without compromising performance too much. You have to put new pieces together when the old ones no longer fit.
What advice would you give to first-year students who are interested in computer science at the HKA?
DG: Find a real project! Think about a problem in the real world that you want to solve. You learn the most when you try to transfer the knowledge from books or your studies into reality. You learn a lot of concepts and tools at university, but the value comes in the application.
Would you say that the HKA prepared you well for this?
DG: Definitely. I really enjoyed the time, especially because of the small groups and the lecturers, who also gave me some freedom outside of the curriculum. I would particularly like to highlight the "application project" in the fifth semester of the Bachelor's degree in Business Informatics.
For this semester-long project, you form a team with your fellow students and work on a real order from industry - from preparing the offer to delivery, with real time pressure and a real customer. That was a great experience because it simulates the real working day in agile software projects. My work today is also mostly project-based: a project starts, is carried out, completed, then the next one comes. Having experienced this structure during my studies was extremely valuable.
Mr. Griebler, thank you very much for the open conversation and the insight into your career!