Developers and software companies are always chasing anything that will make them more productive: to shorten the distance between thinking of a solution and coding it down to near-zero. We’ve talked about the mindset and methods for getting into a flow state on a previous episode of this series, but what if part of unlocking that flow is just better integrating your hardware with your software?
In the third episode of a podcast series sponsored by Logitech, we explore developer productivity, flow state, and the impact hardware and software can have on these key aspects of a programmer’s workday. Our guests on this episode are Laurent Gillet, head of embedded software, and Tanvi Shah, head of software development.
Episode Notes
We dive into some of the ways developers can customize their keyboard with shortcuts, macros, and apps to eliminate repetitive tasks and automate the busywork that stands in the way of bigger, breakthrough innovations.
Flow state can be affected by things as simple as the right lighting, so Logitech created keyboards that automatically adjust their keyboard backlighting.
For those not familiar with the MX series, you can read more about the different versions, including the mechanical one, here.
If you don’t know about Cassidy’s passion for keyboards, you can check out her website here or listen to a previous episode diving deep into the details of mechanical keyboards here.
If you missed episode two, you can check it out below. In it, we chat with Marcel Twohig, Head of Design for the MX Series at Logitech, and Thomas Fritz, Associate Professor of Human Aspects of Software Engineering at the University of Zurich. We cover the research that Professor Fritz has done on flow states, the design work that Marcel and team have done to incorporate that research, and the tools that you can use to maximize your daily flow.
The Stack Overflow blog is committed to publishing interesting articles by developers, for developers. From time to time that means working with companies that are also clients of Stack Overflow’s through our advertising, talent, or Teams business. When we publish contributionsfrom our customers, we’ll identify it as Partner Content with tags and by including this disclaimer at the bottom.
TRANSCRIPT
[intro music plays]
Ben Popper Hello, everybody. Welcome back to the Stack Overflow Podcast. Today we have a sponsored episode. It is part three of our deep dive with the fine folks at Logitech, exploring hardware, software, developer productivity, many things near and dear to our heart of the show, especially some of my co-hosts here, Ryan Donovan and Cassidy Williams. How's it going, y'all?
Ryan Donovan Oh, pretty good.
Cassidy Williams Hello! I'm excited to be here.
BP Cassidy, they sent over a great list of talking points which we're going to dive into. You mentioned some of these acronyms are familiar to nerds like you. Does this touch on some things that you've dealt with as a software developer and mechanical keyboard aficionado?
CW Yeah, so ‘FW’ is firmware, which as someone who builds keyboards regularly, I often have to update firmware on different keyboards and stuff and also just any sort of embedded system where it's not necessarily on a computer. But if you want to control– I don't know why this is the example that came into my head– a Wii remote, it's going to have some kind of embedded software on there to do that. And so ESW is embedded software, FW is firmware, SW is software, HW is hardware. We hear these a lot tossed around.
BP All right, wonderful. Well we're very excited. Laurent, Tanvi, welcome to the show.
Laurent Gillet Thank you.
Tanvi Shah Thank you.
BP So Tanvi, let's start with you. Tell the listeners a little bit about who you are and how you got into this world of technology and what it is you do today day to day at Logitech.
TS Sure! So my name is Tanvi Shah. I lead the Software Development Team at Logitech. I love and thrive at building compelling software solutions and services from conception to launch. Today, I am responsible for overseeing all the software development activities here at Logitech, and we are working on our next generation software platform that enables our users to not just customize their devices, but offer innovative solutions that enhance the way our users interact, navigate, and connect with the digital world by optimizing and automating their workflows to help them stay creative and productive in whatever they're doing, whether you're a software developer, a content creator, a presenter, et cetera.
BP A gamer, a professional gamer I mean.
TS Yes, or a gamer.
BP And Laurent, how about yourself?
LG Hello, everyone. So my name is Laurent Gillet. I'm in charge of Embedded Software Development. So still code development, but that tiny piece of code that runs on your device. So on mice, on keyboards, on presenters, but also for gaming, for steering wheels, for all the stimulation you can play and interact with in order to interact with the digital data. And as said by Tanvi, the ultimate aim is to make sure that what we're delivering fulfills what the user wants. It should not be necessarily perceivable by the end user but maybe big UX, big UI, when talking about the device, but still we take into consideration how the user interacts. It could be a person not familiar with the technology or a very advanced gamer who wants to play and to have the most powerful device in order to win. So we cover the full scale of people.
RD It's interesting. You come from the hardware at two different sides– the code on the device itself and the code that interacts with the device. What's the difference between the software and the firmware that y'all are writing?
TS So software is nothing but just a piece of code that we write that runs on top of the OS. It doesn't have any direct interaction with the hardware. It's primarily designed for user interaction. A lot of what we do is really driven by UX with a big emphasis on usability, the functionality, and it's highly UX driven. So this is what we focus on when it comes to software experiences. Customer first is our journey.
LG And Tanvi, here you are really looking at the UX and the UI, how you guide the user and you offer the best UX. On the firmware, we're also looking at the UX but it's an invisible one. It becomes visible when you have trouble, when you have an issue, when you have latencies, when your cursor is lagging, that's where the UX becomes visible. And as Tanvi said, and correct me if I'm wrong, it's another stuff you are working with.
TS Absolutely. And it's highly visible. We get feedback very quickly from the users because it's highly UX driven.
BP In the forums? Do you hang out in the forums and wait for the feedback? Or do you mean angry emails? How are people getting in touch with you, Tanvi?
TS So yes, definitely forums. We also proactively do a lot of user testing as well. Part of our development process is that when something goes out of the door we also have user testing and that's when we proactively collect data. But then after we release the software we also make sure that we are following actively on the forums at Logitech and outside of Logitech as well.
LG Yeah, definitely that's something we are following. It's something we can sometimes see people want in our devices. And we also see how people react to what we have done. So this interaction, being directly confronted to what people experience with our product, that’s something really, really great. Sometimes we are waiting for that feedback, where when you wait for feedback you expect the best, but we just need to remain ambivalent to say, “Okay, let's see how people perceive what we have done. Let’s see if they've cracked the added value we have done.” And when we see in some technical video that people have noticed the various tiny stuff we have added on top, that's where we are very proud.
TS Absolutely, yeah.
CW For the firmware versus software and everything there's a lot of user testing, but as for the actual implementation of it, is it in a very low level language like C or is it something where you've abstracted that away into a higher level language internally? What do the teams work with?
LG Well here in the firmware we’re mainly working with C and C++. But we are also going at low level Assembly and so on when we need to be, because it's time critical. When we talk of gaming devices or advanced creators, the reporting rate is up to one millisecond. So we made a wireless communication protocol that is as good as corded.
CW Dang!
LG So it means that each millisecond we go through all the sensors, capture all the physical interaction with the device, see the battery life, see everything and communicate to the host and communicate to the software within one millisecond. So timing is critical and that's why sometimes we need to make really huge let's say optimizations of the code we are writing.
CW That's actually incredible, because I feel like Assembly is one of those things that you might learn in your computer science curriculum or something like that where it's a very academic setting. And so to hear it applied makes sense because you do want to be as fast as absolutely possible, but it's a very specific set of skills for sure for the team to have.
LG Yeah, exactly. That's something we really learn. And what is interesting here is that the background of the people that I have in my team, I have half of them from a pure computer science curriculum and courses, but also the other half is from the electrical engineering part. We are really in the middle of both and we need both. We have a pure software development approach when it comes to making interactions and we also have a pure electrical engineering approach when it comes to the peripherals, to the low level sensors and so on and we need both. And the way we integrate, the way we test also are the same. We can test with breakpoints like Tanvi’s team can do, but also with oscilloscopes. So when you go by the desk of a firmware engineer, you have oscilloscopes, a lot of wires, a lot of stuff you don't necessarily find on the software side. But I believe in software you also have some constraints to implement.
BP For sure.
TS I was just saying that on the software side, we develop code using high level programming languages. And our tech stack is much wider in the sense that depending on whether you are doing some low level development which needs to be purely cross-platform then we use primarily C++. And then on the front end when it comes to UX and UI development, we actually build user interfaces using web technologies. So this helps us to kind of really deliver modern user interfaces.
CW It's cool to have both ends of the spectrum because there's major pros and cons to both and you still have to work together. It's cool.
TS Absolutely.
LG Absolutely. And that's the key because let's say we make the perfect device, but the software is not working or the reverse, in the end the user is not happy. So we need to make sure the full system is working fine and that's even if we have different ways of working, different life cycles, different ways to debug and interact. We must work together, we must have touchpoints to work together in order to deliver the best user experience. Definitely.
BP So, Tanvi, what web technologies are you referring to that you use on the front end?
TS We use React JS, HTML5, CSS, et cetera. Our software works both on Mac and Windows, so we need to cater to those operating systems and therefore we use these web technologies, but then we use cross-platform desktop frameworks to be able to go ahead and build a cross-platform user interface.
CW If you don't mind my asking, what is the cross-platform thing that you use? Is it Electron?
TS We are using Electron, yes. Electron.
CW It gets the job done.
TS Yes, it does.
BP So you mentioned working in different ways, but having to come together on this, even if the life cycle of some of it is different. Can you touch a little bit on that? Is there a push and pull for example if all of the users are requesting a bunch of great updates to software so they can optimize for the latest and greatest in performance gaming, but firmware is saying we just can't quite get all of that into this package? Do you two come together and barter to try to get the best user experience that matches both? How do those things work?
LG Maybe here we can talk about the different life cycles we are using because Tanvi and I are following two different life cycles in the way to implement, and then that could answer your questions. On the firmware side, we are working toward the mass production date. The software is embedded into this part so it's really important that when this part leaves the factory the firmware is already up and running, because people paid for that, because we also have some non-advanced users that need a mouse which is working. And most of the time the most valuable product is the product itself. You can’t say, “Okay, let's have the right click and for the left click we’ll make an update later.” No, that doesn't work. We want to have already out of the box the best user experience. So here my team is dedicated to focus on the mass production date. That's a hard date. The scope as well is fixed. You want to have the ultimate experience so the way we manage that is to have more people working toward the release date in order to make sure we reach the right level of quality at the right moment. So it's more, let's say a waterfall approach we are using. We try to put an agile mindset in this way but it's really linked to a waterfall approach.
TS Yeah, it is. Because on our end, our focus is really continuously on keeping our users engaged. How do we delight the customers? And here, software doesn't need to be final when it hits the shelves. There's always room to improve usability, quality, maintain compatibility with everything that it relies on to work. We want to respond to user feedback and address their pain points, so what we do is we work towards continuous releases. So we have the Agile Release Train concept, so this is where we adopt the continuous delivery cadence with the standard industry best practices around CI/CD integration and automation test pipelines. But when it comes to software/firmware combined experiences, this is what Laurent is alluding to, we work here differently in the sense that we still want to keep software in agile mode. But if we have combined experiences, this is where we found a working model which is the Hybrid Agile Process. And this is where we blend agile with commitment based product scheduling, so where software releases for a product works against a plan of record, but it runs in agile mode. So we still run in sprints, we still keep the flexibility to change the UX and perform user testing and adapt to user feedback, and change scope if necessary as long as we release within the commitment milestones that we've agreed on.
LG Exactly. Here we have key touchpoints between software and firmware in order to make sure what we are delivering meets the user expectations. First a kind of architecture backbone in order to make sure that what we’ll deliver, the big ideas we want to deliver, is the right one and will fly with the schedule, and then regular touchpoints, regular integration to make sure that what has been done on the software side, what has been done on the firmware side, and see if the expected user experience meets the one we obtain.
RD You talk about the constant improvement in working together. I have a Logitech camera here and it comes with a little app that lets you adjust how it looks. I'm wondering, as you're developing both the camera itself and the firmware on it and the app, are you feeding into each other? Are you causing changes on the other side?
LG Yes, we have ways to communicate with the software in a way that we interact with each other in order to have configuration contextually being added to the device, camera, mice or keyboard. So definitely.
RD So if I've already got the app and the camera over here and you come up with new features, new firmware, does that filter down to me the user? Or is that new releases, new developments?
LG Well here it totally depends from one product to the other. There is no unique way to do it and to deliver it. There is multiple ways to address the user feedback and either it could be an update or it could be a new product if it's not feasible with an existing product.
TS And I think to add to that, there is the out of box functionality that we talk about where your camera will work in a certain way when you don't have the software installed. And then when you have the software installed, how does software enhance the experience of our users? And today we don't rely on updating the firmware of your device to unlock new features, and that's what we are working towards– how do we change that mindset or perception where we can actually go ahead and bring incrementally these features through new firmware upgrades as well.
LG Yes, totally true. With the embedded device itself, you have the performances, you have the robustness, you are ready. Focus on battery life, robustness, performances, for sure. When you add the software, that's when you have productivity on top. That's where you have the wow effect because we combine the best of the two words.
BP Yeah. You had included a word here that I was curious about in the notes for our talk. It was sustainability, and hearing you say these two things it makes a lot of sense. The more you can extend or improve the life of the device with software updates or even firmware updates, the more you can look forward to sort of that next generation and figure out how to make that great and make the changes that would require, Laurent maybe like you said, going all the way back to the blueprint that goes to the factory as opposed to just things you can push out over the air.
LG Exactly, exactly. So as you said Tanvi, here the software and the firmware plays a great role for durability to make the product relevant longer. And here it's mainly software driven because the software gives longer life to the piece of hardware.
CW And that's so important in today's day and age where the planned deprecation of everything is so prevalent. Having something that you know will last for a while and be improved is very valuable.
BP Yeah, for sure. My last question was kind of in your direction. I know Laurent, Tanvi, you both work at Logitech, firmware, software. What do you think about folks who are building their own stuff or maybe trying to customize your stuff? To what degree do you prepare for people who are going to poke around and try and integrate this with other peripherals or things they've written themselves? To what degree is this stuff open for developers and creators to hack on or add on to themselves?
TS I think there is not a lot of customization in terms of outside of what the software provides, but we do have for example, in our Logitech Option software that's our predecessor, where we provide an SDK for our developers and use third party developers who want to go ahead and build custom plugins for example. Our Logitech Craft keyboard is our wireless keyboard with the crown input dial, and you can use that to activate and control custom actions on various applications. And here is an example of how we had an SDK which enables our users for example to build custom plugins and you can use our application to do so.
LG In the open source community, Linux and so on, there are also some softwares that exposed widely these APIs. We also release some device APIs in order to interact with the device and see what people can work on, build on, and so there are a couple of applications like Solar that allow users to interact with the device and to offer other APIs to external applications.
[music plays]
BP All right, everybody. Thank you so much for listening. As always, we are going to shout out the winner of a lifeboat badge: someone who came on Stack Overflow and found a question with a negative score, gave it a great answer, and now that question has a positive score, saved from the dustbin of history and spread a little knowledge around the community. Awarded August 10th to David, “Can we convert a byte array into an input stream in Java?” David has the answer for you and has helped over 140,000 people with this answer. So thank you, David, and congrats on your lifeboat badge. I am Ben Popper. I'm the Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. Email us with questions or suggestions, podcast@stackoverflow.com. And if you like the show, leave us a rating or a review. It really helps.
RD I'm Ryan Donovan. I edit the blog here at Stack Overflow. You can find me on Twitter @RThorDonovan, and if there's something you'd like to see covered by the blog, please email me at pitches@stackoverflow.com
CW My name is Cassidy Williams. I do developer experience and you can find me @Cassidoo on most things.
TS Hi, I'm Tanvi Shah. I lead the Software Development Team at Logitech. You can find me on LinkedIn.
LG Hi, I'm Laurent Gillet. I'm Head of Embedded Software Development at Logitech, and you can also find me on LinkedIn.
BP Well thank you to both of you for coming on. We appreciate it. Clearly we have a bunch of your devices up and running around us, so glad you're working hand in hand.
LG Good choice. Really good choice.
BP All right, everybody. Thanks for listening. We'll talk to you soon.
TS All right. Thank you. Bye-bye.
[outro music plays]