What’s the difference between firmware engineering and software engineering? And what do toasters have to do with this? 

In this episode we interview Kyle Matthews, director of Firmware Engineering, and Petek Sener, software engineer, about the differences between their respective fields and tips for new and seasoned professionals alike.

 

Julia: 

I don’t know what either of you do.

Britt: 

Haha, I googled but I don’t know if I Googled right at all. 

Petek: 

I’m curious what you Googled. Were you just like, “Software?”

Britt: 

I first looked at LinkedIn to see what your actual title was. Then I was like, OK, firmware. Then I Googled what FWE is. 

Kyle: 

Firmware engineer. Nice. 

Britt: 

I got mainly interview questions, but they actually were somewhat helpful. And then I just read some embedded software stuff. 

Kyle: 

Yeah, that’s about it. 

Julia: 

We always start off with, “What’s your name? What do you do here?”

Kyle: 

Kyle.

Petek: 

Next question. 

Julia: 

Love it, one word answers only!

Kyle: 

No, I’ll go first. So yeah, my name is Kyle Matthews. I’m the Director of Firmware Engineering here at Blur. I’ve been here seven years now. I think I was like the third employee. And yeah, I joined in May of 2017. 

I joined Blur because I wanted to find like-minded people to learn from. I met Nathan and Scott in the interview, and I immediately was like, oh, this is a great group of people. They’re very smart, they’re very passionate, I could learn a lot here. That was seven years ago, and it’s been… I’ve certainly learned a ton. So mission accomplished. 

Julia: 

There you go. I’m sure [you learned] some things you weren’t expecting to learn. 

Kyle: 

Oh yeah. There’s lots of unexpected things too, and I picked up a little bit of mechanical stuff along the way. I actually originally applied as a mechanical engineer. 

Petek: 

Really? 

Kyle: 

Yeah. 

Petek: 

Oh, that’s crazy. 

Britt: 

What’s your degree in? 

Kyle: 

Biomedical engineering. So yeah, I kind of sidestepped my way into electrical engineering and nowadays more firmware and software engineering just by what I enjoy. So it took me a little bit to find exactly what I had a passion for. But yeah, I kind of lucked into Blur, applied because they had a mechanical engineering position open. mechanical stuff, so I applied. And during the interview, it became very quickly clear. Thankfully, Nathan was on the call. And he was like, oh, this is more, you know, you like doing firmware and software and stuff like that in electrical design. So I kind of did a bit of everything in my previous job. 

Now I’ve sort of cut out the mechanical side of things. I don’t touch too many mechanical things anymore. And I have transitioned fully into the firmware world, pretty much nowadays. I don’t really do too much board design either. Maybe a little bit for projects that are, you know, kind of my passion, which would be small wearable devices. They’re very tightly coupled between the electrical and firmware, meaning the choices you make on your circuit board have, you know, huge consequences for what the firmware needs to look like and they kind of play together. There’s generally a huge dependence on energy efficiency, low power type stuff, and so you have to be to make everything as small as possible and as low power as possible. So that lends itself well to doing both the board design and the firmware side by side by sometimes the same person. 

Petek: 

I’m Petek, I’m an R&D software engineer and compared to Kyle I’m a newbie because I’ve only been here for a year. Blur was super nice, they would let me come in and use some of the lab bench and the spaces and that was when I was in a startup so I was doing, I guess kind of like you, I was doing some CAD design and also the software and I was helping build fleets. 

I remember Kyle was showing me how to actually surface mount solder stuff. So yeah, that’s how I got to kind of see Blur and like the company culture. When I was looking for my next opportunity, I was like, let me see if Blur has a position open. And yeah, that’s how I ended up here. 

Britt: 

So what have you learned so far in your first year here?

Petek: 

Oh, so many things. I think it’s really nice to be able to work with so many engineers that come from different backgrounds. Even when you do different things in a project, even when you just do software, you naturally have to interact with the electrical side or people who wrote the firmware, who did the board. So it’s really nice to be able to go up to that person and ask your questions and kind of learn about what their process looks like and the little tips and tricks that they can give you. Yeah, I think that’s really valuable and something I didn’t have before when I was in a smaller startup. 

Julia: 

What do you want people to know about the difference between the two? 

Kyle: 

There’s sort of a blurred line between them. If you ask five different firmware engineers the difference between something like firmware and embedded engineering and stuff like that, you’ll probably get five different answers. But the key thing for me is for firmware and embedded software, you’re kind of working on a variety of smaller processors, right? When you’re working with what I would consider software, I sort of immediately think of desktop software, mobile apps, backend servers, and things like that have oodles of processing power, for lack of a better term. 

For embedded systems, there’s really, kind of, two different flavors there. There’s one that’s gonna be running on small microcontrollers that are sort of all-in-one systems to simplify it a little bit. They’re generally very small, very low power. They don’t have dedicated RAM most of the time. They don’t have a cooling system. A lot of times they run on batteries and they are just sort of small self-contained systems that may or may not have an operating system, which will be a different operating system than your Windows or OS X or Linux or something like that. It’ll be a stripped down operating system known as a real time operating system. 

So yeah, when I explain this to people, I basically just say I write software that goes on the little green circuit boards that you see. And they’re pretty ubiquitous, like we were kind of talking about earlier. Pretty much everything has firmware in it these days, even for very simple things like a toaster.

There are some toasters that don’t. There’s a very famous mechanical-only toaster. It was made, like 60, years ago. And apparently it’s fantastically good. During COVID, it became popular again and they were selling for hundreds of dollars on eBay. 

Petek: 

Woah.

Kyle: 

But it uses like the temperature warms up some mechanical piece that starts bending or turning or changing properties somehow, and that does the timing. Apparently it makes perfect toast every time. Yeah. But it’s very complicated to build because there’s all these mechanical components in it. And… modern manufacturing processes aren’t quite set up for it, right? 

It ends up being cheaper to put a small microcontroller on there and put a little bit of firmware on there and make a million of those, then it is for a more complicated system. You wouldn’t want a Windows computer in your toaster. 

Petek: 

Yeah. 

Kyle: 

So there’s a cost efficiency there too that differs from true software engineering where you have unlimited computing power, basically. A power budget that is far in excess of what you would have on a microcontroller. You can do a lot more things. It’s a little bit of a different design paradigm when you start thinking about what the system needs to do and how you’re gonna go about doing it. 

Petek: 

Yeah, I’m spoiled over here with all the power and processing. 

When we talk about mostly software at Blur, we’re talking about more like a graphical user interface, so applications you would install, download on your computer. As Kyle works on the firmware, I create these engineering applications so that our R&D team engineers, or manufacturing engineers, or even our clients, because we provide that software to them, can use this interface to be able to talk to their device. So to collect data from your device, visualize it, use it to run tests and experiments with your device, test out the feature. 

Some of these devices go through clinical trials, so you want to be able to have a nice user interface where you can make sure your device behaves the way you expect it to behave, and having a GUI just really speeds up that process. You can just hand it off to someone and they can click the buttons and look at it and it’s a more, like, immediate data processing for them. 

Britt: 

What do you kind of have to know about, when you’re working in parallel together, what do you have to know about the firmware piece in order to be successful in software piece? 

Kyle: 

A lot. 

Petek: 

I second that. 

Kyle: 

Yeah, so I mean the big thing is going to be the communication interface between them, right? So that’s step one, figuring out, well, how are you talking to it? Is it through a physical link like a USB or serial connection or something like that? Or is it wireless like Wi-Fi or Bluetooth? So you kind of start there and then you settle on a communication scheme, right, for lack of a better term. 

For something like a physical serial link, you might have a command line interface, or a more structured interface that’s machine readable, right? Instead of actually typing out like, hey, turn on my LED in normal human readable language, you might have a byte string that’s serialized through some protocol that is more amenable to just using an automated control interface in Python or in some other way. 

Likewise, if you do it through a wireless link like Bluetooth or Wi-Fi, you’ll do the same thing. You’ll settle on, well, what’s the command interface look like? What’s the data that goes out of the device? What’s the data that comes into the device? And you end up spooling up some documentation around that. As you go, you flesh out the documentation more, but you basically start with, can we talk to each other? Once you get that going, then you kind of build on it and riff on it a little bit and start fleshing out, like, a command and response or some other sort of paradigm for how you would talk. 

Additionally too, you know, past the just the raw interface of how do you structure messages to each other, what language are you talking? And I don’t mean language like programming language, I mean, what’s the actual information that’s getting passed back and forth? You also have to know the overall device operating scheme and behavior. So, if you’re going to run, for example, a treatment of some sort, are there some setup steps that have to happen before, during and after? Then you’re going to want to check to have some sort of robust system where you’re checking for errors, making sure it’s in the right state, the data is appropriate and it hasn’t veered off into an unhappy path. That you’re kind of staying on the happy path, and if you do diverge from that happy path, say there’s an error or something, you do your best to bring it back onto that happy path, recover from it, tell the user or the operator what’s going on and things like that. 

You know, every project has bugs. You’re never going to create a project right off the bat that is bug free, but you obviously strive for it every single time. I would say there’s various classes of bugs, but some of my favorite ones are bugs that have sort of complicated interactions. It’s not as much fun when you have a bug that you can just immediately point to, like, there’s the culprit, right? Like, that code was wrong, it needs to be changed, this is how you change it. That’s a relatively quick fix. Getting to that point of finding out where the bug is can sometimes be complicated. 

The more fun ones for me are ones that have hardware or user interactions with them too. Like the user does something that causes some physical interaction that then the firmware can’t quite handle. So there’s this chain of events that you have to walk through and understand in order to solve it. So, you know, another [example] from a low-power wearable device perspective is something like the haptic firing and the device doing something else and it causes the voltage on the battery to dip and you have to kind of work around that. 

For some of our very, very small implantable devices, they have very, very weak batteries. You have to be very careful about how and when you do things because the battery itself can’t even support the processor running for long periods of time because the battery droop gets so low. So those are probably my favorite bugs, the ones where you have power interactions and kind of brown out situations where you have to be super careful about when you’re even letting the processor come out of sleep to run commands and transmissions, things like that, and how do you gate that in a robust way to make sure that you don’t continually bring the system down? Or, more likely, you have some sort of weird edge condition way down the line that happens one percent of the time, right? That’s hard to catch in testing. But if you have a million devices in the field that starts becoming a very large problem 

Petek: 

Yeah, I think user interactions are really hard to predict because as the people who create the software, the firmware, you as the engineer have a very clear idea of what it can do and the order of operations when you’re interacting with it. So sometimes it’s hard to imagine all the various ways that a potential user can interact with it. So then, yeah, you have to get more creative and do things that you yourself wouldn’t normally do just to get to those edge cases of, “What ways can they break my code?”

Kyle: 

That’s a really interesting one, too, with user interactions. You can depend on the user to do the complete opposite of what they were supposed to do. And they will do absolutely anything and everything other than what you planned for them to do. So they stray off that happy path that I mentioned a lot. 

Another fun bug that I had was not really a bug at all. It was more, why are these devices failing in the field? This was before I was at Blur, but I like to relay this anecdote. We had a device that would be, you know, worn on the body and the patients, the users, didn’t really love it too much. It was a very early product, it was a prototype and they were, you know, high school kids. So instead of actually wearing the device, they would fake it. They would stick it in their waistband. 

They were playing contact sports and things like that. We had tons of devices breaking. And it was like, well, why are they breaking? They shouldn’t be breaking. They’re relatively protected. The patients are wearing, users are wearing protective equipment and stuff like that. And it turned out that no, it wasn’t really protected because it was just in their waistband and very susceptible to getting hit and sweat and things like that. And so you had to, figure out and solve the main problem, right? Make it more comfortable for the users, make it handier for the users, and have some design changes around that, but also hardening it for sweat ingress, and things like that, where we didn’t really design for that at the start, but it became very clear when you started testing that the users aren’t gonna do what you want. Pretty much ever. 

Petek: 

Yeah. 

Julia: 

I think that’s why usability testing and getting out in the field and having actual people put it in their hands and mess around with it is so important because like you were saying, they’re never gonna do what you expect them to do. And that’ll show you some weaknesses maybe in your design that you need to fix. 

Kyle: 

For sure, yeah, absolutely. I mean, the overall, a lot of times, it’s not a golden rule, but a lot of times, the core functionality of the device, what you would call kinda like the business logic, the device doing what it was designed to do, spitting out the information it was supposed to do, is somewhat a lot of times a smaller section of the code than handling edge conditions and more likely sort of helping guide the user to a path that is appropriate for the device. I don’t have a great example right now, but defensive code to protect the user against themselves. 

Petek: 

Yeah, put up the safety guards. 

Kyle: 

Exactly. 

Britt: 

They have to, they for sure do that with phones. 

Kyle: 

Yeah. 

Britt: 

You know, my mom, when she can’t do her passcode, she’ll just start smacking it or, you know, hitting all the buttons. 

Kyle: 

Exactly. The users turning their devices off and on at random times, throwing them across the room, not charging them, dropping them into water, all sorts of fun stuff. Not to mention just normal usage flow stuff where they’re maybe clicking a button that you didn’t intend for them to click yet or something like that. So that sort of code, once the user starts getting their hands on the device, there’s sort of an expectation that there’s going to need to be some changes in order to firm things up because you’re always going to discover things that you didn’t anticipate. 

Britt:

So you mentioned hobbies kind of led you to where you are. What kind of things actually got you to get into software or into this field or firmware? 

Petek: 

Sure, so I did biomedical engineering in undergrad, which I guess is like a good starting point because I think with that you kind of taste all different sorts of engineering because you still get a little bit of medical side of things and software side of things and mechanical side of things. Through undergrad I got to work on various design projects, and just through those my favorite part ended up being software. After graduating, over the years that’s just been more the main focus because oftentimes like the user interface is what your investors or end users are seeing. It becomes this valuable asset of how well you can present your device. The focus had been shifted more towards that, so that’s where I directed my energy to. But it also became my favorite part of working on a project, so it all worked out. 

Kyle: 

Yeah, and I was sort of the same way. I had always taken an interest in programming and software development in high school and in college. Those kind of were my favorite classes. I worked at a university for many years after I graduated. And in the course of that job, I got experience with a bunch of different facets of product design. Not purposefully, just by nature of needing to set up a certain experiment and needing a little bit of code maybe to help control it or mechanical design or electrical design to make things a little bit easier. So I started dabbling in that as I was just kind of working as like a lab engineer. 

I kind of really enjoyed every aspect of it, to be honest, but I most enjoyed the firmware and the electrical design. So I just sort of kept expanding on that. Every chance I had for a project to roll a little bit of that in, I would take that opportunity and really sort of focus on that. It sort of came about organically for me. I went to school for biomedical engineering also. I didn’t really like a lot of the things about biomedical engineering, but I did like a lot of the things with electrical and software engineering. I found myself sort of moving towards that direction and after seven or eight years of doing stuff like that in a research setting I decided, hey, I really like product development. That’s kind of what I had come to enjoy most is a new project or a new research project coming in and it needed this little widget. I loved doing the widget part, I didn’t like doing the experiment part so much. So I was like, all right, well let’s see if we can kind of hone in on that and that turned out to be product development. And so I decided, well, let’s look around and see what product development places are around here. And Blur was kinda, even though it was very new at the time and there weren’t too many employees, just talking to them, it was very clear that that’s kinda where I wanted to be. 

So I sort of sidestepped my way into this role by way of doing research-based projects for many, many years. 

Julia: 

Yeah, you’ve been around since the beginning. 

Kyle: 

Yeah, the growth, the growth has been amazing. And just seeing it start from really like four of the co-founders and a couple employees to where we’re at today, it’s really interesting in that the culture has kind of remained the same, right? I explain Blur to people like we’re just a collection of smart people who like doing interesting things, right? We all have that passion for kind of product development in general. 

It’s the type of personality where you’re at a restaurant or you’re walking around and you see some interesting mechanical thing or some interesting product, we’re all the type of people who would then stand around that product for five or ten minutes and likely take it apart and start talking about it, right? Trying to bring interesting things and learn from it. Although everybody’s from different backgrounds, different educations, different specialties, there’s that desire to continually learn and to talk about things, which I find really refreshing and enlightening. You can always learn something here. And that’s, that’s kind of, in my opinion, the best part about being here.

Britt: 

What would you kind of educate the listeners on like different tools, both of you? If you could recommend a starting point for someone who just got thrown into a role that maybe they’re not completely prepared for, which lanes would you probably take them down? 

Kyle: 

Yeah, that’s a great question. So I don’t answer this exact question a lot, but speaking to potential interns, potential employees and things like that, I emphasize the desire to learn as being the most important thing. Because you’re going to start a role, you’re never going to know everything there is. You’re never going to be able to slot directly in and start hammering away. And if you could, you know, that might even be a little bit boring, right? If it becomes rote like that. So you always want to be pushing your boundaries, and the most important thing we look for is that passion to learn and that desire to kind of pick new things up. So when you see something new, you don’t discard it because it’s new and you don’t understand it, you want to dive in. And that’s kind of how you learn and that’s how I learned too. 

I would say just understanding the role that you’re in, what’s expected of you and maybe taking small steps at the beginning to introduce new things. Not too fast, right? You don’t want to rock the boat too much. Let’s say that you’re in a new firmware role. Hopefully you’re on like a somewhat new project not like an established project that would kind of fall under my definition of rocking the boat, maybe a little bit too much if you roll into your new job and you’re like, “I think we should change everything.” That’s probably not the way that you wanna go. But even in the course of starting your new role, you’re gonna come across tons of new things, right? Specific ways that the company does things, development processes and things like that, and take everything in, learn about it as much as you can, and then start integrating it. 

As you go along with this process and you keep learning about things, you’ll settle on things that in your mind seem to work and things that could use a little bit of polishing maybe. And so you polish those things up and then you continually learn and it’s just this gradual improvement process. And it’s not something that happens overnight, it’s something that takes time and desire. So just sticking with it, especially from a firmware perspective, just like software engineering, it’s gone through a great deal of progress even in the last five, ten years. And five to ten years from now, it’s gonna continually explode and improve and make people more efficient. Just being able to write firmware that runs on a multitude of different processors and things like that, different wireless technologies that are starting to come about too. So being able to take those new bits of information in and integrate them is kind of the most important thing.

Petek: 

I agree with that one hundred percent because I think it’s never like, oh you learned it, now you’re a software engineer and you’re done for the rest of your career. I think just teaching yourself the skills to learn is the most important part. There’s always new software, right? Like no two companies do things the same way. There are a bunch of different libraries and packages and different ways of doing it, so you’re always going to be thrown into something that you don’t know and it’s a matter of how dedicated you are and how fast you can teach yourself and start using that tool. 

Even here, some projects needed a database so we had to spin a database. We have a new manufacturing application that needed to talk to a barcode scanner. Have I worked with a barcode scanner before? No. But now I had to figure out how to integrate this barcode scanner into my code. It’s always changing and it’s never the same, which is also the fun part because there’s always something unique in play, there’s always a new challenge. But as Kyle said, I think it’s a matter of you being driven to learn new thing that really makes the difference. 

Julia: 

Amazing. Thanks so much for the interview. 

Kyle: 

Absolutely. I will happily do another episode whenever you guys want. 

Petek: 

Yeah, this is fun. 

Kyle: 

It is fun. It is fun.