Embedded - 478: The Map Is Not the Territory

Episode Date: May 30, 2024

Jan Rychter joined us to talk about building a company, electronic components, and software design. Jan is the founder and engineer at PartsBox.com. If you are interested in the meta-analysis of the data, check out his article on the Top Ten Hobby Parts and the Electronic Component Database,  You can find out more about Jan through his website (jan.rychter.com), LinkedIn, or Mastodon. Transcript

Welcome to Embedded. I am Alicia White, alongside Christopher White. Our guest this week is Jan Richter, and we're going to talk about electronics and software, which for a show called Embedded seems quite reasonable for a change. Hi, Jan. Welcome. Hi, hi, hi. Hello. Could you tell us about yourself as if we met at that big German electronica conference? Okay, let's try. So the main reason why we're talking

today, I guess, is because I am the author of PartsBox, an online tool for inventory control, production, and purchasing, which is specifically designed for electronics. So I am at the intersection of electronics and software. And before PartsBox, I co-founded some other companies that were also at the intersection of electronics and software, though always a little bit more on the software side. Personally, I enjoy designing and writing software, building electronics, and more generally just building just about anything. So some of my other hobbies involve mechanical design, 3D printing, software, building electronics, and more generally just building just about anything.

So some of my other hobbies involve mechanical design, 3D printing, resin casting, CNC, or woodworking. We want to do lightning round where we ask you short questions and we want short answers. And if we're behaving ourselves, we won't ask which exactly or why. Are you ready? I can never be ready. This is the scary part, but let's go. Favorite woodworking tool? Plunge saw.

You are a cereal company founder. What is your favorite breakfast cereal? Unfortunately, chocolate muesli. Unfortunately, because that doesn't do my health any good. It's got the muesli, unfortunately, because that doesn't do my health any good. It's got the muesli part. You're fine.

Uh, what's one thing folks should be sure to do if they visit Warsaw? Uh, visit it in the right time of year, I guess. One half of year is, is basically terrible in Warsaw. So visit it in the summer, please. No particular activity? No, not really. Warsaw is interesting for a number of things, but most of them are not related to the Warsaw being strictly Warsaw. People are always surprised when I tell them that.

Unless you're interested in specific aspects of World War II history, there are a few really interesting historical things to see in Warsaw. So otherwise, just enjoy the city, meet friends, do stuff. What's your favorite electronic component? I guess favorite. The one that I use a lot and I have a lot of respect for is the inductor. Because I don't understand it and it's big and scary and has all these aspects that I have no idea about. So I'm not sure if that's the right answer. Don't remember the right answer.

Okay. How many people would your ideal company employ? One. Me. Hardware or software? Okay, you got me. I can't really answer that one. I guess I need to say software because I'm slightly less incompetent in software than in hardware. Favorite fictional robot? Marvin, of course.

Do you have a tip everyone should know? A tip everyone should know a tip everyone should know do things as opposed to not doing things I mean I know it sounds simple and stupid but most companies fail because they don't do stuff I've been in some of those companies

that's actually really good advice yes I've been in companies where never mind such a challenge to get over these. We're afraid to do stuff. And you're already ahead. So I wanted to ask you a little bit about a project I have been contemplating. Almost as seriously as I have been contemplating WASP identification systems.

We have a bunch of electronics and components in our garage. And on the floor right here. And on the floor. And everywhere. And I have this idea where I can just take pictures of the components, label them, then throw the component in a box, take a picture of the box, and if I ever want something,

I can just ask my magic application widget where it is. This seems like a weekend's worth of code. What do you think about that? Yeah, so nine years ago, I was in a similar spot, I guess. I was in the same situation. And I thought, well, this must be easy. Okay, that seems like a weekend's worth of code. So here we are nine years later,

and I still haven't finished that code. So my first impression and my first response would be, don't do it unless you intend to spend the next 10 years of your life writing software for managing your components. And the second, this idea of taking pictures, I guess it sounds good. And maybe these days we might actually be able to do something with it, given the AI that we've been blessed with.

But I strongly suspect that as we get down to details, things will turn out to be much more complicated than they seem. And this is in general the theme of my life as a software developer, especially writing code for others to use, is that things always are more complex than they seem initially. That is always true, I think. Have you ever had anything turn out to be simpler than you expected?

Second thought, no. Not really, I guess. I have, but only when it turns out there's already an API call for the thing I was trying to do that was complicated. Okay. But that just means somebody else did the hard part. Anytime it turns out simpler, I feel like I've done it wrong. Or you're missing something. Yes. Yes. Yeah, yeah, yeah, yeah. So that was the general theme of PartsBox. I really started it.

I mean, the initial motivation was very simple, and there was a trigger for it. I ordered some parts from DigiKey, and I received the bags with the parts. And I opened my drawer and placed the bags next to another set of bags that I had ordered two months earlier and forgotten about. And I looked at that, and I said, okay, there must be a better way. I need to get a grip on this. So, yeah, that's how I started. And then every, I guess, every day I'm discovering that there is more complexity there than one thing. I mean, part of it is just making sure you know where all of your stuff is, that becomes interesting for larger companies because they want to know where all their stuff is so they can do like just-in-time building.

And then suddenly you're in operations and trying to optimize everything. Yes. So that has been kind of my journey, I guess. I started with keeping track of where a part is or where parts are. And this seems simple in theory. You just keep a count. And for every part, you keep a count of, in a certain storage location, how many of those parts you have. That's what could be easier.

It's just a little database. Yeah, it's a small database. It's slightly more complex than a spreadsheet, but not by much. And then a couple of weeks down the road, you discover that you might actually want to keep that part in two separate locations, because sometimes you will have a reel and you will have some parts on cut tape and you want to keep those in two different locations. And lo and behold, your software wasn't ready for that. That was actually the limitation of some open source parts tracking solutions that I tried before. so so then you

modify your software and then sometime later you discover that that's actually not enough what what what you want to remember you want to remember that you have a reel and that you have cut tape and even if you place them in the same storage location you don't want to mix them up and this is where you enter a lot control territory and and you you want to track your parts in lots and keep history of each lot and that that's where it gets really complex and and and then of course once you have these parts you want to use them in your builds in your production whether those are prototype builds uh whether you're still doing a single board or whether you're doing mass production of hundreds or thousands of words so you want to consume those parts but which ones do you consume how do you configure a build how do consume those parts. But which ones do you consume?

How do you configure a build? How do you keep track of that? How do you upload your bill of materials? All of that explodes in complexity very quickly. So I've been working on that, like I said, for more than nine years, and I'm nowhere near solving many of the issues that people encounter. And we're not even talking about large companies, because I'm not writing software for huge companies.

We're talking about small-scale production, so anywhere from one unit to, let's say, low thousands. I mean, you do have a maker-hobbyist free tier for folks like me who just want to know where my stuff is. I do, and that was baked in from the beginning, and I intend to keep it that way. I try not to promise anything because I don't want to make promises that I cannot keep. But what I can promise is that I have always tried, and I will try very, very hard to keep that free hobbyist maker plan available for free without any strings attached. I think too many hobbyists simply get lost in their parts and don't catalog them enough or use a spreadsheet, which is criminal, really.

You should never use a spreadsheet to track your parts, believe me. So I do want... Oh, come on. I mean, sooner or later, there are so many problems with a spreadsheet. It's absolutely incredible. I could tell you horror stories about the data that I sometimes receive from people who sign up for PartsBox. And I offer to import their data. There is no auto importer.

I do everything manually because every data format that I received, every data file was different. And every one was interesting in a number of ways and contained interesting errors, which I discovered during the import. How about a shoebox full of crumpled receipts? You know, that might actually work better than some scratches I've seen. But anyway, going back to the hobbies maker plan, the idea is that I really want this to be free. It's not adware. It's not trying to upsell you to anything. I mean, it will try to upsell you if you're obviously a business.

But if you're a hobbyist, it should do most of what you need without any limitations. I designed the entire software architecture so that I can keep this low-cost and so that I can keep this pretty much forever. So, yeah, if you're a hobbyist, just feel free to use it and enjoy it. And you mentioned and then I mentioned in the breakfast comment, that you have had multiple companies.

Yes. So before PartsBox, actually PartsBox is a result of my professional experience. So before PartsBox, I co-founded, I wasn't the sole founder, but I co-founded some other businesses. And I guess the more interesting ones, the previous one was a business where we designed stereo vision cameras designed to be put in retail stores. And they were supposed to look at people and tell us where those people went in stores and what they did. So not specifically at people's faces. I didn't do any facial recognition or anything creepy of the sort. Think of it as looking at silhouettes of people.

So that was the company before. And before that, I was also a co-founder in a company that did set-top boxes before set-top boxes were a thing, I guess. So IP TVs, something that we take for granted these days, but about 20 years ago, this was definitely not the case. And it was a joint Polish and Japanese company. And it was pretty interesting.

Again, intersection of hardware and software, because we did a bit of both. Those companies grew into more than you. But for PartsBox, you're the only developer. And that was a natural evolution of my experience. The companies I co-founded before, all of them, including the ones before the two I mentioned, they grew into something larger. And there are many nice things about this, because you can build larger products, you can do more stuff, I guess. But there are many disadvantages. And the disadvantages is that you end up depending on many other people uh and i don't just mean co-workers because they're usually great i mean investors and and and managers that you get with that and and external money funding uh and and things like that so

at a certain point in life i simply got tired of all this and i said i want to have something which will be really independent where i will depend on as little as possible and and i said i want to have something which will be really independent where i will depend on as little as possible and and i will not take any external investment any external money i will not have anybody dictate what i can or cannot do i will just do something myself which i think is right um so i did and uh that's why i'm the sole developer and and the only person within the company and i actually intend to keep it that way. I mean, I might outsource little small parts of either software development or graphics design. But for the most part, I do everything.

Does that cause problems with companies who are like, what if you decide to stop doing this? Yeah, so I do get that question from time to time. And I have a carefully prepared answer, a very true one. So I always try to answer very truthfully. And the truthful answer is that I cannot promise I'll be doing this forever. I mean, something might happen to me, I might change my mind, nobody knows. I do intend to keep doing it because I enjoy doing it, but I can't make any promises. However, that said, if you look at the average lifespan of a VC-funded company, I'm already way past that. So I'm a pretty stable business if you compare me to what's out there in the market.

So another way to look at it is that the incentives are very stable, and they are very much aligned with what the customers need. If I do my job right, people pay me money. So if I make their lives easier, and if they find it easier to do their everyday work, they pay me money. If I don't, they don't pay me money. And there are no investors who push for customer growth at all costs or adding features at all costs or things like that. So I guess there are many ways to look at it and everybody needs to consider. But from the point of view of stability, a single founder company might actually be much better than a VC founded company.

Do you ever think about selling the company? Yes and no. I do have to think about this because I get offers regularly. But I think the electronics inventory and production control is a fairly small niche. So this is not a company that is really attractive to venture capitalists or to private equity investors so i do get some like inquiries queries and and i begin some discussions but usually it doesn't make business sense i mean they would need to pay a lot more money that they expect to and and it doesn't make much sense and the second the the i guess the second thing is that i don't really want to sell it because i i like what i'm doing okay i enjoy writing software. I like electronics. I use parts box myself. And another perk of this job is that my daily work involves talking to

engineers. The people who write me, the people who write to support partsbox.com, they are usually engineers. They're smart people. And actually, most of them are smarter than me. So when I explain something, I don't ever get angry with them or fight with them. I just explain how things are, and they understand it. And this is wonderful. This is so different from many other places where I worked at. Do you have features coming up that you can talk about? Yes, I always have features coming up. In fact, my planned feature list is growing longer. It doesn't get shorter. I do have an issue tracker, and somehow the number of issues in it always gets larger and larger. Oh, yeah, there is. There is actually one thing which is something I had really wanted to address for many years now.

So when you get your parts, assuming you remove them from little bags that they came in from your vendor or distributor, or if you want to place your own label, in that case, you want to produce that label somehow. You want to print it. And ideally, you would just click print in your browser and get label out of your printer. And that proves to be surprisingly difficult for many stupid reasons. Browsers are really bad. And there are many stupid reasons. There are not really a whole bunch of good reasons. It's not just that there are so many different label printers and they have different technologies and different sizes. There are browsers. And there are so many different browsers., and they have different technologies and different sizes. And browsers. And there's so many different browsers.

And they're all bad at printing. Yeah. Sorry. Yeah, but the reasons you mentioned are actually the right reasons. I mean, there are other reasons why this is actually difficult, but I'm talking about the stupid reasons. Oh, okay. The stupid reasons are that pretty much nobody cares about printing labels from a web browser. So this is not a common

use case so so things do not get implemented for that so so for example there there is no easy way for me to talk to the label printer right uh from within a browser i can use the standard print interface with all its you know formatting quirks and and portrait versus landscape dialogues different on every platform and so on. Or I can use WebUSB and talk to the USB device directly, which, as you might imagine, is not such a great idea. I was going to suggest that, but just as a joke. There you go. That sounds horrible.

Yes, it does. I'm going to write a printer driver. Yes, it does, inside a browser. I mean, it's absolutely insane. So there are no good solutions. But I do need to figure something out because people do want to print their labels. And the other problem with printing labels is that you need to design the label somehow. And I know it seems obvious.

I mean, yeah, I just want some text over here and the QR code over there. But it means that I need to build in a label designer into my software uh graphics design software which which is also crazy so um it's something that i wanted to do uh for many years now and and i could never find the time and i really hope to address it this year because um i know it sounds silly but this is actually really important yeah i mean as a consultant i wish all of my clients had stickers so that I could put, and instead I use label, I use a label maker and I put their names on it. But if everybody had a sticker, that would be great. And I think about PartsBox, if I could print out labels to identify where things were, I would want the icon for that customer. So it's not only the information of what it is, it's kind of who it goes with, who it belongs to. And then all of

the other, yeah, and everybody's going to want something like that. There's always going to be one more feature somebody wants. Yes, yes. So that's how you end up with a label designer inside your software. So I'm trying to navigate these dangerous waters and figure out something which would at least work for some people. Is your background in electronics or in software? I guess the correct answer is neither, because I'm a college dropout. I didn't actually finish anything because I got, I mean, I dabbled in many things, both software and hardware, both electronics and software. But then I got into business a bit too early. And this is a trap for the unwary.

Running your own business becomes very interesting very quickly, much more interesting than attending courses, college courses. So a little bit of advice for anybody who is still in college do try to finish that before you do anything else because it's very difficult afterwards so i guess my background is in neither but um i feel let's put it this way i feel less incompetent in software okay than in hardware so a little bit less of an imposter syndrome if I'm writing software and a bit more if I'm doing hardware. So not to get you into hot water, but we talked a little bit about what we should talk about on the show. And you sent me a list. And one of your bullet points was electrical engineers are terrible at writing software.

Could you expand upon this? This is controversial? Well, yes. I didn't say it. Yes, and I'm getting myself into hot water. Yes. Well, let's see. Based on some software I have seen over the years,

written by electrical engineers, the software is terrible. So that's why the bullet point was there. I think that it's partly an educational problem. Writing good software is difficult. And even if you attend, even if you specifically are in software, if you learn how to write software in college, they won't teach you how to design well. They will teach you how to program.

They will teach you many aspects of parallel programming, for example, or concurrency. But they will not teach you how to design. And this gets even worse if you're into electrical engineering because you simply have fewer software courses. Maybe this has changed recently because recently everything is pretty much software for the most part. But at least it used to be that you had fewer software courses. As a result, what I often saw was terribly designed software

with terrible patterns. Like, for example, state machines, which were not explicit. They were somewhere in the code, but you couldn't really see them. You really needed to dig into the code and then draw the state machine on paper to understand what the code was doing. So things like that. And yeah, hence what I wrote. EAs are terrible at writing software.

You said patterns, and I think one of the things that is taught now that wasn't taught when I went to school was design patterns. And basically they are how software is the same in many ways and how there are solutions that are well understood to be good. Maybe not the best, maybe not the absolute perfect solution for this problem, but they're good solutions and you should start there. But only if you already know about design patterns and what they can do. And there are design patterns for companies, there are design patterns for embedded systems. I mean, I wrote a book about that, higher level software. But the other thing EEs don't always know about is data abstraction and how you can take a state machine and put it into a couple of structures and suddenly you have a state machine that is implemented in five lines. And nobody has to dig through what happens because it's much simpler to document a structure style. Do you have other things like that?

Or was that not what you meant? Yeah. I agree with what you said. However, I would take that a bit further. Because the design patterns that I see appearing in the embedded world, let's put it differently. There is too little cross-pollination, so to speak, between various areas of software development. So my daily work involves writing in a high-level language.

I write parts books in Clojure. It's a programming language, Clojure, spelled with a J in the middle. And to give you an example, Clojure has an asynchronous programming framework i guess or a small library which is called car racing and uh what what it does it basically provides you with an abstraction of channels and you can put stuff onto channels and you can do blocking reads or non-blocking reads but but that that's just one part the other part is that it it has what it calls a goal macro and and that's a way to take a piece of your code and write it sequentially.

So you want to read from one channel, then you want to write to another, then you want to wait on a couple of channels whenever something becomes available, then do something with that. So you're looking at sequential code. And the compiler takes that and turns that inside out, I guess, into an event-driven state machine. So kind of a really high-level transformation. You write sequential code, and you get an event-driven state machine. And that is fantastically useful. It's absolutely amazing. And I think this could be implemented in a number of languages and in a number of contexts and could be used. I'm not sure if you could call it a design pattern, but it's certainly an interesting

idea that I would like to implement it elsewhere. I also have another example. A number of years ago, I tried to use x86 assembly and tried to write some x86 assembly. And at the time, I was in a company and there were guys sitting next to me, and they were writing assembly for TI DSPs. So very long instruction TI DSPs. So very long instruction word DSPs. Which is very possible. Yeah. And we compared our tools.

So I guess a good metaphor for that would be that I was using a hammer to drive nails and they were using like high speed magnetic blast-o-matic nail guns with automatic feeders. I mean, there was such a gap between these tools. So they wrote linear assembly for multiple execution units, and they had this whole compiler that took this assembly and scheduled those execution units and did automatic register allocation and did a number of other things. And they could really focus on the algorithm and on using the right tools for the job.

While I had to do pretty much everything manually. I had a piece of paper where I had my registers, and I did register allocations manually. And I know there are slightly better tools. But again, this is an example where this cross-pollination would help a lot if we could just learn from each other in various disciplines and various places. I think there's definitely a case for that, and that's something I've gone back and forth between writing software for devices, embedded system stuff, and doing some app development here and there. And yes, the tool difference is striking a lot of the time.

And there's always stuff to complain about in whatever development environment you're in, but the amount of infrastructure you have as an app developer is massive compared to what you have as an embedded developer, although that's changing. And we complained about that differently on a previous show. But you're right.

It's something I've been kind of quietly hammering on for a long time, that embedded developers need to learn from software developers, and a little bit vice versa, too um but i think it's a good point yeah i think it goes both ways and and we are we are slowly getting there so so there's for example zephyr which which um i heard you you mentioned a number of times in the show and uh i got the impression that you seem to like it uh which makes me happy because I like it too. And I think at the very least, it provides a fairly good common code base for a number of platforms,

which we can kind of standardize upon. But even there, I mean, Zephyr, it's not something that solves everything. If you look at concurrent programming, for example, the abstractions in Zephyr, they are still the same abstractions that we had for the last 30 or 40 years. So most people are just using semaphores and that's it. And there's better things out there, so we could do more. Also, Zephyr has this

I recently tried actually using it for a real project and I discovered that there are many components which look very nice, but when you try to couple them together, they just don't fit together. Weird, yeah. And there are very surprising holes and things which you would think would be obvious. I came to Zephyr, for example, and the first thing I looked for was a button driver.

And if you're surprised by the name button driver, I mean exactly what I said. No, I know what you're talking about. I mean a driver for a button. Yeah. So I connected a button. There's no debouncing, and I want it to be debounced. And I want to get logical events. So whenever somebody long presses a button, I want to get a long press event, for example. And I want a number of those. And there was nothing of the kind, so I ended up writing my own button driver with a state machine.

Actually, surprise, that's not there. That seems like some pretty basic stuff. Yes, yes, yes. I was also surprised. I thought everybody needs that. But it seems that everybody rolls their own. So I did the same thing. I rolled my own.

I do intend to publish it someday because that might actually be useful to people. Okay, we should take this offline because I believe the show after this one is with a Nordic engineer about Zephyr. We'll write his outline. Yes. But I have forgotten what was popular. We were talking about the cross-pollination of software, higher level software stuff and embedded stuff and electrical engineering and all of those things. I mean, yes. It's all good.

It's all, we should do more cross-pollination as best we can, given we have to learn what we're doing for our jobs at the same time. And design patterns, I think, are the way to go, at least from software. They can be, yeah. But sometimes, like in embedded, the things he's talking about in Clojure, you know, C doesn't have a very good async or futures interface or any of that stuff. But we're getting better at active objects and other asynchronous. I mean, for a long time, the mental model was very serious. Embedded is catching up to software circa 1997. Blah, blah, blah.

No, it sounds flip, but it is behind. No, it's true. Partly because of the language. And C++ is advancing, so there's a lot of stuff in C++, but it's difficult to move to C++. And Rust has a lot of these features, but it's also difficult for various reasons, not all of them technical, to move to Rust. So, I mean, stuff is there,

and people can do it if they want, but they have to make an effort. So one thing that is worth adding at this point is that the Clojure lead developer, Rich Hickey, who designed Core Racing, when he presented it first, he explicitly stated

that he was not the one who came up with these ideas. Right. I mean, they were there way back, and somebody invented all this stuff. He just put them together and figured, well, this might work, even for a modern language, and he just implemented that. So the ideas are out there, and it's not like

they've invented something new. And I think this... I mean, many things were invented before, we just forgot about them. So it's worth doing some digging and looking around and doing that cross-planation. I've been reading a book. Sorry, I talk about off-subject. I've been reading a book where it talked about art is how you get people into a field.

You have to make things artistic and beautiful. And rituals are how you remember the important things. And, I mean, rituals have a definite connotation towards religion, but I think there are some things that I forget all the time. Important, like, look up new technologies, rituals that I just forget to do sometimes. And I wonder what kind of rituals we should have as embedded software engineers trying to stay current. That is a good question, actually.

Let me rephrase that. Do you have any advice for people trying to stay current? I'm afraid I don't. I mean, I am desperately trying to stay current. I'm trying to read about anything I can out there. Sadly, I'm very often disappointed. I see many things which become fashionable and become modern fads, which are obviously a bad idea, or at the very least an idea not for everyone, but they seem to be presented like an idea for everyone to use. But I am trying to look around and look for inspiration pretty much anywhere. But no solid advice there. Okay. I think it's really hard to just read about stuff. I really do. I mean, if you want, and there's always a time factor, right? So you can work on your job and do you want to learn more about your job, not on your job. So it's nice,

you know, it's great when you have a job that requires you or allows you to learn stuff, but it's so hard to, you know, finish work and then go read about, oh, I should go read about how development works on this other thing, on this other language and see if there's anything useful to pick up from that. I mean, that's a big hurdle to climb, at least for me. At the Embedded Online Conference, Jack Gansel said he sets aside Monday mornings for learning new things. That's a good idea. I thought that was kind of a good idea, to actually have time set aside.

And it should be employer time, although it's hard to convince your employer of that what if you're your employer employer time you say yeah i know we'll work for ourselves yeah yeah something related to that another bullet point which i've sent you is um i wrote that i can't bring myself to finish some of my electronics projects because they require writing firmware. And that's somewhat related to what Chris just said. After a day of coding, you would like to do something else. So I would love after a day of coding parts, working on design, I would love to sit down and do some soldering or electronics design.

And it's all great, but it turns out that in a modern electronics project, the actual building part is the smaller part. The larger part is that you end up with a microcontroller, which isn't that micro these days. I mean, those are huge machines. And then you need to write firmware, which is fairly complex. And I just can't bring myself to do it because it feels like work after work. So this is where I am today. And that's related to what Chris said. It's difficult to find time for learning after work if it looks like work. And that's why we need it to look like art. True. That's true. You mentioned about the NE555P.

Yes. Could you tell me more about what that particular part does and why it's cool? Okay, so that's a very interesting question because I'm actually one of the, I think, two users of parts books that do not have the NE555P in my collection.

But I wrote that. So the data point for anybody who is puzzled by why we're talking about this. The data point is that I did some data analysis on the collections of parts that HopBiz and companies have in PartBox. And I looked for commonalities. So I found, much to my surprise, that the NE555P is, at the first approximation, 100% of hop-based inventories. So almost everybody has this part on their shelf. And it's a timer.

It generates signals, basically. And the reason why this was puzzling for me is that, I mean, it used to be hugely popular a number of years ago. It used to be the part to get if you wanted to get into electronics, because you would get this chip, you would connect a bunch of resistors and capacitors to it, and an LED on the output side, and it would blink an LED in various patterns that you programmed it to using these resistors and capacitors. And it's a very versatile chip, but these days you can be much more versatile

with a timer that's built into your microcontroller. But then you have to write firmware. Exactly, yes. Which you hate after work. But still, I expected that people would go this way and people would use microcontrollers. And I didn't think people use a discrete chip for that. Because, well, who would do that? So, yeah, that data point surprised me. That meta-analysis is really interesting.

Did you do anything fun you can talk about during the chip shortage? No, not during the chip shortage. I do intend to do some things to remediate the chip shortage. Believe it or not, but the waves generated by the chip shortage are still out there. There are companies which have a lot of excess inventory and they're looking to get rid of it. There are other companies which are looking for chips of certain kinds, which some of them are still difficult to find. I want to somehow connect them together and make it easier for them to buy or sell parts. But that data point came out of this analysis where I simply made rankings of top components, which are in most customer inventories. And I did two rankings, one for hub-based and one for businesses, for companies.

And obviously, these rankings will be totally different. And I skipped the boring parts like resistors and capacitors because it's obvious that what the most commonly used part is, it's a 10K resistor. So if you throw that out, you end up with mostly semiconductors. And that's where it gets kind of interesting. One kind of amusing thing is that when I published those, I think for the most part, people didn't believe that they were real.

Because there are so many spammy SEO articles with top 10 something or top 10 whatever. And people looked at my list and they thought, okay, that's just SEO spam. That's just boring. And those were real, based on really real data. So it's good stuff. It's kind of interesting. You can find that on the Partsbox website if you're interested. And you can dive through. The reason why I find it useful is that we often, sometimes you go and see another engineer somewhere else, and you see him using a part, and you didn't even know that part existed. So this is a way to

learn about other parts, which you might not have otherwise heard about. And I think that's actually useful. I want to tie that back to design patterns and learning things, but nah. If you could go back in time to when you started founding companies, but I mean, you gave the excellent advice of staying in college if you can, because it's much harder to go back later. What other advice would you have for new founders? I have quite a bit of advice. It's advice that I would have given myself, I guess, if I could. So I guess first, if you're an engineer, stick to the real stuff, the technical details, the circuits, the code, basically stay in the trenches, don't become a manager. People think and the common assumption

is that you can start managing people. So you can become a CTO or a team leader and not write any code, but just talk to people and they will tell you what the difficulties are. And that's just not true, in my opinion. The only way to stay current and to actually have any kind of job satisfaction is to actually do the work. It might not be all the work, but it should be some work. So I do not believe in being CTO without doing any coding, for example, or electronics design. It just doesn't work. So that would be, I guess, the first bit of advice.

And that's based on a real mistake I made once in my career. I got detached from the technical details. I stopped writing code. And I had another layer, basically, between me and the code, the human layer, the people who came to me. And the people were great, but this never works. I mean, you can never really understand all the technical aspects without actually doing the work yourself. Number two, I guess I already said that doing things. Doing things is an underappreciated technique of achieving success. Just do stuff. Don't wait.

If there are things to try, just try them. And often you will find that you can discover very quickly if something is promising or not just by trying it. So, yeah. And the next bit of advice would be that there is, again, this is common knowledge, but there is no substitute for actually being there. So, if you build any kind of product that goes in the field somewhere or that goes out to users or people use it, you need to go there physically. You, in person, not remotely, not somebody, you know, filming with a phone camera for you.

You need to go there and you need to look around and you need to notice things. So as the military used to say, the map is not the territory. Not being there does not give you the full knowledge. And I found this is true so many times with so many systems that right now I really believe in that. And then I guess the final bit of advice, and this is somewhat peculiar and perhaps somewhat specific to me. I started to believe that contrary to common thinking, venture capital is not necessarily that great. It's not the only way to build a business. It's not even the best way to build a business. It's one of the ways to build a business. And it might be the right way for

your business, but it might not. So I would suggest not assuming that you need to go that way. And it's easy to get pressured into it, because if you look on the Internet today and the popular online forums, this is this kind of Silicon Valley culture that dominates. You need to get investors, you need to get investment, you need to show growth, and it needs to be hockey park growth, and so on and so on. And I do not agree. There are many ways to build companies, there are many kinds of businesses and and you do not need to get vc funding and then finally the just just a very simple one think for yourself i mean the the internet crowd is often wrong or perhaps not wrong is this is not the right word uh their advice might not be applicable to your case okay let's put it this way so i can't count how many

times i read about microservices or kubernetes or or things like that online and and and people kept asking me well does parts box run on kubernetes how are you dealing with scalability what if suddenly 50 million users come and sign up to your service how will you handle that and um i never i never got myself pressured into doing any of these things and i'm very glad i'm glad i didn't because they didn't make any sense for me so that's actually very common so so i would suggest thinking for yourself being independent and and making your own decisions that is good advice not always easy to follow but good advice um and then one more question about founding companies.

How important is it to keep an idea secret as you are going through the beginning of the company? Well, if you ask me, I don't think it matters at all. I really think what matters is execution, is what you do with the idea. Ideas are a dime a dozen. And if you can think of something, there are good chances that there are many other people in the world who thought of it. And many, if not most of those people, are smarter than you. And perhaps some of them have better resources than you. So I wouldn't really get too obsessed with that.

I don't really care about keeping secrets. I care about just doing things. Okay, there was one other bullet point you sent me that made me curious. That there are only 256 unique parts that are actually used. I think there are 250, wait a minute. 250,000? 250,000. Okay.

Not 256, because that really would be quite the data point. Yes. I mean, I feel like ST's processors are in the order of 250,000 at this point, given how many there are. And they have to use letters and numbers for the part numbers, so it must be quite a few. It must be a lot. But you say there are only about 250,000 unique parts. Yes.

Could you list them? I guess I could if you ask me to yeah and i found that to be really surprising uh because if you look at the market for electronic parts you expect there to be millions of of unique parts and there are i mean i feel like some of my digi-key searches have gotten me millions of different parts yes yes yes yes but but if you think about uh real usage what what people have in their inventories uh this this this particular data point it stayed remarkably constant over the years so 250 000 unique parts are what actually gets used in all hobbyists and commercial bills of all customers of parts box. And that's a pretty sizable sample at this point.

So obviously this does not represent the entire world. But that's, I guess, the popular parts. And I thought there would be more. I expected the number of popular parts would be around a million at least. And it isn't. And I mentioned that everywhere I can, because I'm surprised by how small the number is. As parts grew over the years, it grew to the 250,000 number, and then it stayed there. So I'm constantly puzzled, but I guess that means that even distributors could really focus on a smaller number of parts, or at least put more emphasis on a smaller number of parts.

Is this because there are 250,000 good parts, or is it because there are really only about 250,000 unique parts. I mean, when you say a 10K resistor, sure, there are a whole variety of them, usually involving precision or temperature variability or power limits. But it's still all just a 10K resistor. So that number includes all the variability that you mentioned so so those are 250 000 unique mpns so to speak um so all the variants of the 10k resistors are are in that number uh so so i guess that that's what people actually use and i really don't know what the reason for this is i mean i'm pretty sure there are many companies that use more parts than that or that use bizarre parts they're just not my customers uh but from my sample, this is the number I can come up with. And I also think that one reason why

people might not use other parts is that a lot of them in the long tail, so to speak, they're more difficult to find, they're more difficult to source. If they're less popular, they're more difficult to buy, obviously. And then you need to learn that they exist at all. I mean, searching for resistors is actually reasonably straightforward, where you can look them up by value. But if you're talking about semiconductors or chips, we don't have good techniques for chip discovery right now. If you don't learn about a chip from someone or from some other design

or from a distributor brochure, you don't have a lot of chances to learn about a new chip, right? Well, it's getting worse because it's not just, okay, we have a dozen 16 or 8-bit microcontrollers out there with a core set of five or six features that they add more of. Now it's, well, okay, so it's got, you know, 87 spy things. And, oh, it's got a neural processing unit with some number of tops. And so now the search space has gotten much wider because the kinds of features that can be in a microcontroller are so broad. Yeah, I don't know how you would narrow that down without knowing exactly what you're looking for. And then even then, it's like, how do I search for...

Yeah, some of the things are not easily searchable, right? Like peripherals are easy to search for how many peripherals you have. But performance is not something that's super easy to search for. And when you search for a number of cores, it's like, which kinds of cores? Yeah, are they high power, low power? Do you need two high power and one low power, or what? It gets very complicated. So on that note, you've touched on something that I really like to talk about, but please stop me if it gets too boring.

I really feel the pain because we don't have good data for our parts. We don't have good specifications. We have no taxonomy. We have no categorization. And that's something that the other industries somehow managed to do, but we haven't, even though we call ourselves engineers. So to give you an example, if you're looking for a component and you would like to filter based on the specifications, which specifications are applicable to the kind of component that you're searching for? There's no good source for the data. So manufacturers don't provide the data in a machine-readable format,

or some of them do and some of them don't, and everybody uses something different. And we don't have a good, like I mentioned the word taxonomy, some sort of a predefined set of specifications that everybody agrees on with certain units, for example. So none of that exists. And I run into that regularly because people add their parts in parts box, and there are some specifications.

So, for example, for a resistor, you will get resistance, and you might get power. And for some, you might get the maximum voltage, but not for all of them. But how do you know which specifications are applicable to the part you're looking at? And how do you actually filter parts or find parts based on the specification? So the examples that you mentioned, Chris, are fairly extreme because you mentioned microcontrollers, which are really full-blown computers at this point with with number of peripherals and these are extremely difficult to categorize or or or um summarize and and specifications but even looking at simpler parts even looking at what we call passives um even there we we we haven't gotten that in place so some distributors try to do something about this and and try to build a database with specifications,

but we all know that it doesn't work as well as it should, and that filtering leaves much to be desired, so to speak. I mean, but no fault, because there are so many parameters. You can't... For passives? Even for passives. I wonder if it's a problem of there's so many parameters or every manufacturer has a different way of talking about them. I don't know.

I have a question for you, actually. I don't think it's a problem of too many parameters. I think it's a... If we had an organization in our electronics world that would try to standardize some things and try to define a ground, a base set of parameters for every kind of part, then we would at least make a step forward. But we're not doing anything of the kind at this point. So obviously, yeah, you can characterize a part by millions of parameters. But there is a small subset that is actually useful.

So you know that, for example, for a resistor, you know that you'll be looking at resistance and power and package size, first of all. For capacitors, you'll be looking at capacitance and dielectric and breakdown voltage, right? And you will begin there. So even codifying that would move us forward, but we haven't even done that.

And there are no open standardized formats for publishing your parts data, which is bizarre in this world. I mean, there are all those databases of electronic parts, but if I try to go to a manufacturer website and use their API to access the parts that they offer and get some specifications, I can't for the most part. I mean, some of them do have this, but everybody does their own thing and and uh it's not standardized so i i think there is a lot that we can do here to make part discoverability much easier than it is now and this is tied to the number of parts being used i mean the let's let's look at it this way the the companies that are my customers are small and medium companies manufacturing electronics so they don't have the time to look and go for really special parts that

will make their design unique uh they use whatever they know uh that works and i think that's part of the reason why they they use only 250 000 unique parts if you're samsung you will spend a lot of r&d and your people will find the most bespoke part that you could possibly use that is specific to the thing that you're designing. But if you're not, you just use what you know. Okay. Anyway, some theories. Good theories, good things to think about, mind-expanding. Jan, do you have any thoughts you'd like to leave us with?

Yes, just one thought and and uh sorry if that sounds very general but but i've been trying to to to to follow this thought for a number of years now and i think it's got to be to good places so uh the thought is uh do the right thing if you look at many problems or many decisions in life, many times you think might seem complicated. Or if you read about stuff online, you might find about really complex dilemmas. And you will learn that everything has 10 viewpoints of looking at everything and decisions are difficult. But very often there is the right thing that could be done. And if you think about this for a moment, you will see that there is a right thing to do. And there are many wrong things. So just do the right thing that could be done. And if you think about this for a moment, you will see that there is a right thing to do and there are many wrong things. So just do the right thing.

I think if more people, especially politicians these days and in the world, just did the right thing, the world would be a much better place. That sounds like really good advice. Our guest has been Jan Richter, founder of PartsBox.

Check out partsbox.com. Thanks, Jan. Thank you for having me. Thank you to Christopher for producing and co-hosting. Thank you to our Patreon listener Slack group for their one question from the listener from DigiKey. Hmm. And thank you for listening. You can always contact us at showatembedded.fm or hit the contact link on Embedded FM. I'm not going to add a quote. Do the right stuff.