The Embedded Frontier

#011 - Mastering Embedded Systems: Lessons from 'The Embedded Project Cookbook' with John Taylor

• Jacob Beningo • Episode 11

Share episode

Summary

In this conversation, Jacob Beningo interviews John Taylor about his extensive experience in embedded systems and his new book, 'The Embedded Project Cookbook.' They discuss the inspiration behind the book, its target audience, and key themes such as the importance of building and testing software before hardware. John shares insights on challenges in requirements gathering, the use of a reference design, and the transition from C to C++ in embedded projects. They also explore future trends in the industry, particularly the impact of AI, and conclude with key takeaways from the book.

Takeaways

  • John Taylor has over 30 years of experience in embedded systems.
  • The Embedded Project Cookbook was inspired by the need for better documentation and processes.
  • The primary audience for the book includes software architects and tech leads.
  • Building and testing software before hardware can save time and improve code quality.
  • Requirements gathering is a critical yet challenging aspect of embedded systems development.
  • The GM 6000 digital heat controller serves as a relatable reference design in the book.
  • Source code and frameworks provided in the book can help developers bootstrap their projects.
  • C++ offers advantages in type safety and encapsulation for embedded systems.
  • AI is becoming part of embedded workflows, but its understanding of embedded systems is still limited.
  • Quality in projects requires planning and discipline beyond just writing code.

Keywords

Embedded Systems, Embedded Project Cookbook, Software Development, Requirements Gathering, C++, AI in Embedded Systems, Software Architecture, Project Management, Hardware Development, John Taylor

Jacob Beningo (00:01.883)

Alright, well hello John, how is everything going today?


John Taylor (00:04.822)

It's going good. Keeping busy.


Jacob Beningo (00:07.639)

Excellent, excellent. Very, very good to hear. It's been a little while since we chatted last, and I'm really looking forward to talking to you about embed systems today. And I know you've got a new book, the Embedded Project Cookbook, which we're going to be talking a little bit about. But before we dive in all of that, one of the first questions just for listeners to kind of get an idea of your background and stuff in about 60 seconds or so, can you tell us a little bit about your background and about yourself?


John Taylor (00:18.775)

Mm-hmm.


John Taylor (00:32.75)

so I've been doing this for been doing embedded work for way too long, over 30 years. I got interested in embedded work when I was co-op being with my undergrad and ended up, working for train and doing lab automation. And that I found it's really cool to do something over here, here, relay click and a light turns on sort of dates how long ago that was.


And so I'm a computer science major by background, but I've been doing embedded stuff my whole career. I've worked in a bunch of different industries, HVAC, telecom, industrial automation, medical. I'm working for AMD right now. So broad spectrum work for several service companies and you get to do all sorts of things in those companies. So I enjoy what I do.


I do it on my spare time, hence the books. So I'm sort of a nerd.


Jacob Beningo (01:36.899)

Excellent. It's always good when you have a passion for what you're doing, right? Even whether you're on the job or off, it's your hobby, it's your job, it's a way of life to some degree, right? So, excellent. So, well, thank you for giving us that background. As I kind of mentioned a little bit earlier to everybody, we're going to be talking about the Embedded Project Cookbook. And one of the things that kind of came to mind, having written a couple of books myself and...


John Taylor (01:47.948)

Yep.


Jacob Beningo (02:05.153)

knowing all the money that's in it, Or lack thereof. What inspired you to write the embedded project cookbook? Right. It takes a lot of time to write these and, you know, lots of they know it, lots of knowledge, lots of time. Was there a specific moment when you realized that this book needed to exist as well? So.


John Taylor (02:06.742)

Yeah. Yes.


John Taylor (02:13.602)

It does.


John Taylor (02:22.254)

yeah, and it was just sort of by accident. so I have a previous book, which I know you're aware of cause you were the tech review for that. so a couple of years, I don't know how many exactly, probably two, three years after it was published, publisher came back and said, Hey, do you want to do a second edition? And I'm like, well, sort of the nature of the book. mean, it's not really one of those that goes out of date real quick. Cause it's not talking about bleeding edge tools or anything.


But that got me thinking and I just recently Ramped up a new with with a new company and was ramping up their development processes and stuff and I was like man I've done this so many times I am tired of doing it from scratch and you can't bring your previous work to your new work So it all had to be clean room done again. So I said, know what? If the publisher will do it, but even if they don't I'm gonna do a


I'm going to write the book. I'm going to do a full project, fully really good example documentations from requirements to software development plans, et cetera. So I never have to do it again. I'll just literally, you know, plagiarize myself, copy paste reuse. And that was the start of the book.


Jacob Beningo (03:41.411)

Excellent. Very cool. And having worked on so many projects, as you mentioned, you really discover going from one project to the next, there really is a lot of doing the same things just over and over again.


John Taylor (03:49.728)

Yes. Yes. I mean, they're all different, but two thirds of it is the same stuff, just maybe different colors.


Jacob Beningo (04:00.099)

Yep, exactly. So, so kind of having put this book together, who do you think the the who do you think but who was the ideal audience for your book? it?


John Taylor (04:10.03)

I mean, at the, I mean, the primary audience is a software architecture or the tech leads, right? Cause they're the guys on the ground that care about this stuff and are doing the work. But at the same time, as we were going through it, my brother's my co-author. When we were doing it, it's like, it, even if you're not one of those, if you're just a developer,


And the book is such, don't have to, it's not a front to cover. You read particular chapters here and there, and you know, just for developers, it gives them more of the why, when they're asked to do things. And it sort of puts it into context for when, why is, why is, why are they always asking me for this and for that? Why don't, you know, what's the point? And so, and it exposes to them, especially if they come from their EE turn software guy, which is


pretty common in our space, right? To processes and things. And so it gives them that background. Also talking with managers, it gives them tangible things that they can use when they go champion. What I've coined in the book is, do it right the first time. There's a famous quote, well, not necessarily famous, but there's quote, there's never time to do it right the first time, but there's always time to do it over.


Jacob Beningo (05:28.924)

you


Jacob Beningo (05:37.919)

Yeah. I recently discussed that when I'm linked in to kind of poke everybody. It's like, why do we always have time later to go back and do it when we couldn't do it right the first time? You're absolutely right. So and I hear that for so many teams. But excellent. Very cool. Now, kind of looking at looking through, you know, looking through your book and having having had the opportunity to read through it. You know, I did notice, you know, something


One, first of all, really does, to me, speaks a lot to just great processes and great material. It's a book after my own heart, essentially. lot of the stuff that you have in there, I'm like, yes, yes, good, fantastic. And one of those things that you mentioned or you advocate for, think, in the book is build and test software first and add hardware second. Can you elaborate a little bit on that and why it's so crucial?


John Taylor (06:24.046)

Yep.


John Taylor (06:28.654)

Um, that's been sort of an ongoing theme in my career for almost over 20 years. Um, and it literally started when I was on a project, I was a contractor. if I wasn't working, I didn't get paid. And the hardware guy took eight months to pick a microprocessor. So I had to do something, right? I had to, not only did I need to make money, but the prog, the project had to progress.


And so, and then that has, that was the original start, but it has evolved over time. And it's, it's, it's where I've got to where I've refined it more and more. There's real, I mean, a microprocessor is, it's just a tool, right? A UART's a UART. An I squared C bus is an I squared C bus, right? There's nothing magical important. I mean, yes, those are core things and you have to have them, right? But whether it's.


NXP, ST, microchip. I mean, they're all slightly different, but they accomplish the same thing. What's the value add is that application that's built on top. What is it that you're doing with the hardware? It's not that, and that kind of thing. So by getting off the hardware as quick as possible, you can actually, and then do it in a way where you can write production code, test production code without the hardware is this huge advantage.


because everybody wants the project yesterday, right? Timelines rarely, other than the fact that they're late and they have to, I mean, you're always asked to move the project left. And so if you focus on what the app is instead of the bits and the registers, it lets you do that. I just find it incredibly helpful. And it makes you think, I think you get better code because you're not...


You're not thinking in terms of a specific microcontroller. You're thinking in terms of what it is I have to do. What are the edge cases? How can I test the edge cases without hardware? Anyway, this was a big theme in my first book. It's a theme in this book. I've seen your blogs. I've seen your books. There's a lot of overlap. We're very much in agreement. I mean, we may differ on some details, but I just...


Jacob Beningo (08:47.431)

Yeah.


it


John Taylor (08:55.266)

The software, I mean, the hardware guys don't like it because it takes away some of their importance. But the reality is the software is where the value add comes these days. Hardware is getting more and more commoditized.


Jacob Beningo (08:58.894)

Yeah.


Jacob Beningo (09:08.197)

Yep, absolutely. It absolutely is. And I totally agree with you, as you know, because I have very similar types of beliefs. so every time I read your material, I'm like, yes. You think very similarly to the way that I do. We each have our own little spins and stuff like that. But from my side, it makes me happy to see other people having the same types of thoughts and finding the value in how some of these things work. And definitely, think...


John Taylor (09:28.472)

Mm-hmm.


Jacob Beningo (09:36.165)

just to kind of share. think it's always funny that if you don't separate the software from the hardware, it's funny how the software folks always get blamed for being late. You imagine you wait eight months for hardware. It doesn't seem to matter that we get the hardware eight months later. It just matters that we're the ones who are doing our software last.


John Taylor (09:53.4)

Right, because we're last in the food chain. Well, the testers are actually last last, but yeah. Yes, right. Management doesn't understand the caveats or they don't emotionally register.


Jacob Beningo (09:59.227)

Yeah. But then they point their finger back at us and say, well, we're on these guys. And for some reason, we're in the middle, right?


Jacob Beningo (10:12.199)

Yep. Exactly. So now one of the things that I thought was really cool about this book and cause I know I personally get a lot of questions about this and I've always, um, it's not the funnest or most interesting topic to a lot of software developers, but it's super critical for anything that we do. Um, and that's the book does a good job of covering requirements gathering. And so I wanted to ask you really quick, what do you think some of the biggest challenges developers face in actually writing good?


tests are good requirements for embedded systems.


John Taylor (10:44.686)

that's a broad topic, right? and if you've ever worked with, I think I write good requirements, but then I get with a system engineer and he just tears my requirements apart because they get, I mean, that's their world. They've got to be specific and testable and et cetera, et cetera. I'm just like trying to capture what they want me to do and do it in a way that isn't defining a solution, just.


Jacob Beningo (10:49.223)

It is, yep.


Jacob Beningo (10:58.407)

You


John Taylor (11:13.474)

describing an outcome. And the reality is, at least in Mars space, nobody gives us requirements. So when I worked in a carrier, we were doing a new generation of rooftops and chiller controls. And they were like 15 years out of date. And the marketing guys came in and said, here are your requirements. We want a control algorithm to control temperature to plus or minus 1 degree.


And the staff that we had is we're software guys, we're not controls engineers. And so we're, we're always like, we don't have requirements and the marketing guys go, we gave you the requirements. Right. So one person's requirements is not the other person. there's this gap and you've, you've got to be able to close that gap. And I spent years whining about that gap.


Jacob Beningo (12:09.797)

Yeah.


John Taylor (12:10.102)

and being frustrated by the gap. it's finally like, that gets you nowhere. It's like, if there's a gap and nobody stepping up to fill it, the software guys have to step in and fill it. And so a lot of those, there's two chapters on requirements, right? A lot of that is just my battle scars from trying to get requirements, right? And trying to emphasize, tracing requirements wasn't that big of a deal for me until


I did some medical stuff and it highlighted, I mean, we had done some before in previous industries, but not like the medical field, right? It's more regulated. But there's a lot of value to it. And it's important. mean, even if you don't do trace, just having identifiers for requirements that don't change. It seems like what's the big deal? Well, it happens. I worked at one place where we had


Jacob Beningo (12:47.655)

Yo, yeah.


Jacob Beningo (13:00.615)

Yeah.


John Taylor (13:07.64)

what I call the story form of requirements, which is a technical spec. It's in paragraph form. And so this one developer was he was going through, he would have a hard copy. And when he implemented something, he'd go highlight off the sentences inside a paragraph of what he thought he did. And then he would say victory when everything in that paragraph was completely highlighted. And it's like, okay, that may have worked for you, but


That's your inter, you know, it's for someone to come test it, you know, are they going to take away the same set of stuff? And so it was anyway, so a lot of software developers don't like requirements. want to be given requirements. And I get that because I've been there, done that. but the reality is, is you got to go get them and you got to write them down. So there's a single source of truth. It's unbelievable how many projects turn in the back half about, well, you did this.


I go, well, you did that. No, you didn't. And it's everybody has a different definition because they didn't write down the requirements. They're just an email or a discussion in the meeting. And there is no canonicals or no source of truth. Anyway, so I can get on my soapbox.


Jacob Beningo (14:19.932)

Yeah.


Jacob Beningo (14:23.557)

Yep. Exactly. And the few that you do have end up changing over time, right, throughout the project. that they change. Yep. Absolutely. So I thought, yeah, I'm glad that you were able to answer that. like I said, in the book, it's fantastic that you covered that. I don't see too many people covering that. It's such an important topic. Now, one of the things I did also notice I thought was


John Taylor (14:30.774)

Yes, which is okay as long as you track that they change.


Jacob Beningo (14:52.903)

was really cool was that you reference, inside of your book, you essentially go through a reference design and your reference design is this GM 6000 digital heat controller. to some degree, I think it's kind of interesting that you chose a heat controller because I've done similar types of things in the past. And so I was like, oh, he chose a heater controller. And I was kind of curious, what kind of spurred your use case, use cases for that?


John Taylor (15:00.579)

Yes.


John Taylor (15:04.387)

Yes.


John Taylor (15:19.69)

I've been in the, I've done what 10, 15 years in HVAC. I've done a lot of thermostats. So it was a domain that was very comfortable. didn't have to, I knew enough of the domain that I could, yes, the projects contrived, some of the requirements are contrived, but they're based on real world things, right? So it was just one less thing I had to learn or invent.


in the context of the book.


Jacob Beningo (15:50.887)

Okay, excellent. I think it's probably pretty relatable to people, right? I mean, a heater controller, it's pretty well, you know, pretty simple, minimal number of requirements. Someone could very easily look at it and go, oh, oh yeah, a heater controller, all I'm doing now, I'm turning heat on, I'm turning it off, I'm doing maybe some Wi-Fi and connectivity and stuff like that. And I love that example, by the way. When I was reading through that, like, oh yes, cool. So I think that was a great example.


John Taylor (15:57.334)

And it was pretty simple. Right.


Jacob Beningo (16:19.781)

You know, I am kind of along the lines of like the heater controller and this book has a lot of material outside, kind of I'll say that goes with the book, right? You kind of provide source code, frameworks, things like that with the book. How do you see those being used by the readers or by developers?


John Taylor (16:39.87)

In a perfect world, they can just take it as is, right? If they take that example project and there's actually a snapshot, a branch in GitHub where you just have the core shell that runs on the simulator, runs on the target, and it's just the framework for the application and it has the console running with the small number of commands, right? But to be honest,


That's a third of your project right there. mean, the reality is, right? And then the software development plan, the architecture, detailed design, those are all flushed out. I was talking to a buddy who did a book review, who did a review of the book for me and he was like, well, do you have template? Do you got those documents as a template? And I go, no, I understand why you're asking, but at the same time, I'm biased, right?


I think they're better than a template because it gives you concrete examples of what you should put here instead of just a text description of, well, describe this or describe that. So in a perfect world, you should be able to take it and run. And I've done that. In my most recent job, we bootstrapped our development team. within a couple of weeks, we had a full process and we had working apps.


now are people going to do that? No. One is, they read a book and are they going to trust me that, you know, they're it's professionally, you're not going to risk until you're comfortable with it. I've seen bits of it work. They're not going to just go and okay. Yeah, I'll trust them. I'll do it and, and whatever. And I realized I can do it really quickly because I eat, drink and sleep this stuff. Right. So I, it's not fair comparison.


Jacob Beningo (18:33.649)

Yep.


John Taylor (18:36.462)

But what I hope is that they'll take it as at a bare minimum ideas or at least get them to think about what's involved besides just coding. And then when I do code, if I plan a little better upfront, I get huge rewards on the backend. So I think realistically what will happen is people will look at it. It will sort of open them up to possibilities.


Jacob Beningo (18:58.224)

Okay.


John Taylor (19:06.318)

and probably cherry pick things here and there that are low risk for them to take on. And that's fine.


Jacob Beningo (19:10.311)

Okay.


Jacob Beningo (19:14.553)

Excellent. Yeah, perfect. Thank you very much. Now, I think at the opportunity to look through some of the stuff that was there in the book and also in the examples and everything. And there is a fair amount of that's in C++. And I know sometimes engineers are hesitant to move from C to C++ in embedded projects, even though there is a very steady transition in the embedded systems industry away from C and I'll say to C++. It's very slow. It's maybe one.


John Taylor (19:31.65)

Mm-hmm.


Jacob Beningo (19:43.289)

know, 1 % of projects per year or something like that. It's not the heavy like it's a, you know, everyone's running for the exit. do you know, what's your take on this debate? And how do feel you address that in the book, if at all?


John Taylor (19:43.424)

Yes.


John Taylor (19:54.582)

Yeah, so I mean, I talk about it a little bit in the book and basically say I'm using C++, but at the same time, none of the stuff in the book or in the concepts presented actually requires C++. That was just a choice. I mean, it's my preferred language for embedded stuff. Now, professionally, it's about 50-50 between C projects and C++. The framework that's in the book, I've done C versions of that more than once.


Jacob Beningo (20:13.584)

Okay.


John Taylor (20:23.79)

So I get that most of the space is in the C camp, which is fine. But my counter argument is, Arduino under the covers, it's C++, dude. So don't tell me it can't run on small microcontrollers. And C++ by nature is not any less efficient at runtime unless you're doing something where you need virtual tables.


Jacob Beningo (20:42.075)

Yeah. Exactly.


John Taylor (20:53.698)

But if you were to do that in C, you're not going to handcraft a Vtable implementation better than the compiler, that kind of thing. So I view C++ as it's safer. It's got better type safety. The encapsulation class is requiring you to have constructors, destructors, things like that. References help.


because you don't always have to check for null pointers because a lot of people forget to check for null pointers. Right? So to me, there's a lot of things. Now, do I use modern C++? No. Part of that is just I learned C++ in the 90s. And there's a lot of the new stuff that I don't feel applicable in the embedded space, so dynamic memory. So most of the standard template library is gone. Exceptions, runtime typing.


Those are usually taken out. And the C++ standard library is large. You pull that whole thing in and you've just code bloated significantly. So I use sort of a subset and it's more of the older just because of my upbringing. there are some things that could be done better with some of the newer features, but that's the thing about C++. You don't have to be C++ 24.


Jacob Beningo (22:22.287)

Yeah.


John Taylor (22:23.17)

You can use the subset that makes sense for you. I I use templates, not very often, because templates can lead to code bloat. But for certain things, they're great. But you look at the modern notation, that template notation is used, in my opinion, used and abused and just, I mean, it's why I like Python. Python is syntactically very simple, other than the goofy indenting rules. I have no complaints.


Jacob Beningo (22:39.559)

Yeah.


Jacob Beningo (22:48.933)

Yeah.


Excellent. Yeah, I appreciate that because I know because there's so many people there and see that's what I want them to get away is, hey, look, even though there's some code in the C C++ in the book, it's actually very good to go check it out. It's helpful, I think, for the reader and for listeners to go and see, hey, look, there's good C++ techniques that you can use. It's actually a great language for embedded and they don't need to be hung up on that kind of thing. Right. They can check that out. So I appreciate you.


John Taylor (23:18.968)

Yep.


Jacob Beningo (23:21.895)

Uh, you know, let us know about that. Um, you know, what kind of mate you're thinking behind it. Cause I think there's a, um, you know, great, a lot of good experience there to, uh, let listeners understand, uh, you know, kind of what, what is helping you make those decisions, um, when you're putting together your frameworks and your code and the book and stuff as well. So, um, all right. So, um, a couple of other things that I was thinking we could, um, we could talk about here very briefly. Um, you know, we've talked a lot about the book. Why don't we talk a little bit about.


you know, kind of the industry and maybe where some future trends are going here. You know, you've mentioned 30 years of experiencing the embedded systems industry. Where do you see things going maybe in the next five to 10 years? Do you see it kind of status quoing or do you see AI really driving into the space and changing things?


John Taylor (24:08.558)

Those are yeah and some of those questions keep me up at night So one is I mean the embedded space and and I'm mostly talking about microcontrollers. Yeah, there's some embedded Linux, right? But to me that starts to gray the space We've never been we're small relatively speaking to the rest of the space, you know other spaces


Jacob Beningo (24:28.582)

with you.


John Taylor (24:36.462)

And so, and things lag behind, right? I see much now CI is becoming part of the embedded workflows. 10 years ago, absolutely not, right? So because of that...


whether it's an upside or downside, whatever AI does to the industry, it will be slower. Now, slower may be relative. Right? it took over this in five months and it took eight months here. So, and so like I use Copilot at work. use, I pay my $10 a month for Microsoft. I use it on my stuff. It's getting better. It's still 50-50.


Jacob Beningo (25:02.331)

Yeah.


John Taylor (25:23.79)

It doesn't really I mean AI doesn't really understand but it's not for lack of better word trained well on embedded stuff Right, but it is a supercharged IntelliSense right now, right? And so At a minimum it's gonna do that Probably ultimately a lot of the boilerplate stuff is gonna go is gonna just be delegated to AI and it will do it


So that's a big, I don't know where it's going to go. One thing that disturbs me is if AI replaces the junior mid-level engineers, what happens when all the senior engineers retire? And there's nobody to check if the AI is hallucinating or not hallucinating, right? So that bothers me. And so I don't know where it's going to go. It's interesting.


I mean, to be honest, I'm getting, I'm old enough to think about retirement. So my hope is at least I won't be displaced out of a job before AI conquers all. So I know these are, it's hard, it just moves so fast. I mean, it's just, it's exponential.


Jacob Beningo (26:26.363)

Okay.


Jacob Beningo (26:33.895)

Gotcha.


Jacob Beningo (26:41.371)

Yeah. it is. as a linear as humans, as linear thinkers, it's very hard to think in exponential terms. So, so I'm yeah, I struggle with trying to figure that out myself. but, you know, it kind of, I guess, kind of go back. You mentioned being close to retirement with embedded systems being your work and your hobby. mean, what would you do if you retired more embedded systems? Right. So.


John Taylor (26:45.312)

Yes, we're linear.


John Taylor (27:09.974)

Right. But as a hot, mean, in theory, have the lecture, the income to retire, so I can do it as a hobby and, and I can be John Henry to the, to the machine and, and I can live in my little bubble and, you know, not have to worry about paying the bills. I don't know. It's, it's interesting time. I don't know where it's going. Um, unfortunately for me, there's way too much hype in the industry. Granted, I work for a company that


Jacob Beningo (27:11.483)

Ha ha ha.


Jacob Beningo (27:37.201)

Yeah.


John Taylor (27:38.732)

makes a lot of cash off of compute. So it's hard to understand what's to distinguish between the hype and the reality. I look at it as really the only AI I use is Copilot because I spend, what, 80 % of my time looking at source code. I'm not, as it stands now, yeah, Skynet's not taking over.


Jacob Beningo (27:40.709)

Yeah


Jacob Beningo (27:54.705)

Okay.


Jacob Beningo (28:00.112)

Okay.


Jacob Beningo (28:07.333)

Yeah. Not yet. All right, excellent. So I've just had a couple more things here that I wanted to ask you before we close out here. I know you will be giving a talk at the Embedded Online Conference coming up in May. And the talk is going to be about decoupling drivers from the hardware platform. Could you give us a little short insight into maybe what you're going to be talking about and going into during that talk?


John Taylor (28:11.309)

Not yet.


John Taylor (28:21.613)

Mm-hmm.


John Taylor (28:32.878)

Yeah, I would like to say I've got that all done and I can give you a summary of it, but that's not true. It's essentially going to be there are several chapters related around doing drivers and different approaches on how you can do it. There's a bunch of different, there's no one way to do anything in software. So there's a bunch of different ways you can do it. The book has three different sort of approaches on how to decouple your drivers. So it's going to be sort of a


Jacob Beningo (28:38.375)

you


John Taylor (29:01.24)

condensed distillation version of that, but also touch on what, why do you want to do it? Right? What, what, what's the bang for the buck?


Jacob Beningo (29:11.975)

All right, excellent, perfect. Yeah, I'll definitely look forward to that. So again, I think it's going to be a fantastic talk to listen in on. the one last thing I wanted to ask you before we close out here, as you can, I guess, kind of answer this how you want, readers, someone who might read the embedded project cookbook, do you have any key takeaway that you're hoping people will take away from the book?


John Taylor (29:37.87)

for this particular book, it's this is all this is in the context of professional projects. If you're a maker or doing hobby stuff, this book is probably maybe some interest, but probably not, you know, something you have must read kind of thing. But if you're doing professional projects, the code is only a small part of it. And there's all this other stuff that has to go in.


making the project successful and quality just doesn't inorganically appear. You have to plan for it and you have to have the discipline to do it. And so hopefully that's what they'll take away from the book is, okay, yes, I need to plan. I need to have some discipline, you know, and yes, I need to build right the code, test it, et cetera. But that's just, that's only a


I would claim less than half of the project.


Jacob Beningo (30:39.975)

All right, perfect. Well, hey, thanks a lot, John. I really appreciate you taking the time to chat with us. And I know the readers really appreciate it. certainly, everyone, check out John's latest book, The Embedded Project Cookbook. And honestly, check out the Patterns in the Machine as well. That's another great one. So you can't go wrong with either one of them. Head them both to your collection, right? And I appreciate it, John. So any last thoughts?


John Taylor (30:44.77)

Okay.


John Taylor (30:56.354)

Thank you.


John Taylor (31:05.014)

Okay. No, thank you for having me on. I've had a good morning so far. It's been fun talking shop. All right. Bye.


Jacob Beningo (31:11.417)

Awesome. Excellent. Me too. So I really appreciate it. We'll have to chat again here soon. So, all right. Thanks.




People on this episode

Head Shot

Jacob Beningo

Host