Embedded - 222: Virtual Bunnie

Episode Date: November 10, 2017

Jonathan Beri (@beriberikix) spoke with us about his double life: Particle.io product manager by day, maker by night (and weekends). Jonathan wrote a chapter about piDuino5 Mobile Robot Platform in JavaScript Robotics. Product manager resources from product.careers and Ken Norton's Newsletter. For an alternate take, there is a good cartoon about effective product management from Henrik Kniberg. For getting into open source, see the guide from Github. Also, there is a newi-sh consortium, the TODO group, with guides and resources about running open source projects. There is also the often useful Google's developer documentation style guide. NerdRage’s video on the chemistry of etching The Essential Guide to Electronics in Shenzhen by Bunnie Huang Speaking of Robot Operating System (we did, briefly), IEEE Spectrum had a nice history of ROS.

Welcome to Embedded. I'm Elysia White, here with Christopher White. Our guest this week is Jonathan Barry. We're going to talk about Silicon Valley tech careers and after-work engineering. Hi, Jonathan. Welcome to the show. Hi, Chris. Hi, Elysia. Could you tell us about yourself? Sure. So, my name is Jonathan Barry Welcome to the show. Hi, Chris. Hi, Alicia. Could you tell us about yourself? Sure. So my name is Jonathan Berry, as you mentioned.

I am a product manager at Particle, a full-stack IoT platform. I'm a former Googler and gelato enthusiast. All right. Well, I know you've heard the show, so you are familiar with Lightning Round, where we ask you short questions and want short answers. And Christopher, why don't you go ahead and start? Favorite gelato? Banana. Really?

Banana. I did not expect that. No, that was really not what I expected. Tip you think everyone should know let's see um always always check polarity that's the voice of experience do you prefer to complete one project or start a dozen dozens multiple dozens hacker maker tinker, engineer, or programmer? Hmm. I would say, well, early in my career, I used to claim I was a computer scientist.

And now, I think I'm comfortable with maker. Favorite programming language? Hmm. Today, C++. Otherwise, JavaScript. Arduino Uno, Bigelow Black, Raspberry Pi, or something else? Lightning round question, huh? All of the above.

It really depends on who you are, where you are in your career, and the application. For yourself, for today, whatever you're doing today. I have an Uno handy pretty much all the time. Okay. Favorite motor? Ooh. There's a very, very tiny stepper motor. I think it's a NEMA 17, though.

Something or other, but it's so cute. It fits between your two fingers, and it's a stepper motor. That sounds like fun. A little tiny thing. Okay, so enough with the lightning round, unless you want to answer this question that way, which is could you walk us through your career? I think it would be harder to lightning round question.

Maybe not lightning round, but I'll try to keep it short. So let's see. Career-wise, I started, well, let me go back to college and kind of where I got to, how I got to where I am today. In high school, I was very much one of those science people. And somewhere along the line, I decided I wanted to build robots. And in order to build robots, I figured out that you need to know mechanical engineering, electrical engineering, and computer science. And fortunately, I knew a little bit about computers,

a little bit about electronics, and knew nothing about mechanical. So I said, okay, great. I'm going to go study mechanical engineering in undergrad, take graduate courses and become, you know, an electrical engineer expert and a computer science expert, and I'll be a roboticist. Check. Win, right? But as many of your listeners and people who go through college experience, I had a different path in front of me. So I started it as a mechanical engineer, which was so much fun, especially the hands-on parts, learning CAD and building prototypes. But the math part was not as fun,

especially applied math in mechanical engineering. There was this, I remember there was a very important class that made me decide not to pursue mechanical engineering. It was the statics class where it was just a whole quarter of beams. Yes. You know, a beam on the wall a beam on the floor you know how much will it deflect how much will it if you drop something on it which way will it go and i just it just didn't resonate with me um and i decided i didn't want to do mechanical engineering

anymore and looking at my previous coursework i said computer science i really had a lot of fun doing it i even liked electrical ones. So I switched to computer science. But not only computer science. That's right, that's right. So I switched majors and I had some classes to backfill. But I didn't know what I wanted to do with computers. I really didn't understand the industry. I had no one to really talk to about it. So I

decided to do a bunch of different internships. And this was probably lucky for me that I made this decision early on and just try completely different disciplines. So I did IT at a major hospital. What else did I do? I did AI, doing image processing for a crazy physicist manager, which is really fun, web and database stuff. And they all had fun parts to them. And I excelled in all of them. But it wasn't quite right for me. I didn't know why. And I got great advice from the chair of the CS department. He said, well, you know, you're not the typical software engineer. You know, you don't want to be in the basement of a computer lab and code there until five in the morning.

Have you thought of product management? And I had no idea what he was talking about. And at the time, you couldn't even Google the term product management and find anything useful. But I did some research and I met with some people in industry and decided I wanted to do product management. It seems like a good fit for me. So I wanted to learn more of the business side of the,

you know, of building products and found out that there was a brand new major at my university, which was a double major. So computer science and business administration, certainly a guinea pig program. I was one of four graduates with that degree, but it definitely helped me get into the product management. Okay. So product management to me are the people who interface between either customers or marketing, depending on the size of the company,

and the engineers. They're the ones who say, no, what we really need is for that button to do X or for the screen to be a little bigger or a little brighter. But also, sometimes the product managers can help with the entire state machine. It's like when you do this, when the user does this, that should happen.

But they do a lot more. Or how would you really describe that role? Yeah, not quite just people, persons, right? There's this sort of romantic narrative that product managers like to say that they're the CEO of the product, which means nothing and doesn't help anyone understand what you do. And to be fair, the industry doesn't have a good definition because someone might be doing product management as an engineering manager at a company. Or they might be an intern who does a little bit of product management. And it's really about the functional role I like to think about. And if you look at a small company,

let's say it's two co-founder company, right? What are they going to do, right? They have an idea of a thing they want to build, a problem they want to solve in the world. So somebody is coming up with the product. And then somebody is coming up with the design of it, if it has a user interface or user experiences. Then there's a technical person who's designing the solution

and implementing the product and building it. Eventually, somebody is going to have to sell it. Somebody's going to have to support it. And that is the bulk of typical companies, right? You have your executive team, your leadership team. You have your engineering team, your sales team, your customer support team, and maybe designers. And you'll see a lot of companies structured that way. But eventually, you're going to have to decide what to build and what not to build.

And one way to do that is to understand the customer, understand their pain points, understand the industry and competitors, understand your limitations as a company and where you should invest in or grow. And all that spits out and comes up with what the product definition should be. And the day-to-day of a product manager is writing product requirements. So saying, here's the things that we should do based off of all my experience, all my research, talking to engineering, talking to product management, other product managers, rather. And this is it. This is the from the mountaintop kind of thing.

What ends up happening, though, is some companies might have a person with a title program manager that's actually doing product management or vice versa. Or, like I said, engineering or the CEO might be doing some of that definition. But at the end of the day, it's what should we be building? What should we not be building? And it is, to me, sometimes a translation position. Because marketing looks at people in specific and in general, and engineering looks at the technology. And you need to find the overlap in order to create a product.

Oh, yeah, totally. Especially in the types of products I work on, which are developer products, which are deeply technical. The marketing team can really go out and tell a story, but they may not be in the position to understand how the technology works, especially if the technology benefits the customer in some way. So the engineering team is laser focused in on building and sometimes engineers have, don't speak marketing speak. So as a product manager, part of my responsibility is to tell that story and be that bridge, certainly. And it's good if it goes both ways. So many times the marketing requirements involve breaking the laws of physics. And so the program manager role, when the person who's filling it is from marketing, sometimes doesn't see the importance of understanding the technical pieces.

You come from a pretty technical background. Do you have trouble with the marketing people thinking you're too much of an engineer? The truth is all park managers have the largest imposter syndrome and we pretend to be marketing, we pretend to be engineering, we pretend to be marketing we pretend to be engineering we pretend to be sales so you wear a lot of hats and i have no marketing background except for the little bit in school i picked up but i have to understand the the sort of the science and you know black art of marketing in order to talk to marketing effectively and then i need to be able to understand you know speak like an engineer but not to become off, you know, naive and bridge the two. Constant challenge. And you talked about program management.

To me, that's the person who kind of monitors the schedules and plans ahead and deals with resources. Is that what you mean by it, too? Yeah, I think that's generally true. Certainly, I worked with folks who, their title are program managers, but they have a CS degree. And they fill the void oftentimes where a program manager manages projects individually as a standalone project or a larger program, and that's what a program manager would be. Could we get fewer things that are abbreviated PM? Yeah, maybe.

That's a little confusing. It's also product marketing, right? Yeah, I've seen it as PDM, PGM, PJM, PMM to try to disambiguate, and that doesn't help. And for a small company, it is very likely there is one person filling all of those roles. Yeah, totally. In many companies, they don't have product managers or program managers,

and the CEO and the engineering or the technical co-founder is that functional, that function. Okay. But you didn't stop doing hardware and software on the side, even though you decided that wasn't your career path. Right, right. So I was kind of guided on that path anyway, working on developer products.

So if we're building an SDK, I should have used the SDK in order to understand the pain points of our customers. So I was always coding even after college, but just not real code, right? Just samples. And at some point, I was in a conversation, and I can't even remember the exact conversation with some fellow computer science majors about embedded electronics, Arduinos. And I happen to know one kernel more than the rest of the group. And I was able to answer one question about, you know, LEDs or something to that effect,

which made me feel inspired. And I decided to pick up a SparkFun invent kit, do all the examples, and that really kick-started my career deviation, if you will, to be more on the embedded system and hardware side of the world. Was this while you were at Google or before that? This was at Google, yeah. Okay, and you were at Google for about six years and you left a few months ago. Yep, that's right. So did they approve of your extracurricular activity?

Was this your 20% project or was this entirely on your own and they never really knew? Well, a little bit of both. Google in general has always been encouraging for folks, whether they're in engineering or not, to explore outside hobbies, contribute to projects that may help Google and its brand, but also just for fun and interest, including open source or community projects. I had a couple hardware-related 20% projects, which were really fun to be part of, But that was well after I started playing around

on my own. I'd say, in general, one of the skills that helps keep a product manager sharp is extracurricular exploration. So reading every RSS feed you can around your industry and your competitors, or playing with your competitors' products or hardware, trying out new things so you can be sharp on whatever area you're working on. And so that felt natural to me. And I wasn't working on hardware. That just happened kind of by chance. But I started just doing a lot of extra learning and experimentation on my own. I think it's important even for engineers to look around their industry.

I remember after I left LeapFrog and then the Apple iPad came out, when I went to go have lunch with friends there, they hadn't ever touched one. I'm like, no, no, you have to understand this, this, this is a new thing. You really need to see it because it will affect how we teach kids to read and that's what you're doing so you can't just put your head in the sand and hope that your product's the best yeah companies people like companies in particular who don't use their own products and not i'm not even talking about dog fooding your own product but just be an actual user um it's really hard to empathize with your customer. And it's also hard to innovate because the moment you stop finding all the pain points of your product, somebody else will have found it and built a better thing.

Well, the flip side of that is companies that prohibit employees from using competitors' products like Microsoft for a while. You can't have an iPhone, you know, that that kind of thing which i think is equally distressing because then you tell yourself all sorts of stories about how great you are and then don't have any idea what the other stuff is yeah okay so you were at google you you had some extracurriculars and you were learning stuff and it fed into your job did it just like click over like after six months you had been working with your spark fun inventors kit and now you were an expert and and poof now your day job is embedded systems uh definitely not it was a multi-year journey um but there was there was an actual interesting inflection point. There was an open source project that was just coming online

for targeting software developers to play with hardware. And it was using Node.js, which was very new at the time. And it was having crazy ideas of talking to GPIO and Arduinos. It was called Johnny Five. You may have had it mentioned on your podcast. I think so. I think I remember that, yeah. And it was just a very simple idea that JavaScript is event-driven,

GPIO is event-driven, let's use JavaScript to control GPIO. And Rick Waldron, who created the framework originally, was at a JSConf, and I watched this video, and I said, I get that. I understand what he's saying. I understand how to code in that.

I can go build a little robot. And on stage, he had a little robot that was driving around and had a sonar sensor and it avoided obstruction. But there was one thing that really bothered me about his demo, and that was it was wired. He had a really long USB cable hooked up to his laptop while the rover was moving around the stage. So I said, hey, here's a challenge. I can make that wireless. It had a Raspberry Pi on

board. So why not just put a wireless transceiver on it and a little battery pack and make it go. It didn't actually have a Raspberry Pi on board. It just had an Arduino Uno on board. So I said, let me take a Raspberry Pi, which was the first version wireless card in a battery pack. So I did that, and I published my source code, and I tweeted at Rick saying, hey, I think I made the first wireless Johnny-Five.

So that helped me become part of the community, helping people port projects to Raspberry Pi and was helping Rick and the other contributors to making work on Raspberry Pi, writing device drivers for motor controllers, and just generally being the Raspberry Pi guy for a while. But you had a full-time job at Google, which is not known for being like full-time, 30 hours a week sort of full-time.

Yeah, that's right. But it was interesting because it helped scratch an itch. And I think at that time, I was doing a little bit of the same thing and it was getting a little bit slow in my day job. So my brain had this extra opportunity of processing and being creative. And so it was a good balance, especially where I was. I find that after work stuff for me is usually the opposite of whatever I'm actually working on. So if I'm doing something that involves a lot of management and a lot of people work, then I'm happy to code after work. But if I'm coding all day long, that's not what I want to do when I get home. Yeah, I guess I don't code all day long. I haven't done it for a while. So usually,

usually when I'm home, I'm doing coding. That's a good observation. I think it's the same. Well, I mean, would you want to come home and do the product management and people interfacing? How do you do that as a hobby? You yell at your pets? I already do that. I guess that's what I do. No. I mean, open source products still need people to help limit the scope i mean we can build

anything we want to uh what are we gonna ship next week even as an open source product you still have to absolutely ship things and i i would say knowing um quite a few open source maintainers the hardest part of of running a big project, or even even a small one that has a lot of passionate users is the the non coding part, right, the figuring out what to build next, the roadmap planning, the marketing side of it, trying to get the word out there. But no, I don't come home and do that. And so this, this difference between what you do during the day and what you do at night, is that how you avoid burnout? I've definitely been burnout in my career in the past.

And it had nothing to do with the balance between work stuff and non-work stuff. It was really burnout at the job. And the way I manage burnout has been recognizing it and switching, switching out something, whether it's the field I'm in or the vertical, maybe it's the team or the location. But the sort of the daytime and nighttime has been more about what I'm doing today is while it's interesting and it's stimulating, it's not scratching one itch, whether it's deeply technical or fun and interactive or, you know, interfacing with lots of humans. So that doesn't help me with burnout per se, but definitely helps me round out my overall, I don't know, happiness. Cool.

How do you identify burnout? You know, in the times that I've been burnout, it's been through external, you know, friends and colleagues. A manager who noticed that I'm just, I'm not the same and called me out on it. That was probably the first time I had career burnout. And then just, you know, friends and family saying, you're coming home every day. You don't want to talk about work. You're not happy. You don't light up when you talk about what you're working on. Something's different. And I think I've gotten better at it over time. So I haven't been out in a while and recognizing it before it happens as my, you know, the way I feel about my job changes. Try to course correct before it happens. It's hard.

I think a lot of us experience burnout. And I don't notice I'm doing it. And when I tend to start the cycle, it's very much a spiral for me where I will do more and more code and stare at the screen for longer and longer and somehow work so much harder, which makes the burnout go faster. What I need to do is walk away and get perspective and not just stare and hope it gets better. Taking the steps is required, but not usually what my mental frame tells me I should do until long after I should have done it. Yeah. And I found that in those times of starting to get burned out, I'll even take on more responsibility or more complexity versus the opposite of what you just described.

Yeah. Yeah. Sometimes I need a simplification and sometimes I need something more interesting to work on. And I'm working on something that's boring and so I'm going to do it the bestest I ever can, even though that is pointless at some level. Yeah. I think there's a lot of confusion sometimes about whether it's burnout because you've really worked yourself to the, you know, to ashes versus being bored. There's different kinds of things. And I've experienced both and you feel really tired when you're bored, had a job, but then you go on to another, you quit that job and go on to a much more challenging job and immediately

things pick up. So it's not that I was really tired. it was not that my brain was used up it was that i was bored but there's definitely been the other way too where it's like i can't think anymore and then you go to a new job and you still can't think anymore that requires time that that's a strained muscle sort of problem oh exactly okay you mentioned robotics and, and saying, okay, that robot shouldn't have a wire, which I think is true of all robots. Uh, and you were one of the contributors to the JavaScript robotics, uh, book from make, what did you write about for them? Yeah. So the, that, that whole experience of making the first wireless Johnny five robot

and documenting it and helping the community was basically, I was offered and asked to contribute my chapter about that experience and a little bit about the history there, but more about building a mobile robot. So I documented the experience of doing it in the beginning, but really a more modern and cleaned up way of building that robot. And for me, it was my first time authoring anything that was published and doing high quality pictures and trying to being very pejorative and reduce complexity for the reader was a lot of fun and a lot of work. A little bit, yeah. What were the hard parts about it?

I would say it's very easy to write a lot of words. Go NaNoWriMo! Right? To be Chaucer and get paid by the word would be fantastic. But I think it's really hard, and I'm very humbled and respect people who can write fewer words that are more instructive. So starting with this really long draft, no pictures, and had to get it down to a certain page count.

But the instructions, for example, in the book chapter, you use the Raspberry Pi and you use Node.js, and it's running on the Raspberry Pi. Well, when I built the first robot, Node.js wasn't officially ported to the ARM architecture. So I had to do cross-compilation and deal with whole sorts of craziness to get that to work. And when I started the chapter, there was a unofficial port of ARM and Node.js. So, the instructions were, you know, here, go download from this sketchy website and make sure it works and everything's okay. But towards the end of the publishing, before the publishing date, there was an official port and I had to scramble and rewrite that. And that changed the steps you do and the troubleshooting area. And just that whole

process of writing really clear and concise and infallible instructions was just so hard. And having it depend on open source things that change, that's scary too, because you don't want it to be out of date right away, but open source things like Johnny5 can be a little house of cards-ish. Did you run into more problems in that area? So when the book was published, it was all good. It was all nice and stable.

Johnny5 was okay. Node was okay. It was a year later or a year or two later, or somebody on Twitter reached out to me saying, Hey, you know, all this has changed. And it wasn't because there was the swell of changes in the open source community and breaking things and making it chaotic. It was that Johnny five released a motor library that was well designed and worked, you know, worked. And that wasn't available when I wrote the book. So they just asked me, hey, here's all this code that you put. And I think I can just use this one line instead. Could you help me make it,

you know, figure it out. So I spent some time and I just simplified the example code. So there's somewhere a, you know, addendum to the book about, you know, half the code kind of thing. And so you have to maintain your own open source code. Open source code that lives in a book forever. Yes. That can get tough. I mean, because it can be, it seems like, oh, I'm going to write this chapter in a book. It's going to be, it's going to take me a while, but then it's going to be done, but it's never really done. Is it? No. And I would say what's interesting. One thing I learned from that experience is when you, when you work on open source projects, which, which I do for, um, for work and you contribute to the whole stack, whether it's all your own code or you're using other people's projects that you feed back to,

it makes documenting things a little bit easier, right? Because at least you control part of your own destiny. But if you're building something or just running a book, for example, on code written by everyone else but you, you have no control over its fate. And that becomes a lot more of an interesting challenge to maintain and deal with. Do you have any advice for people looking to get into open source? Yeah, yeah. There's actually, in the last year or two, been some really good resources published online from how to design an open source project, from the engineering aspect to how to maintain, how to deal with bad actors and creating a community to welcome people.

GitHub released a bunch of content. Google released a bunch of content. And there's all these great tools now for automating pulled requests and, you know, still issues, etc. So it's actually a really good time to be an open source. Okay, we'll get some of those links from you so that I have them for the show notes. Yeah, definitely. It's funny. I like open source. I'm willing to write code that is open source, but I don't necessarily want to play in some of the open source groups that aren't known for being nice. And since I don't really know any of them that are known for being nice, I just kind of do my own thing and don't worry about everybody else. How do you find a community that's open and accepting and is a community for yourself?

Yeah, that's a great question. When I started my career, I was in open source, and the company I was at contributed to open source. And I had no idea that there were toxic cultures in open source. And I was just completely oblivious to it, partially because who I am and which area I was in. But there are horrible black corners of open source. But like I said, this is a great time to be in open source because there are now communities who just don't allow that,

whether it's organic or big companies behind it because of press reasons. And you're starting to see codes of conduct and lead maintainers shutting down negative comments and blacklisting people who are just toxic to the community. So there are certain signals you can look at when you decide to use a project and then also contribute back.

How they manage their community and their forums and things like code of conduct, et cetera. I guess looking for a code of conduct is a really good start because it's fairly rare still, sadly. Yes, totally. The Linux kernel, may I just have that? Sorry. Back to robotics.

Robotics is such a way to get people addicted to playing with the hardware. Because seeing things move is magical. But it's tough to get it from the uncanny valley of technology. And not uncanny as in robotics uncanny, but there's this huge gap from proof of concept to prototype to real thing. And actually, I find a lot of times the proof of concept phase is actually really hard to get to. Because just because you've got an LED to blink or a motor to turn,

it's not actually proving out your core idea. In the software world of mobile apps and servers, I feel like the industry has helped bridge that gap where you can say, well, I built my web app in a hackathon. Great, now I can go out and build a product. Where in the hardware, embedded, robotics, IoT, all these different spaces, we don't have good tools to get us from Blinky VLights to proof of concept yet. They're getting better.

I mean, we went to our local electronics store, and they had a whole wall of new small dev kits for cheap, and they had all the different sensors and a decent plan for putting together something fairly large. I was impressed. And I mean, SparkFun, I remember when SparkFun started and you could buy jumper wires and it was sort of magical not to have to solder everything together. It is getting better, but robotics especially is one of those spots where it's still really hard because the power requirements, I'm not a power engineer.

I'm not even a hardware engineer. I just want to make, I want to type on my little keyboard and I want it to move. Are we going to get someplace that's easier to get to proof of concept soon, do you think? Yeah, and you hit on a good point around dev kits and breakout boards. The sort of world of complex projects, I think of robotics and IoT kind of as these really complex problem spaces

are actually complex because they're systems of systems, right? So, you know, your sensor is not just a sensor, it's a fusion algorithm and a serial protocol, and then there's an aggregator, and then that's before the brains of the operation actually do anything useful. And with DevKits, right, these sensor modules,

they simplify some part of it. And the accompanying library that is now produced and available through, you know, their Arduino IDE or Adafruit is simplifying parts of the subsystems so that you can construct these more complex systems more easily. And I totally, I see that path. When it comes to specifically robotics, there's a huge opportunity there. I don't know if you've played with Ross and like me hit your head against the wall. So much.

It was so cool. It was so fascinating. And I managed to read like two whole books in order to get it working and functional. And then I couldn't figure out how to simulate my robotic arm because I just don't have enough mechanical knowledge to know how to do linkages. And this is where I like hang my head and my shoulders down. I'm like, we have so many other tools in so many other areas to build far more complex systems than your basic robotic simulation. But nobody's built it for robots yet.

I've seen a visual designer who can mock up a mobile app, a fully functional mobile app, all graphical, um, with high performance UI, and it actually spits out the full app when it's done. Um, and the same thing in, in sort of simulating a, uh, you know, a quadruped that just needs to kind of limp around is just so hard and so complex. Uh, and I actually had a fun lunch. I got invited to the X Lab, to now Alphabet X, to talk about some of the roboticists there.

And they have a background in academia and they all use ROS in university. And they told me the story behind ROS, how it started out in academics and all these academics knew nothing about developer tools and user experience and they just needed a thing that could communicate from a very expensive sensor to a very expensive computer so they just made a thing and it just kind of worked and then over time people started

contributing things that kind of worked and uh nobody liked it but it just all kind of worked and they got through their you know their dissertation and their graduate work um kind of limping along. And it's been good enough up until now. But when you build these really complex systems with people who don't have, you know, six, 10 years of education, you know, kind of works is not how it makes it easy to build that proof of concept. You really need to simplify the individual components down.

Exactly. And I mean, this goes back to open source and how fast it changes and how it can be chaotic and robot operating system had a lot of that with it where there was if you were on the wrong version and you wanted a library from a different version you just either you considered the phd would do that would allow you to do that or you just kind of waved goodbye to that little future and hoped someday it would come about? Very House of Cards-ish. I'm torn because on one level, yeah, I think there should be better tools and things should be easier. But on the other, I do worry about the commoditization of hard things.

I mean, some things are hard because they're hard. And if you don't understand the background behind them, then whatever you're building, you don't truly understand. Do you know where I'm going with this? Oh, absolutely. And I mean, that was, I fell apart when I had to get to the linkages because I didn't truly understand how my robotic arm worked. Right, but if somebody fixed that for you with a tool to just spit out the linkages, you would have moved on to the next.

Yes. I don't, but I learned a lot doing it. You don't have to learn everything from first principles. Right. Right. Yeah. And I think there's this very important role for those who are deeply,

you know, know a domain really well for the next generation sort of pushing the, the deeply, you know, know a domain really well, for the next generation, sort of pushing the envelope. You know, I'm starting to learn a little bit about machine learning and trying to wrap my head around TensorFlow and the other libraries out there. And I will never invent a new, you know, algorithm or come up with, you know, quantum computing and machine learning. And it's just, I don't have the capacity, I don't have the education or even the desire. But I can start using machine learning in our future products because I understand it enough and I can make it do a thing.

So I can talk to the people who know the, you know, are the PhDs and can invent the new thing. But for this large, there's a large opportunity, basically, for people who don't understand how the thing works, but still make it useful. Maybe machine learning is scary to let people just build things without understanding but in other domains that might be that might be very applicable crisper in genetics yeah just let's just try it it'll be fine if we don't get it right this time, we'll get it right next time. I have been doing some machine learning as well, and it is frustrating because I want to understand every piece,

but I also want to not spend five years understanding every piece. It's very much I wish I could matrix-style jack in and get all the information just downloaded so that when I run into a problem where the back propagation is leaky and that's the cause of all of my errors, I don't look around and go, I don't remember what back propagation is, you. It is hard. There's this war between making things simple enough to use and hiding the complexity that makes them what they truly are.

Yeah, and I think you hit on a point earlier. We just need the Spark Fund for robots or the Spark Fund for machine learning. Give a simplification down enough where it's still powerful for those who invest a little bit, but not so much so that the learning curve is too high to get started. Oh, well, then skip TensorFlow and go straight to Keras. That was so nice.

It was very Spark fun-ish. I mean, here's a module, here's how you use it, here's how you don't use it, and don't worry about all the TensorFlow pieces. I like Keras. Cool, check it out. I know not everybody did but uh okay so uh robot but you so we're talking about robotics in general but you have a specific robotics task you have been

working on recently involving boards like pcb boards could you tell us about it yeah so one of my dozens of projects i've started and not finished is actually in the space of making things at home and quickly. And there was this great debate on one of the somewhat toxic Hackaday articles a couple years ago about cheap PCBs, nobody needs to make their own PCB. And then the Greybeards are, you know, it's really easy to add your own PCB. I've been doing it since the 70s. What do you young kids know about anything? And I thought about it. And I had no opinion, because I wasn't making PCBs back then. But there was something about the immediacy of having a design. And coming from more of the traditional server and mobile world,

you write some code, you hit run, and you get a response. It changes the way you build things, because you can iterate and perfect your design a lot more rapidly. So I said, well, what's the rapid iteration for electronics? And I did some math in my head saying, okay, well, if you took the entire process of building a board, designing a piece of electronics, and you reduced everything you can down to zero, that's all the software. So you download a Gerber file, you download some code off the internet, you have a mechanical CAD part, the thing you can't reduce down is the manufacturing of the board. Even the assembly of the board, you can do by hand pretty quickly. So I said, well, how would you go about making a

desktop tool that helps you make PCBs? And I thought about etching. And I learned how to etch when I was a kid. My dad taught me in his garage, and it was messy, and it was toxic, and it's actually not very precise, and those who can do it really well have spent years perfecting it. And I said, hey, you know, it'd be fun to build a machine that automates the process of making PC boards, specifically etching,

because it takes the costs and the resolution down, right? Because you can mill a PCB, but it won't be as, you know, can't do fine pitch footprints or whatnot. But I can use automation and electronics to make it precise. So that's what I've been working on as one of my dozen projects.

How's it going? It's going a little slow. I started it earlier this year and then had a lot of life career changes along the way. But what I've done is, what I always do when I start a new project is go deep and understand, you know, the chemistry of etching, understanding the manufacturing process and processes that are used to when chemicals are used in a manufacturing process. So I have a bunch of pumps and some fluids and some etchings, some boards of different types. And I'm starting to write some, you know, system code to pump reliably. And I haven't got

to the chemistry part because I don't know enough about chemistry, but there's a fantastic YouTube channel called Nerd Rage where he explains chemistry and even has an episode on the chemistry of etching. So now I'm trying to see, you know, what based chemicals should I be using that are both efficient and actually environmentally friendly. So I'm playing around with some chemicals now. How are you motivating yourself to continue this

instead of going on to number 23 or 24? I get my inspiration for these projects by oftentimes from people talking about it. Somebody on Twitter talking about making PCBs or in a conversation around someone who runs a makerspace and saying, hey, we buy everything from Wash Park, but it takes forever to do a class. So that keeps on re-inspiring me.

It is often re-inspiring, sometimes it's guilt making but um it is motivating either way i definitely feel guilty um after i have this great conversation with someone about an idea and i see them a couple months later and i haven't made enough progress to talk to them about it and they're like how's your project going and you're like yeah i started a new one yeah exactly yes i've been there i've so been there uh for work uh you are doing you are a product manager for particle and um they make things like the, which is a cell modem-based IoT platform. And it's impossible to search for, because when you search for Particle Electron, you do not get the help documents. Would you believe that they changed their former name to be more SEO-friendly?

Particle I-O? Yeah, it used to be Spark. Oh, right, yes. Yeah. That was a lateral move, sorry. Yeah, yeah. I'll give that feedback to marketing. I have learned to type particle.io and then whatever I want,

and that usually gets me what I want. How is that going? Oh, it's great. It's been a lot of fun working there. One of the reasons I went there was I really enjoyed the founders who I met early on. And so now being part of the sausage making is quite exciting. Do you have any big plans you can tell us about? Big plans?

I can tell you general big plans and kind of what I'm responsible for at Particle. So I came on board to be product manager number two. And we fuel our business in two halves. One is what we call prototyping. The other one is platformer enterprise. So we work on things from hardware to firmware to cloud connectivity and tooling to help you build your true proof of concept.

This is that idea of what a true proof of concept is that I mentioned earlier. So I look over all those pieces. And then once you have your proof of concept, there's manufacturing at scale, you know, design for manufacturing, test jigs, fleet management, OTA, you know, all these other pieces

that come with the scaling part, which somebody else looks after. So I'm super excited about, you know, all these other pieces that come with the scaling part, which somebody else looks after. So I'm super excited about, you know, new hardware that we're working on, which I can't speak to. But the thing that I am really passionate about is tools. And my goal, one of my goals at Particle is to, you know, generally make building embedded systems, not just, um, enjoyable, um, but make embedded engineers and developers, um, proficient and productive. And I think there's a huge opportunity in the space around, around those tools and, uh, bring those to, to particle, um, developers. You mean talking things like static, uh, checking static checking and unit tests? Yeah, the whole development lifecycle from, I'm just writing code, so making it more,

you know, making the act of writing C++ code more efficient with intelligent suggestions and, you know, refactoring all those pieces that are readily available for free in the mobile world are not as accessible to every developer on the embedded side. factoring and all those pieces that are readily available for free in the, you know, maybe mobile world are not as accessible to every developer on the embedded side. But yes, static analysis, profiling, programming and debugging are still clunky in some areas unless you buy really expensive tools. And hopefully find some opportunities to innovate, just like there's been innovation in reducing complexity on the other software world. Cool.

And as part of your job, you recently went to Shenzhen? Yes, Shenzhen and Taiwan, which were juxtapositions in the electronics world. This was your first time? Yep, yep. First time. Spent about half a week in Taiwan and a week in Shenzhen. the electronics world. This was your first time? Yep. Yep. First time spent, uh, spend about a half a week in Taiwan and a week in Shenzhen. Okay. What was it like? For someone who like

loves electronics and getting a new dev kit is exciting. It was amazing. Uh, and the team I was with was just giddy as we went through the stores for the rest of the team who was there, who are more in the back, uh, back office. They just sent, sat around and said, how long, how much longer are we going to look at resistors guys? Did you have, um, Bunny's book to talk to people in Shenzhen with? I did not. And, uh, funny enough, I found his book for sale at one of the stalls. I was half

ready to buy it, but I just, I had locals who were bilingual and they were my virtual bunny. Virtual bunny. Sorry. And so did you, did you come home with a bunch of components for yourself or was it mostly really a work trip? It was mostly a work trip, but I definitely compiled a list of things that I thought I needed or I thought I wanted. And in the beginning of the trip, it was really long. And then towards the end of it, I said, why do I need a earpiece?

That's also a cell phone. Um, so I kept on ripping things off the list that were just nonsensical and a waste of money. Wait a minute. You didn't bring back the earpiece that was a cell phone? I couldn't bring myself to bear to buy it. But it's... Who knows what it does to you? I mean...

There is no form of testing for those products. No form of testing for those products no form of radiation anything the microwave beam straight to your do you have any advice for people who want to become program managers who are maybe engineers or early in their career or college folk so program and product management. Again, we'll use those blurred lines because it truly is depends on where you go. There are great resources now available online for free. When I started, there was literally no books on product management and one print sort of pamphlet that I found. And now there's this great sites. Ken Norton is a great newsletter or has a great newsletter about product management with great articles and resources. And there's

product dot careers, which is slow down a bit, but has a huge, huge list of resources you can go off and dive deeper in. I would say the number one thing I look for when I interview a product manager, especially a junior one is have they built something? If they're an engineer, do they have a GitHub project that they actually own? There's something there about having an idea of a problem and executing on it. It just so happens that you have the skills to write the code to solve that problem. But if you're thinking about product management, that's a good way to sort of exercise those parts of your brain and think about, think about the product. And how do you stay current in the industry or how do you recommend people?

Yeah. Stay current in the technology pieces. So, you know, reading everything you can, I think we talked about that earlier. There's podcasts about product management, which are pretty good,

but really just understanding the industry as a whole. Talk to other product managers, learn about their processes and some of the challenges that they encounter. But like I would answer to that junior in college who's doing software engineering but wants to do product management, build stuff, right?

Become product manager for the thing you want to see in the world. And that's how I constantly hone my skills. Cool. Are you going to Supercon in Pasadena? Yes. Number three, I think. Yes.

And I'm pretty excited. What are you most excited about? Let's see. The first Supercon that was in San Francisco, I had the privilege to speak at, which was nerve-wracking and a lot of fun, but I really didn't enjoy the conference as much as I'd like to

because I was just done with my talk. But the last one was just a bunch of great inspirational talks, things that I am super interested in and things I never even knew I was interested in. And so getting inspired, um,

meeting the speakers and other makers at the event and just coming back with, you know, another dozen projects to work on. Yeah. Yeah. It was, uh,

we aren't going, um, although we do have somebody who will be handing out stickers. So if you find Ben, ask him, Ben Henke, then you can get more embedded stickers if you go to Supercon. But we won't be there because I don't need another dozen projects to work on. I haven't finished the last one I went to Pasadena to talk about. All right. Christopher, do you have anything else

you'd like to ask Jonathan? Well, I wanted to go back. We talked about documentation a bit. And you asked the question about open source projects and how to encourage people to do it. But how do you get... I don't know if you have a great answer for this, but if you come into a place that's already established

and they have a lot of code and they have products, and yet there's just a lot of tech debt and things that are undocumented, how would you suggest trying to build a culture of documentation within a company, not an open-source hobby world? Oh yeah, that's a great question. Working on developer products, I value, as a product manager,

documentation above just about everything. I rather have half the features, but the ones that exist well documented, than more stuff. And so far, I've been right about that from the community. The way I do it is, part of my responsibility is to define the things that

are important for us to work on. So introducing documentation as a feature of our product and putting that on the roadmap and making a culture of defining something as done, meaning it's deployed, available in the firmware, but more importantly, also documented. So if a feature is not documented, it doesn't exist. Okay, hang on, I've got to write this down. And so that's one piece. That's one piece of the equation. I've also found that working directly with engineering,

a lot of developers value documentation as well and would gladly write docs, even if they're not good at communicating, because they themselves find the value of it. So if you give them that opportunity, they're very encouraged to do it. And the only reason why they don't write, you know, comments or documentation is because they just haven't had the bandwidth and runway to spend time on doing it. So saying it's a priority for product, encouraging the engineers and unleashing the value that they see there. And then, you know, if that doesn't work, right, and that's not enough, usually you have to go to customer support.

And you now have a third champion saying the time we spend answering the same thing over and over again equals this much money, right? This is how much we spend on contractors or full-time employees doing customer support. By having a link to the thing that describes this very common problem with proper troubleshooting as well will save us this much money. So that has been enough for me in the past to create that culture. But it may not work everywhere.

I take another approach to the documentation problem, which is, it's fantastic to be right. It's fun to be right. But without good documentation, nobody knows how right you are. And that, depending on who I'm talking to, that path works okay. Because he used the word technical debt. And we have never really talked about that on the show. And I don't think we're going to do a whole show about it now because the sun has come out and we haven't been to the beach in several days. But could you define tech debt? So a loose definition would be all those things that you maybe didn't do right in the interests of expediency

that you need to go back and fix. Or sometimes it's just bugs, bugs that aren't necessarily customer-facing but are hindering your ability to move forward. So if you have a module that's full of spaghetti code, that's technical debt. Something you don't understand how to fix, that's technical debt. You have a system that needs to reboot every day at midnight because it reboots at some point. Yeah, I mean, that'd be an extreme example of something terrible. But it's stuff that's difficult to get buy-in to spend time and resources on because it's not usually customer-facing. It's not easy to argue how this makes things better except from a long-winded sort of,

we'll be able to go faster in the future, we'll be more modular, we'll be able to fix bugs faster, we'll be more efficient, that kind of thing. All right. Jonathan, do you want to add to that or make suggestions on additional ways to prioritize fixing the technical debt? We encourage us by saying, oh, this warning doesn't matter. Yeah, the elevator pitch I have around technical debt is in the culture of move fast and break things. It's all the things you broke. Yes. They're not bugs that you didn't foresee. It's we purposely didn't do this thing, or we did this thing in another way, because we need to ship or because we need to get to market faster. And you said, we'll go fix that later. And there's a to-do in the comments and you never go fix that.

And they just accrue over time. And there are all these small incremental decisions that you made with well-meaning intentions. And it's been a year and you had to hard code the time zone of your server because your your your batch script is just off um and you don't have time to fix it like it's those kind of things uh and in big companies whole products can be technical debt um and i've certainly seen that and uh the the culture that squashes it early or adds to the sort of bandwidth and your planning to fix out technical debt bugs or handle low hanging fruits regularly is one that doesn't have a lot of these big products that are actually themselves technical debt. You have to chip away at it early and often.

I agree. All right. Well, Jonathan, do you have any thoughts you'd like to leave us with before we wander off? building products for customers. And that's approach the problem with empathy. And, you know, empathy for users, empathy for your colleagues, and that's how you build the best products. I think that's a great sentiment. Our guest has been Jonathan Berry, maker, author, and senior product manager at Particle. Thank you for being with us, Jonathan.

Thank you very much for having me. Thank you to Christopher for producing and co-hosting. And of course, thank you for listening. Our quote this week is a little long, hope you don't mind. It's from a book called Algorithms to Live By, The Computer Science of Human Decisions. Seemingly innocuous language like, oh, I'm flexible, or what do you want to do tonight, has a dark computational underbelly that should make you think twice. It has the veneer of kindness about it, but it does two deeply alarming things. First, it passes the cognitive buck. Here's a problem. You handle it. Second, by not stating your preference, it invites the others to simulate or imagine them. And as we've seen, the simulation of minds of others

is one of the biggest computational challenges a mind or machine can ever face. So, tell your co-workers where you want to eat. What if I don't care? Then make a... I don't care. to eat. What if I don't care? Then make a... I don't care. That is never true. I don't care. That's never true.

No. Just say three things. Whichever three things that you don't care about, that's fine. Just choose something. Don't care, don't care, and don't care. Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of Logical Elegance, an embedded software consulting company in California. If there are advertisements in the show, we did not put them there and do not receive money from them.

At this time, our sponsors are Logical Elegance and listeners like you.