478: The Map Is Not the Territory
Transcript from 478: The Map Is Not the Territory with Jan Rychter, Christopher White, and Elecia White.
EW (00:06):
Welcome to Embedded. I am Elecia White, alongside Christopher White. Our guest this week is Jan Rychter. We are going to talk about electronics and software. Which for a show called "Embedded," seems quite reasonable for a change.
CW (00:21):
<laugh> Hi, Jan. Welcome.
JR (00:23):
Hi. Hello.
EW (00:25):
Could you tell us about yourself, as if we met at that big German Electronica conference?
JR (00:33):
Okay, let us try. The main reason why we are 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.
(00:48):
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.
(00:55):
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, resin casting, CNC, or woodworking.
EW (01:13):
We want to do lightning round, where we ask you short questions and we want short answers. And if we are behaving ourselves, we will not ask, "Which exactly?" or "Why?" Are you ready?
JR (01:24):
I can never be ready. This is the scary part, but let us go.
CW (01:27):
Favorite woodworking tool?
JR (01:33):
Plunge saw.
EW (01:34):
You are a serial company founder. What is your favorite breakfast cereal?
JR (01:40):
Unfortunately, chocolate muesli. Unfortunately, because that does not do my health any good.
CW (01:46):
It has got the muesli part. You are fine. <laugh>
JR (01:51):
<laugh>
CW (01:51):
What is one thing folks should be sure to do, if they visit Warsaw?
JR (01:56):
Ah. Visit at the right time of year, I guess.
CW (01:59):
<laugh>
JR (01:59):
One half of the year is basically terrible in Warsaw. So visited it in the summer, please.
EW (02:07):
No particular activity?
JR (02:09):
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 are 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.
EW (02:32):
What is your favorite electronic component?
JR (02:38):
I guess favorite- The one that I use a lot, and I have a lot of respect for, is the inductor. Because I do not understand it, and it is big and scary, and has all these aspects that I have no idea about. I am not sure if that is the right answer.
CW (02:54):
There are no right answers.
JR (02:55):
<laugh> Okay.
CW (02:56):
How many people would your ideal company employ?
JR (03:00):
One. Me.
EW (03:02):
Hardware or software?
JR (03:05):
Okay, you got me. I cannot really answer that one. I guess I need to say "software," because I am slightly less incompetent in software than in hardware.
CW (03:16):
Favorite fictional robot?
JR (03:19):
Marvin, of course.
EW (03:21):
Do you have a tip everyone should know?
JR (03:25):
Hmm. A tip everyone should know. Hmm. Do things. As opposed to not doing things. I know it sounds simple, it is stupid, but most companies fail because they do not do stuff.
CW (03:36):
<laugh> I have been at some of those companies <laugh>.
EW (03:38):
<laugh> It is actually really good advice. Yes.
JR (03:39):
<laugh>
CW (03:40):
I have been in companies where- Never mind. Such a challenge to get over the "We are afraid to do something. We will just sit around for a year."
EW (03:45):
<laugh>
JR (03:47):
You just need to do stuff, and you are already ahead.
EW (03:51):
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.
CW (04:10):
<laugh> And on the floor right here.
EW (04:12):
<laugh> And on the floor.
JR (04:13):
<laugh> And everywhere.
EW (04:14):
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?
JR (04:32):
Nine years ago I was in a similar spot <laugh>. I was in the same situation and I thought, "Well, this must be easy. That seems like a weekend's worth of code." So here we are nine years later, and I still have not finished that code.
(04:49):
So my first impression and my first response would be, do not do it, unless you intend to spend the next ten years of your life writing software for managing your components.
(04:59):
And the second, this idea of taking pictures, it sounds good and maybe these days we might actually be able to do something with it, given the AI that we have 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.
(05:20):
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.
EW (05:31):
That is always true, I think. Have you ever had anything turn out to be simpler than you expected?
JR (05:40):
Second thought? No, not really. <laugh>
EW (05:42):
<laugh>
CW (05:43):
I have, but only when it turns out there was already an API call, for the thing I was trying to do that was complicated.
JR (05:50):
<laugh> Okay.
CW (05:51):
But that just means somebody else did the complex- <laugh> The hard part.
JR (05:54):
Yeah.
EW (05:54):
Anytime it turns out simpler, I feel like I have done it wrong.
CW (05:57):
Or you are missing something. <laugh>
EW (05:57):
Yes.
JR (05:59):
Yes. So that was the general theme of PartsBox. I really started it- The initial motivation was very simple. There was a trigger for it. I ordered some parts from the DigiKey. 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. <laugh>
EW (06:21):
<laugh>
JR (06:21):
I looked at that and I said, "Okay, there must be a better way. I need to get a grip on this." Yeah, that is how I started. And then every day I am discovering that there is more complexity there than one thinks.
EW (06:37):
Part of it is just making sure you know where all of your stuff is. But once 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 just-in-time building. And then suddenly you are in operations and trying to optimize everything.
JR (06:59):
Yeah. That has been kind of my journey. I started with keeping track of where a part is, or where parts are. This seems simple in theory, you just keep a count- For every part you keep a count of, in a certain storage location, how many of those parts you have. What could be easier?
EW (07:17):
It is just a little database.
JR (07:18):
It is kind of like a spreadsheets. Yeah. It is a small database. It is slightly more complex than a spreadsheet, but not by much.
(07:22):
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 was not ready for that. That was actually the limitation of some open source parts tracking solutions that I tried before. So you modify your software.
(07:46):
And then, sometime later, you discover that that is actually not enough. 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 do not want to mix them up. This is where you enter a lot control territory. You want to track your parts in lots, and keep history of each lot. That is where it gets really complex.
(08:07):
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, whether you are soldering a single board, or whether you are doing mass production of hundreds or thousands of boards.
(08:21):
So you want to 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.
(08:35):
I have been working on it, like I said, for more than nine years. I am nowhere near solving many of the issues that people encounter. We are not even talking about large companies, because I am not writing software for huge companies. We are talking about small scale production, anywhere from one unit to let us say low thousands.
EW (08:54):
I mean, you do have a maker hobbyist free tier, for folks like me who just want to know where my stuff is.
JR (09:05):
I do. That was baked in from the beginning, and I intend to keep it that way. I try not to promise anything, because I do not 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.
(09:23):
I think too many hobbyists simply get lost in their parts, and do not catalog them enough. Or use a spreadsheet, which is criminal, really. You should never use a spreadsheet to track your parts. Believe me.
EW (09:37):
Why not?
JR (09:37):
I do want- Oh, come on. <laugh> Sooner or later, there are so many problems with a spreadsheet. It is absolutely incredible.
(09:44):
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.
CW (10:08):
How about a shoebox full of crumpled receipts?
EW (10:09):
<laugh>
JR (10:12):
You know, that might actually work better than some spreadsheets I have seen. But anyway, going back to the hobbyist maker plan, the idea is that I really want this to be free. It is not adware. It is not trying to upsell you to anything. I mean, it will try to upsell you if you are obviously a business.
(10:29):
But if you are 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. Yeah, if you are a hobbyist, just feel free to use it and enjoy it.
EW (10:45):
You mentioned, and then I mentioned in the breakfast comment, that you have had multiple companies.
JR (10:53):
Yes. Before PartsBox- Actually PartsBox is a, I guess, result of my professional experience. So before PartsBox I co-founded, I was not the sole founder, but I co-founded some other businesses.
(11:05):
The more interesting ones, the previous one was a business where we designed stereo vision cameras, designed to be put in retail stores. 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 It did not do any facial recognition, anything creepy of the sort. Think of it as looking at silhouettes of people. So that was the company before.
(11:34):
Before that I was also a co-founder in a company that did set-top boxes before set-top boxes were a thing. IPTVs. Something that we take for granted these days, but 20 years ago this was definitely not the case. 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.
EW (12:01):
Those companies grew into more than you. But for PartsBox, you are the lone developer?
JR (12:10):
Yes. Although I will take issue with the word "lone." <laugh> I do not feel lonely here. And it is not like the lone wolf. But yes, I am the only developer, and that was a natural evolution of my experience.
(12:25):
The companies I co-founded before, all of them, including the ones before the two I mentioned, they grew into something larger. There are many nice things about this, because you can build larger products, you can do more stuff.
(12:38):
But there are many disadvantages. The disadvantages is that you end up depending on many other people. I do not just mean coworkers, because they are usually great. I mean investors and managers that you get with that, and external money funding and things like that.
(12:56):
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. 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." So I did.
(13:19):
That is why I am the sole developer, and the only person within the company. I actually intend to keep it that way. I might outsource little small parts of either software development or graphics design, but for the most part I do everything.
EW (13:36):
Does that cause problems with companies who are like, "What if you decide to stop doing this?"
JR (13:42):
Yeah. I do get that question from time to time. I have a carefully prepared answer, a very true one. I always try to answer very truthfully. The truthful answer is that I cannot promise I will be doing this forever. 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 cannot make any promises.
(14:05):
However, that said, if you look at the average lifespan of a VC funded company, I am already way past that. So I am a pretty stable business, if you compare me to what is out there in the market.
(14:19):
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. If I make their lives easier and if they find it easier to do their everyday work, they pay me money. If I do not, they do not pay me money.
(14:36):
There are no investors who push for customer growth at all costs, or adding features at all costs or things like that. 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.
EW (14:57):
Do you ever think about selling the company?
JR (15:00):
Ah, yes and no. I do have to think about this, because I get offers regularly. But I think electronics inventory and production control is a fairly small niche. This is not a company that is really attractive to venture capitalists or to private equity investors. I do get some inquiries, and I begin some discussions, but usually it does not make business sense. They would need to pay a lot more money than they expect to, and it does not make much sense.
(15:35):
The second thing is that I do not really want to sell it, because I like what I am doing. Okay. I enjoy writing software. I like electronics. I use PartsBox myself. 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.
(15:58):
They are smart people. Actually most of them are smarter than me. So when I explain something, I do not ever get angry with them, or fight with them. I just explain how things are, and they understand it. This is wonderful. This is so different from many other places where I worked at.
EW (16:16):
Do you have features coming up, that you can talk about?
JR (16:20):
Yes. I always have features coming up. In fact, my planned feature list is growing longer. It does not get shorter. I do have an issue tracker, and somehow the number of issues in it always gets larger and larger. I am not sure if there is something specific that I should-
(16:39):
Oh, yeah, there is. There is actually one thing, which is something I have really wanted to address for many years now. When you get your parts, assuming you remove them from little bags that they came in from your vendor or distributor, or that you- Or if you want to place your own label. In that case you want to produce that label somehow.
(16:58):
You want to print it. Ideally, you would just click "print" in your browser and get label out of your printer. That proves to be surprisingly difficult, for many stupid reasons. Browsers are really bad.
EW (17:12):
They are many stupid reasons. They are not really a whole bunch of good reasons. It is not just that there are so many different label printers, and they have different technologies, and different sizes-
CW (17:23):
The browsers.
EW (17:24):
And there are so many different browsers.
CW (17:26):
<laugh>
EW (17:26):
And they are all bad at printing. Sorry.
JR (17:31):
Yeah, but the reasons you mentioned are actually the right reasons. They are the reasons why this is actually difficult. But I am talking about the stupid reasons.
CW (17:37):
Oh. Okay.
JR (17:37):
The stupid reasons are that pretty much nobody cares about printing labels from a web browser.
CW (17:43):
Ah. Okay.
JR (17:45):
This is not a common use case, so things do not get implemented for that. For example, there is no easy way for me to talk to the label printer from within a browser. I can use the standard print interface, with all its formatting quirks, and portrait versus landscape dialogues, different on every platform, and so on.
(18:04):
Or I can use WebUSB and talk to the USB device directly, which as you might imagine is not such a great idea.
CW (18:11):
I was going to suggest that, but just as a joke.
JR (18:15):
<laugh> There you go.
CW (18:15):
That sounds horrible. <laugh>
JR (18:17):
<laugh> Yes.
CW (18:18):
I am going to write a printer driver. <laugh>
JR (18:20):
Yes it does. Inside a browser. It is absolutely insane. There are no good solutions. But I do need to figure something out, because people do want to print their labels.
(18:30):
The other problem with printing labels, is that you need to design the labels somehow. I know it seems obvious, "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 graphics design software, which is also crazy.
(18:47):
It is something that I wanted to do for many years now, and I could never find the time. I really hope to address it this year, because I know it sounds silly, but this is actually really important.
EW (19:00):
Yeah, as a consultant, I wish all of my clients had stickers, so that I could put- Instead I use a label maker and I put their names on it. But if everybody had a sticker, that would be great.
(19:14):
I think about PartsBox. If I could print out labels to identify where things were, I would want the icon for that customer. It is not only the information of what it is, it is who it goes with, who it belongs to. And then all of the other- Yeah, and everybody is going to want something like that. There is always going to be one more feature somebody wants.
JR (19:40):
Yes, yes. So that is how you end up with a label designer inside your software. So I am trying to navigate these dangerous waters, and figure out something which would at least work for some people.
EW (19:52):
Is your background in electronics or in software?
JR (19:56):
I guess the correct answer is, "Neither." Because I am a college dropout. I did not actually finish anything, because I got- I dabbled in many things, both software and hardware, both electronics and software. But then I got into business a bit too early. This is a trap for the unwary.
(20:13):
Running your own business becomes very interesting, very quickly. Much more interesting than attending college courses. A little bit of advice for anybody who is still in college. Do try to finish that before you do anything else, because it is very difficult afterwards.
(20:29):
So my background is in neither, but I feel- Let us put it this way, I feel less incompetent in software than in hardware. A little bit less of an imposter syndrome if I am writing a software, and a bit more if I am doing hardware.
EW (20:48):
Not to get you into hot water, but we talked a little bit about what we should talk about on the show. You sent me a list, and one of your bullet points was, "Electrical engineers are terrible at writing software." Could you expand upon this?
CW (21:04):
This is controversial?
EW (21:06):
Well...
JR (21:06):
<laugh> Yes. <laugh>
EW (21:09):
<laugh> I did not say it.
JR (21:11):
Yes, and I am getting myself into hot water.
EW (21:12):
I might have said it before. <laugh>
JR (21:16):
Yes. Well, let us see. Based on some software I have seen over the years written by electrical engineers, the software is terrible. That is why the bullet point was there. I think that it is partly an educational problem. Writing good software is difficult. Even if you specifically are in software, if you learn how to write software in college, they will not teach you how to design well.
(21:52):
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. This gets even worse if you are into electrical engineering, because you simply have fewer software courses.
(22:07):
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.
(22:21):
For example, state machines which were not explicit. They were somewhere in the code, but you could not 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. Things like that. Yeah. Hence what I wrote, "EEs are terrible at writing software."
EW (22:42):
You said, "Patterns." I think one of the things that is taught now, that was not taught when I went to school, was design patterns. Basically they are how software is the same in many ways, in 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 are good solutions and you should start there.
(23:09):
But only if you already know about design patterns, and what they can do. There are design patterns for companies. There are design patterns for embedded systems. I mean, I wrote a book about that higher level software.
(23:22):
But the other thing EEs do not 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. Nobody has to dig through what happens, because it is much simpler to document a structure style.
(23:47):
Do you have other things like that? Or was that not what you meant?
JR (23:53):
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 us put it differently. There is too little cross-pollination, so to speak, between various areas of software development.
(24:08):
So my daily work involves writing in a high level language. I write PartsBox in Clojure. It is a programming language. "Closure" spelled with a "J" in the middle. To give you an example, Clojure has an asynchronous programming framework, I guess, or a small library, which is called "core.async." What it does, it basically provides you with an abstraction of channels. You can put stuff onto channels. You can do blocking reads or nonblocking reads. But that is just one part.
(24:39):
The other part is that it has what it calls a "go macro." That is 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 it. So you are looking at sequential code.
(24:56):
The compiler takes that, and turns that inside out, I guess, into an event driven state machine. A really high level transformation. You write sequential code, and you get an event driven state machine. That is fantastically useful. It is absolutely amazing.
(25:14):
I think this could be implemented in a number of languages, and a number of contexts, and could be used- I am not sure if you could call it a "design pattern," but it is certainly an interesting idea, that I would like to see implemented elsewhere.
(25:27):
I also have another example. A number of years ago I tried to use x86 assembly, and tried to write some x86 assembly. 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 word DSPs.
EW (25:47):
<laugh> Which is very possible. <laugh>
JR (25:50):
Yeah. <laugh> And we compared our tools. I guess a good metaphor for that would be that I was using a hammer to drive nails, and they were using high speed magnetic blastomatic nail guns with automatic feeders. There was such a gap between these tools.
(26:07):
They wrote linear assembly for multiple execution units. 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. They could really focus on the algorithm, and on using the right tools for the job.
(26:25):
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. 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.
CW (26:44):
I think there is definitely a case for that. That is something I have gone back and forth between, writing software for devices, embedded system stuff, and doing some app development here and there. Yes, the tools difference is striking a lot of the times.
(27:00):
There is always stuff to complain about in whatever development environment you are 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 is changing. We complained about that differently on a previous show. <laugh>
EW (27:15):
<laugh>
CW (27:16):
But you are right. No, I think- It is something I have been quietly hammering on for a long time, that embedded developers need to learn from software developers, and a little bit vice versa too. But I think it is a good point.
JR (27:29):
Yeah, I think it goes both ways. We are slowly getting there. There is for example, Zephyr, which I heard you mention a number of times on the show. I got the impression that you seem to like it, which makes me happy because I like it too. I think at the very least, it provides a fairly good common codebase for a number of platforms, which we can kind of standardize upon.
(27:52):
But even there, Zephyr, it is 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 is it. There are better things out there, so we could do more.
(28:13):
Also, Zephyr has this- I recently tried actually using it for a real project. I discovered that there are many components which look very nice, but when you try to couple them together, they just do not fit together.
CW (28:26):
<laugh> Weird. Yeah. <laugh>
JR (28:27):
And there are very surprising holes.
CW (28:28):
Uh-huh. Yeah. <laugh>
JR (28:29):
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 are surprised by the name "button driver," I mean exactly what I said.
CW (28:42):
No, I know what you are talking about.
JR (28:43):
A driver for a button.
CW (28:43):
Mm-hmm. Yeah.
JR (28:43):
So I connected a button. There is no debouncing, and I wanted to be debounced. I want to get logical events, so whenever somebody long presses a button, I wanted to get the long press event, for example. I want a number of those. There was nothing of the kind. So I ended up writing my own button driver with a state machine <laugh>.
CW (29:04):
Actually surprised that is not there. That seems like some pretty basic stuff. Yeah.
JR (29:08):
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 on my own. I do intend to publish it someday, because that might actually be useful to people.
EW (29:21):
Okay. We should take this offline, because I believe the show after this one is with a Nordic engineer, about Zephyr.
JR (29:26):
Ohh.
EW (29:26):
We will write a whole- We will write his outline <laugh>.
JR (29:34):
<laugh> Yes.
EW (29:34):
But I have forgotten what was-
CW (29:36):
We were talking about the cross-pollination of software, higher level software stuff and embedded stuff and electrical engineering and all of those things.
EW (29:44):
Yes.
CW (29:45):
It is all good. Do more of it.
EW (29:47):
We should do more cross-pollination as best we can, given we have to learn what we are doing for our jobs at the same time. Design patterns I think are the way to go, at least from software-
CW (30:00):
They can be, yeah. But sometimes in embedded, the things he is talking about in Clojure, C does not have a very good async or futures interface or any of that stuff.
EW (30:14):
But we are getting better at active objects and-
CW (30:17):
Right. Sure.
EW (30:18):
Other asynchronous- I mean, for a long time the mental model was very serial.
CW (30:23):
Embedded is catching up to software circa 1997.
EW (30:26):
Blah, b-blah, b-blah.
CW (30:28):
No! It sounds flip. But it is behind-
EW (30:29):
No, it is true.
CW (30:31):
Partly because of the language. C++ is advancing, so there is a lot of stuff in C++, but it is difficult to move to C++. Rust has a lot of these features, but it is also difficult for various reasons, not all of them technical, to move to Rust. Stuff is there and people can do it if they want, but they have to make an effort.
JR (30:49):
One thing that is worth adding at this point, is that the Clojure lead developer, Rich Hickey, who designed core.async, when he presented it first, he explicitly stated that he was not the one who came up with these ideas. They were there way back and somebody invented all this stuff.
(31:08):
He just put them together and figured, "Well, this might work even for a modern language." He just implemented that. So the ideas are out there. It is not like they have invented something new. Many things were invented before, we just forgot about them. So it is worth doing some digging and looking around, and doing that cross-pollination.
EW (31:30):
I have been reading a book- Sorry, talk about off subject. I have 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.
(31:44):
And rituals are how you remember the important things. 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. I wonder what kind of rituals we should have, as embedded software engineers trying to stay current.
JR (32:17):
That is a good question, actually.
EW (32:19):
Let me rephrase that. <laugh> Do you have any advice for people trying to stay current?
JR (32:26):
<laugh> I am afraid I do not. I am desperately trying to stay current. I am trying to read about anything I can out there. Sadly, I am 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.
(32:49):
But I am trying to look around, and look for inspiration pretty much anywhere. But no solid advice there.
EW (32:57):
Okay.
CW (32:59):
I think it is really hard to just read about stuff. I really do. There is always the time factor, right. So you can work on your job. And do you want to learn more about your job, not on your job? It is great when you have a job that requires you, or allows you, to learn stuff.
(33:15):
But it is so hard to 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 is anything useful to pick up from that." That is a big hurdle to climb, at least for me.
EW (33:31):
At the Embedded Online Conference, Jack Ganssle said he sets aside Monday mornings for learning new things.
CW (33:36):
Mmm. That is a good idea.
EW (33:36):
I thought that was a good idea. To actually have time set aside. And it should be employer time. Although it is hard to convince your employer of that.
CW (33:47):
What if you are your employer?
JR (33:48):
"Employer time," you say?
EW (33:49):
Yeah, I know. We all work for ourselves.
JR (33:53):
<laugh> Yeah. Something related to that. Another bullet point which I have sent you, is I wrote that I cannot bring myself to finish some of my electronics projects, because they require writing firmware. That is somewhat related to what Chris just said. After a day of coding, you would like to do something else.
(34:10):
So I would love after a day of coding, of coding PartsBox, working on design, I would love to sit down and do some soldering or electronics design. It is all great. But it turns out that in a modern electronics project, the actual building part is the smaller part.
(34:27):
The larger part is that you end up with a microcontroller, which is not that micro these days. I mean, those are huge machines. And then you need to write firmware, which is fairly complex. I just cannot bring myself to do it, because it feels like work after work.
(34:40):
So this is where I am today. And that is related to what Chris said. It is difficult to find time for learning after work, if it looks like work.
EW (34:49):
And that is why we need it to look like art.
JR (34:53):
<laugh> True, that is true.
CW (34:54):
<laugh>
EW (34:59):
You mentioned about the NE555P.
JR (35:00):
Yes!
EW (35:00):
Could you tell me more about what that particular parts does, and why it is cool?
JR (35:10):
Okay, so that is a very interesting question, because I am actually one of the, I think, two users of PartsBox, that do not have the NE555P in my collection.
EW (35:18):
<laugh>
JR (35:18):
But <laugh> I wrote that- So the data point, for anybody who is puzzled by why we are talking about this, the data point is that I did some data analysis on the collections of parts that hobbyists and companies have in PartsBox. I looked for commonalities.
(35:37):
I found much to my surprise that the NE555P is, at the first approximation, 100% of hobbyist inventories. Almost everybody has this part on their shelf. It is a timer. It generates signals basically. The reason why this was puzzling for me is that, I mean, it used to be hugely popular a number of years ago.
(36:03):
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. It would blink an LED in various patterns that you program it to, using these resistors and capacitors.
(36:18):
It is a very versatile chip, but these days you can be much more versatile with a timer that is built into your microcontroller. So I-
EW (36:29):
But then you have to write firmware.
JR (36:31):
Exactly, yes <laugh>. Which you hate after work.
EW (36:35):
<laugh>
JR (36:35):
But still, I expected that people would go this way, and people would use microcontrollers. I did not think people use a discreet chip for that, because well, who would do that? So yeah, that data point surprised me.
EW (36:52):
That meta-analysis is really interesting. Did you do anything fun you can talk about, during the chip shortage?
JR (37:00):
No, not during the chip shortage. I do intend to do some things to remediate the chip shortage. Because believe it or not, but the waves generated by the chip shortage are still out there.
(37:12):
So there are companies which have a lot of excess inventory, and they are 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. So I want to somehow connect them together and make it easier for them to buy or sell parts.
(37:26):
But that data point came out of this analysis where I simply made rankings of top components, which are in most customer inventories. I did two rankings, one for hobbyists, and one for businesses, for companies. Obviously these rankings will be totally different.
(37:42):
I skipped the boring parts like resistors and capacitors, because it is obvious what the most commonly used part is. It is a 10k resistor. So if you throw that out, you end up with mostly semiconductors. That is where it gets interesting.
(37:58):
One amusing thing is that when I publish those, I think for the most part, people did not believe that they were real. Because there are so many spammy SEO articles with "top ten something" or "top ten whatever." People looked at my list and they thought, "Okay, that is just SEO spam. That is just boring."
(38:20):
Those were real, based on really real data. So it is good stuff. It is interesting. Then find it on the PartsBox website, if you are interested. And you can dive through.
(38:33):
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 did not even know that part existed. So this is a way to learn about other parts, which you might not have otherwise heard about. I think that is actually useful.
EW (38:52):
I want to tie that back to design patterns and learning things. But nah.
CW (38:56):
<laugh>
JR (38:56):
<laugh>
EW (39:00):
If you could go back in time to when you started founding companies- You gave the excellent advice of stay in college if you can, because it is much harder to go back later. What other advice would you have for new founders?
JR (39:19):
I have quite a bit of advice. It is advice that I would have given myself, if I could. First, if you are an engineer, stick to the real stuff, the technical details, the circuits, the code. Basically, stay in the trenches, do not become a manager.
(39:37):
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 is just not true in my opinion.
(39:53):
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 does not work. That would be the first bit of advice.
(40:16):
That is based on a real mistake I made once in my career. I got detached from the technical details, I stopped writing code. I had another layer basically between me and the code, the human layer, the people who came to me. The people were great. But this never works. You can never really understand all the technical aspects, without actually doing the work yourself.
(40:35):
Number two, I already said that. Doing things. Doing things is an underappreciated technique of achieving success. Just do stuff. Do not wait. If there are things to try, just try them. Often you will find that- You can discover very quickly if something is promising or not, just by trying it. Yeah.
(40:58):
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.
(41:14):
Not remotely. Not somebody filming with their 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. I found this is true so many times, with so many systems, that right now I really believe in that.
(41:37):
And then the final bit of advice. 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 is not the only way to build a business.
EW (41:51):
Definitely not.
JR (41:51):
It is not even the best way to build a business. It is one of the ways to build a business. 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. It is easy to get pressured into it, because if you look on the internet today and the popular online forums, this is this Silicon Valley culture that dominates.
(42:13):
"You need to get investors. You need to get investment. You need to show growth. It needs to be hockey puck growth. And so on and so on." I do not agree. There are many ways to build companies. There are many kinds of businesses, and you do not need to get VC funding.
(42:28):
And then finally, just a very simple one, think for yourself. The internet crowd is often wrong. Or perhaps not- "Wrong" is not the right word. Their advice might not be applicable to your case. Okay, let us put it this way. I cannot count how many times I read about microservices or Kubernetes or things like that online. People kept asking me, "Well, does PartsBox 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?"
(43:01):
I never got myself pressured into doing any of these things. I am very glad I did not, because they did not make any sense for me. That is actually very common. So I would suggest thinking for yourself, being independent and making your own decisions.
EW (43:18):
That is good advice. Not always easy to follow, but good advice. 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?
JR (43:32):
Well, if you ask me, I do not 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. 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.
(43:54):
So I would not really get too obsessed with that. I do not really care about keeping secrets. I care about just doing things.
EW (44:04):
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.
CW (44:16):
250,000?
EW (44:16):
250,000.
CW (44:16):
Okay.
EW (44:16):
Not 256. Because that really would be quite the data point. But-
JR (44:22):
Yes.
CW (44:22):
<laugh>
EW (44:24):
I feel like ST's processors are in the order of 250,000 at this point, given how many there are.
CW (44:31):
And they have to use letters and numbers for the part numbers. So it must be quite a few.
EW (44:37):
<laugh> Must be a lot.
JR (44:37):
<laugh>
EW (44:37):
But you say there are only about 250,000 unique parts.
JR (44:43):
Yes. And that was really-
EW (44:43):
Did you list them?
CW (44:44):
<laugh> List them? <laugh>
JR (44:47):
<laugh> I guess I could if you asked me to.
EW (44:48):
Oh. No.
JR (44:48):
Yeah. I found that to be really surprising, because if you look at the market for electronic parts, you expect there to be millions of unique parts.
CW (45:00):
Yeah.
JR (45:00):
And there are.
EW (45:02):
I feel like some of my DigiKey searches have gotten me millions of different parts.
JR (45:07):
Yes. But if you think about real usage, what people have in their inventories, this particular data point, it stayed remarkably constant over the years. So 250,000 unique parts are what actually gets used, in all hobbyist and commercial builds of all customers of PartsBox. And that is a pretty sizable sample at this point.
(45:32):
Obviously this does not represent the entire world, but that is I guess the popular parts. I thought there would be more. I expected the number of popular parts would be around a million at least. And it is not. I mentioned that everywhere I can, because I am surprised by how small the number is.
(45:52):
As PartsBox grew over the years, it grew to that 250,000 number, and then it stayed there. So I am 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.
EW (46:13):
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 is still all just a 10k resistor.
JR (46:40):
That number includes all the variability that you mentioned. So those are 250,000 unique MPNs, so to speak. So all the variants of the 10k resistors are in that number. So I guess that is what people actually use.
(46:55):
I really do not know what the reason for this is. I am pretty sure there are many companies that use more parts than that, or that use bizarre parts. They are just not my customers. But from my sample, this is the number I can come up with.
(47:10):
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 are more difficult to find. They are more difficult to source. If they are less popular, they are more difficult to buy, obviously.
(47:24):
And then you need to learn that they exist at all. Searching for resistors is actually reasonably straightforward, where you can look them up by value. But if you are talking about semiconductors or chips, we do not have good techniques for chip discovery right now. If you do not learn about a chip from someone or from some other design or from a distributor brochure, you do not have a lot of chances to learn about a new chip. Right?
CW (47:51):
Well, it is getting worse because it is 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 is, "Well, okay, so it has got 87 SPI things." And, "Oh, it has got a neural processing unit with some number of tops."
(48:12):
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 do not know how you would narrow that down, without knowing exactly what you are looking for.
(48:25):
Even then it is like, "How do I search for-" Yeah, some of the things are not easily searchable, right? Peripherals are easy to search for, how many peripherals you have. But performance is not something that is super easy to search for. Instructions set-
EW (48:40):
When you search for number of cores, it is like, "Well, which kinds of cores?"
CW (48:43):
Yeah. Are they high power, low power?
EW (48:45):
Do you need two high power and one low power, or what it?" It gets very complicated.
JR (48:52):
On that note, you have 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 do not have good data for our parts.
(49:04):
We do not have good specifications. We have no taxonomy. We have no categorization. That is something that the other industries somehow managed to do, but we have not, even though we call ourselves engineers.
(49:15):
To give you an example, if you are 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 are searching for. There is no good source for that data.
(49:28):
Manufacturers do not provide the data in a machine readable format, or some of them do and some of them do not. And everybody uses something different. We do not have a good- I mentioned the word "taxonomy." Some sort of a predefined set of specifications that everybody agrees on with certain units, for example. None of that exists.
(49:50):
I run into that regularly, because people have their parts in PartsBox, 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 are looking at? And how do you actually filter parts or find parts based on the specification?
(50:16):
The examples that you mentioned, Chris, are fairly extreme because you mentioned microcontrollers, which are really full-blown computers at this point with a number of peripherals. These are extremely difficult to categorize or summarize in specifications.
(50:30):
But even looking at simpler parts, even looking at what we call passives. Even there, we have not gotten that in place. So some distributors try to do something about this, and try to build a database with specifications. But we all know that it does not work as well as it should. And that filtering leaves much to be desired, so to speak.
EW (50:54):
But no fault, because there are so many parameters. You cannot-
CW (51:01):
For passives?
EW (51:03):
Even for passives.
CW (51:05):
I wonder if it is a problem of there are so many parameters, or every manufacturer has a different way of talking about them. I do not know. A question for you actually <laugh>.
JR (51:17):
I do not think it is a problem of too many parameters. 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 are not doing anything of the kind at this point.
(51:41):
You can characterize a part by millions of parameters, but there is a small subset that is actually useful. For example for a resistor, you know that you will be looking at resistance and power and package size, first of all. For a capacitor, you will be looking capacitance and dielectric and breakdown voltage, right? You will begin there.
(51:58):
So even codifying that would move us forward, but we have not even done that. And there are no open standardized formats for publishing your parts data, which is bizarre in this world. There are all those databases of electronic parts.
(52:13):
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 cannot for the most part. Some of them do have this, but everybody does their own thing and it is not standardized. I think there is a lot that we can do here to make part discoverability much easier than it is now.
(52:35):
This is tied to the number of parts being used. Let us look at it this way. The companies that are my customers, are small and medium companies manufacturing electronics. So they do not have the time to look and go for really special parts that will make their design unique. They use whatever they know that works. I think that is part of the reason why they use only 250,000 unique parts.
(52:59):
If you are a Samsung, you will spend a lot on R & D, and your people will find the most bespoke part that you could possibly use, that is specific to the thing that you are designing. But if you are not, you just use what you know.
EW (53:13):
Okay.
JR (53:15):
Anyway. Some theories.
EW (53:17):
Good theories. Good things to think about. Mind expanding. Jan, do you have any thoughts you would like to leave us with?
JR (53:26):
Ah. Yes. Just one thought. Sorry if that sounds very general, but I have been trying to follow this thought for a number of years now. I think it has gotten me to good places. So the thought is, do the right thing.
(53:39):
If you look at many problems or many decisions in life, many times things might seem complicated. Or if you read about stuff online, you might find about really complex dilemmas. You will learn that everything has- There are ten viewpoints of looking at everything and decisions are difficult.
(53:58):
But very often there is the right thing that could be done. 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 the world, just did the right thing, the world would be a much better place.
EW (54:18):
That sounds like really good advice. Our guest has been Jan Rychter, founder of PartsBox. Check out partsbox.com.
CW (54:29):
Thanks, Jan.
JR (54:30):
Thank you for having me.
EW (54:32):
Thank you to Christopher for producing and cohosting. 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 show@embedded.fm. Or hit the contact link on embedded.fm. I am not going to add a quote. Do the right stuff.