Podcast with our Embedded Software Developer Philipp

Tune in to hear what Philipp’s day-to-day life as an Embedded Software Developer looks like, his work on the new generation of Livy products, and much, much more. 

Click here to listen to the full podcast

Christopher: Hi Philipp! I said you were an Embedded Software Developer, you said that was “sort of” your job title. Can you clear that up for me?

Philipp: That is what I was hired for, and as the word says, Embedded Software Developer, would mainly have to do with writing software. But as it turns out, I am more of an Embedded Systems Engineer, because I also deal with hardware a lot – microchips, circuitry, volts and amps – so I am kind of in the middle there. I do write software, but I also deal with the hardware itself.

C: Can you then briefly describe what you do here at HUM Systems, so even a non-tech person like me can understand it?

P: We at HUM Systems make smart home devices, together with an entire eco-system of software and the mobile app, but the devices that we make are what I work on. I help develop and design the circuitry, the physical components that go into the devices – the sensors, processors, etc. – so they can do what we want them to do. And then I also write the software, which runs on the devices in those microchips, which breathes life into the device and ties it all together and makes it comes to life.

C: So your position is a bridge between those two worlds?

P: Right.

C: What did you study?

P: I studied computer science in my bachelor’s degree, just general computer science, which is a lot of theory and software and math and stuff like that. Like any IT job or person would have studied. But then you can specialize in many different fields, and towards the end of my bachelor’s I decided to specialize in hardware, so I put an emphasis on computer engineering, which dives into the hardware more. You learn about how computers work down to the physical level – to the transistors and voltages and currents. That was a lot of fun and was really interesting to me, I really liked it. It also helped me understand computers and the digital world in its entirety – from the transistor upwards to when you click your mouse on the computer. That whole stack, understanding it the whole way through, which is a really great feeling.

So that was at the end of my bachelor’s, and the I chose to study computer engineering in my masters, which was more into detail with the hardware and the low-level software. That kind of reflects what I do now – in part software and in part hardware, and that was my bachelors and masters as well.

C: That leads directly into my next question – how did that impact your choice of job offerings and the position you have now? In other words, is that directly correlated to what you studied?

P: Yea, pretty much. Even with computer engineering, you can do many different jobs – you can do jobs that only have to do with software, but it depends on which direction you specialize in in computer engineering. But for what I do, it pretty much matches up perfectly with what I studied. You can go way more into hardware and you can go way more into software, and I like that middle ground – that is sort of where the magic happens. It is where, like I said earlier, where you start breathing life into circuitry. From the physical and hardware point-of-view, you make it come to life, but then again from the software point-of-you, this is your gateway to interacting with the real world. Whereas, if you only write software, it is just theoretical and intangible. That is a really interesting intersection, a really interesting point. And that is right where I am and what I studied, so it fits perfectly.

C: So, it is literally a one-to-one relationship between what you studied and what you do now.

P: Yea.

C: That’s cool. I want to get back to what you just said, but first – how did you get to HUM Systems?

P: Towards the end of my masters I was looking for jobs, mainly in the north of Germany – Hamburg and Berlin. I wanted to move to a big city. I studied in Heidelberg, which is way down in the south…

C: Gorgeous city.

P: It is a pretty city, a lot smaller, but it is very nice and has got a good university. But I wanted to go to a big city in the north, and mainly Berlin – that was the plan. So, I looked at jobs there, and on some portal,  I found the job offering for an Embedded Software Developer. I looked at the company and what they do, I liked the fact that it was a start-up, I like the flat-hierarchy and hands-on, intimate way of working, in contrast to a huge corporation where you are one of many, so I sent out a job application.

C: What was your job interview like?

P: Soon after I sent out the application, I got a response and luckily, we were able to do the first interview remotely, because like I said I was in the south and HUM Systems is here in Berlin, which is a 7-hour train ride up here. It would have been really annoying to have to come up north for every interview that you do. This is true for apartments as well – I was looking at apartments at that time, so I was always really thankful when I got to do it remotely, at least for the first one, because sometimes you know right away that it isn’t going to work out and it would be a disappointment if you put all of that effort into that.

So, we did the first interview remotely – it was Reza, our CEO, and Helena from HR. We had a chat, they explained to me what the company does more in detail, what the job entails, I talked about my situation, myself, and yeah – it was really nice, really friendly, really easy. You know, sometimes conversations are just easy.

C: Yeah, sure.

P: Then I got sent a small coding challenge, so I did that in a couple of days and sent it back so Reza could see some code, and it always helps with determining the skill-level of the applicant. That was convincing, so I got invited to a second interview in Berlin. At the same time, I also had an interview for the apartment that I live in now, so that worked out perfectly, I could do it in one day.

C: Was it Reza and Helena again, for the second interview?

P: Yea, it was the same. We met at the office, had a conversation, Reza introduced me to some of the people there and showed me around, so I could get a feeling for the workplace, told me some more about the company. By the end of that conversation, we both pretty much knew that it was the right fit.

C: So, coming back to what we were talking about before, you and I had had a conversation about this and what I wanted to touch on before, and this is coming from a non-tech person. You combine an engineering background but you also have the ability to code. Is the transition between two fields -- so from my perspective it looks like some tangible like hardware, but also something super theoretical, like coding -- is that now for you fluid?

P: Now I would say, yes it is, but like I said earlier, that interface between the real world – the circuitry, the electronics, that make it all happen in the first place -- and the software that makes use of the hardware, that interface is really interesting. That is really where things come to life. From a hardware perspective, the software is what gives it purpose, and from the software perspective, the hardware is what makes it all possible. What you said – tangible and allows us to interact with the world.

Your first impression is right – they are two very different worlds, and bringing them together is not trivial and is not that easy. It is a lot of fun but can be very difficult, and there are some tripwires in the beginning, some obstacles and some things you have to learn. You definitely have to study this to even get started, but that alone won’t save you from making mistakes and getting hands-on experience. You get the hang of it and things start to become more fluid – and then it gets fun, because you are this guy that has the toolset for both worlds, you can make things do something. You can put the circuitry together, write software, and you have a prototype that can do things.

Whereas if you just do hardware, it will never come to life – it will work, it will be correct, but it will never interact with the user. If you only write software, it is a file essentially, on a computer somewhere. You need to execute it and implement it on hardware for it to have purpose.

C: I wanted to talk about that, because you and I had a conversation, because I was looking at the Beethoven symphony, and you said “what is all of this on this paper?”

(Laughs).

And I described to you how it is composed and how I read it, and you said, “Oh, so it is kind of like code”, and I replied “Yea?”, in the sense that if you are composing something, then you do it for a piece of hardware, let’s say a piano, but that hardware is fixed. So, you have to compose the code, so to speak, around that hardware. Is it the same thing, that you are doing?

P: Yea, absolutely. This is really the software that I write. It needs to be very aware of the hardware, and it makes a big difference if you use a chip to do something from manufacturer A versus manufacturer B, because it might be different in the way you need to deal with that chip, even though to the user at the end it will provide the same service.

So, this is really the software that I write, which is very aware of the hardware and interfaces with it, and then abstracts away from it, so software layers above that, that will only talk to my software, but not the hardware directly, they don’t have to worry about that anymore.

Let’s say you have a really simple temperature sensor. Depending on which one you put in, it might be very different in the way you need to handle it, from a hardware point of view, from the circuitry and interfacing with it. This is the software that I write. To the software layers above, I simply expose the ability for the higher layer of software to ask for the temperature – so it can ask for the temperature and it will be delivered, regardless of the underlaying hardware and the differences between the two sensors that you use. So that is really what I do.

C: What is a typical day at work look like for you at HUM Systems? I know at the moment you are hard at work on the next generation (of Livy Protect), and is that the same for a standard embedded software developer? Or is does it really vary from position to position?

P: Well, for one, I do more than just software, and these days a lot more than that – I am helping in the development of the next generation, which in an earlier stage has a lot to do with the hardware which needs to be put together, so in the past I worked more on hardware than software. Then again, once that is done, I will write a lot more software, because the hardware is sort of fixed at that point.

From company to company it differs as well, even though an embedded software developer typically just writes software and doesn’t have to deal with the hardware that much. It also matters if you work for a start-up or a bigger company because at a start-up you just aren’t that many people and every individual takes on multiple roles and has various responsibilities.

My days are always different; it never gets boring! Typically I get up, do some email house-keeping, at 10 o’clock we always have a daily with everybody in the hardware team. There are other hardware developers that just do hardware, there are others that help with the software, there is the industrial designer that does housing and cases for the devices – and all of that plays a role in which components you select. The case may restrict how the hardware can look and the hardware may require the case be like this or like that.

So, we have our daily, where everyone talks about the current state and what they are currently working on, current problems that need to be solved so we can help each other out, and then it can be very different. Sometimes I do research on components – on microchips, picking out the right ones for our device. Other times I write software. I talk to suppliers or manufacturers if we need support or have questions or need custom modifications on what they have. Sometimes I work on the schematics itself – the circuitry for individual components, and yea, it always comes back to software.

Sometimes we build prototypes, if we want to try something out real quick. We have a little lab, there is a soldering iron, there is some duct tape, there is some glue…

C: Cool! So it gets down and dirty sometimes.

P: You just MacGyver it.

(Laughs).

C: You have been working a lot on the next generation of the Livy Smart Ring. What has the process been like? What are some of the challenges you faced – either expected or unexpected?

P: I guess the biggest challenge overall is that the new generation is a big step up over the current one. We try to have an agile method in hardware as well – this is usually done in software and harder in hardware because you have factories, things get manufactured and time frames are just bigger. But it is still a cool idea to develop hardware in an agile way too, because you get out prototypes faster, you try out things and learn from that and then iterate on the product, you improve it. We do this a couple of times a year, usually three or four months or so, which is a lot of fun.

We have done a lot of iterations on the past product already, but it is now not just an iteration on that, it is a new generation. It is basically now a different product. It is a product that has so many more features than the one before, so that was definitely the biggest challenge – you have so many different facets and so many new challenges to deal with, all at once, but it is great. It is a lot of fun, it is a great learning opportunity, and it is just fun to build something cool, something that hasn’t been there before.

C: Philipp, as always, it has been a pleasure!

P: It has been a pleasure, thanks!