Embedded - 47: Bridge of Toothpicks

Episode Date: April 16, 2014

Nathan Tuck joined Christopher White (@stoneymonster) and Elecia White to chat about varied topics relating to being an embedded (and graphics) engineer (and manager). Nate works at NVidia on the Tegra K1-64. He mentioned some openings in his team at the end of the podcast, email the show to get a connection. We also noted that Eyefluence is hiring for an EE and/or technician for work somewhere between San Jose, CA and Reno, NV. Direct resumes to Peter Milford using the email you find on their webpage (info @ ...).  We asked if managers are sociopaths. If you haven't seen The Expert tragicomedy sketch (7 perpendicular red lines...), you need to as it is becoming engineering vernacular.

This is Making Embedded Systems, the show for people who love gadgets. I'm quite pleased to have Nathan Tuck and Christopher White on the show today. We're going to talk about something. I'm not sure what, but that'll be fine. It will be a little less focused than usual. Mostly we're going to sit around and chat like we normally do. Maybe a little more formally than usual, but maybe not. All of this is because our scheduled guest didn't quite work out.

He was wonderful, turned up promptly, and spoke into his microphone. That's usually all I require. However, he really couldn't tell us much about his company. I suppose it might amuse you to listen to my insightful questions and him saying he couldn't talk about that or we'd need an NDA to discuss it. But maybe he'll come back later when he can talk about it. And since Nate is our house guest, I figured we could record something with him. I don't really plan on starting dinner until he's come up with at least three interesting things to say. Can anyone say captive guest? So, Nate, welcome

to the show. Thank you, Alicia. And Christopher. Yep. Let's see, you, Nate, went to school with us, and then you went to SGI, and then some neat startups, and now you're at NVIDIA. Yes. Did I miss anything important?

No, I guess I took some time out for grad school somewhere in the middle. But wrote a few papers and took some classes, but didn't actually get any degrees out of that. So that was interesting. That's life. Yeah, that's life. You work in graphics, which has always been interesting to me because we can talk about a lot of things, but not everything. It's different than embedded.

How do you mean that we can talk about some things but not a lot? Well, sometimes we chat about math and algorithms and optimizations. Right. But then, you know, processors are different because you work on bigger processors. Well, they're different architecturally. They're not CPUs. So, I mean, well, sometimes they are, sometimes they aren't. So today I'm actually the manager of a software team within a CPU architecture team in NVIDIA. I have worked on graphics processors in the past at Silicon Graphics,

and certainly a lot of the people I worked with back at Silicon Graphics, funnily enough, are at NVIDIA today, which I guess is the normal Silicon Valley story. They're all doing completely different things than when I first met them. But, you know, the cast of characters changes, the companies change, but, you know, exactly what the cast of characters is doing. And then new people come in and people leave. But I find it's been interesting.

I think everywhere I've worked, there's always been someone who I worked with at one or more companies in the past. I think that says good things about you. It means I remember things that people did 20 years ago that they don't remember. You know that day when you brought that tuna sandwich to a meeting and the rest of us were starving? That sort of thing?

I sometimes scare people with things like that, yes. Are they all working on similar areas that they did 20 years ago? It's the same cast of characters, but people who have slightly changed their focus or their technical roles? I think you see both. There are a lot of people who I see now who were doing very different things in the past. And then I see some people who have clearly been mining the same area for some time.

Your role has changed quite a bit in the last five years. Right, right, yeah. My own personal history has been a little interesting by Silicon Valley standards in that I've, I've been working mostly remotely for Silicon Valley companies since, uh, 1998. And, and that's 98. I thought it was later,

but I guess you guys did bug out of here pretty quickly. Didn't you? Yeah. Yeah. So, so I, I'm probably one of the, well, actually, I mean, there were plenty of telecommuters who I knew back in 96, but that was pretty weird back then because you usually had dial-up or something like that.

128 kilobit ISDN. Yes. Chris, you did a lot of telecommuting back then, but it was for a company that was only 10 miles away. So that was not as difficult as being hundreds of miles away. I remember at Silicon Graphics, there was a guy who lived out on Whidbey Island. And he had, you know, the one thing that people were kind of upset about was he probably had a half million dollars worth of equipment in his house, in his home office. And that was,

uh, I don't know. I guess it was allowed because he was exceptional, but, uh, you know, it kind of made people nervous. Actually,

that's, that's an interesting thing that I've noticed that's changed over, over the last, uh, couple of years is as, as the equipment cost has come down. It seems to me that the industry has been kind of squeezing the cost out of, you know, I mean, some of the startups are now making a big deal about we have two monitors and

so forth. But I think my first job, I had $150,000 worth of equipment in my personal office. And now it feels like the industry is kind of in an environment where if you have $10,000 worth of equipment in your office, it's a bigger deal. I remember being told that if I dropped that logic analyzer, it was worth more than I was. Yeah, Cisco, we had routers and stuff in labs, and I know a lot of the telecommuters had their own labs in their house, and that was a similar thing,

where you'd have several hundred thousand dollars worth of stuff, which now is probably less powerful than an iPhone. But yeah, nobody batted an eye at that. And now it's, oh, you want a laptop with 8 gigs of RAM? Well, we're going to have to go to corporate on that and get you a special exemption. Well, there's also the secrecy part. Jen just, one of her older projects just finally hit the market.

She was very excited. And I said, well, have you had one all this time? Is it neat? And she said, no, I never got to take one home. And she was integral to that project, and she never could take it out of the lab because of the secrecy piece. Right. Well, Apple's notorious for that,

where you can't even talk to your spouse about what you're working on. Yeah. I mean, I think that companies definitely talk a lot less about what they're doing these days, which is interesting because there are fewer and fewer competitors. So I don't know exactly what they're trying to protect. But I definitely feel like it is a less open environment these days than it was in the past. I wonder if we just hear more about the super secret places. Because there are companies

like Bia, where Jen works now, that, I mean, she told all, between the conference presentations she's given in the last two months, I don't know, other than specific code, what she left out. And then Salier, the logic analyzer people, should have a lot of information about their scopes, their brand new scopes. Yeah, but they're about to sell those. Well, yes, but it isn't just the specs they have. I mean, they're giving out the APIs and how to deal with them. Some companies are doing the transparent and open thing.

It depends on if they think they can sell more by being open, I think. But there are still a lot of startups out there, and I know people who work at Stealth Startup. They won't even tell you the name. It's just Stealth Startup. They're really excited to say they're being stealthy and they're not going to tell you anything. And nine times out of ten, those startups come out and it's like,

oh, yeah, we're building another thing that they're, four other companies making it. And it's exactly the same as everybody else's, except we tweaked this one thing and we're going to take over the market. And then they fail. It's just, you know, I think people get off on the secrecy sometimes without there really being a reason for it. Right. I think that startups and then the larger companies,

I think there's a lot more interest in controlling the message that goes out. And I think also the overall group of people that we're selling to. I think when we started in the industry, it felt to me like we were designing computers for us and people like us. We being the three of us. The three of us, yeah. Not your current job, okay. No, no.

I feel like back 20 years ago when we all started, I know that hurts. It hurts me every time. Five years. Five years, yes, yes. But back then, it felt to me like, particularly at Silicon Graphics, the target was very technical people who wanted to use computers to solve hard problems that were science, engineering, math-oriented kinds of problems. And I assume at Cisco, that would be networking. But then you probably were more thinking about the people who were building out infrastructure rather than end users. for the core of the internet. So customers were all the big, big backbone ISPs.

And yeah, you didn't have to talk to anybody who wasn't extremely knowledgeable about what they were buying, which was good and bad because then they could tell you you were full of crap when you were trying to sell them something that wasn't what they wanted. But yeah, it was a different environment.

Well, wait a minute. And I went to HP at that time and worked on networked servers, which were again, huge things. But these were all companies that at the time were big and very focused on getting good college hires. Cisco

now certainly still has that program. SGI doesn't exist and HP has been broken into. SGI still is a server by fries. There's a building over there that says SGI. I'm sure that they do something. But we've gone from working for these huge companies that tapped college graduates to work on their nifty problems

to all going to startups. And I know, Nate, now you're at NVIDIA, which is larger, but it is differently focused. And do they have the new college hiring programs? We definitely do new college hiring. You know, I guess I don't know exactly what college hiring was like when we were college graduates because it was a bit of a mystery to me back then. And now it is a little bit different. So I definitely do see that we are hiring college graduates. I think the general hiring mix changes from year to year and maybe quarter to quarter in terms of, you know, are you looking for experienced people or are you looking for new college graduates? I do feel like the mix has shifted towards people with a master's and PhD. And I feel like...

Given the area you work on, that's not a shock. Well, I wonder whether I'd be able to find a job in the industry today the way I did back then. I remember our own hiring searches, you know, our own searches in college, and it felt pretty easy to compare to what I see right now, where, you know, you may see tens or hundreds of PhD resumes and not necessarily too many of them make it very far. So I felt like, you know, Karen, your guest a few weeks ago, Karen Schell, I remember her going to interviews and people being amazed that she knew about email.

Well, I mean, it depends on what you're doing, too, because it seems to me there's always a role that needs to be filled for extremely junior people. There's always things that need to be done on a project that, you know, a PhD, unless they're completely out of their element, shouldn't be working on. So are you saying that those roles are no longer there? Wait, wait. I want to go back. I think for big companies, it feels to me like that has moved overseas. Oh.

Oh, that's terrifying. What I was actually trying to say was that we all went to big companies, and the reason we all worked on big projects was because we went to big companies, and that consumer is a harder space for new college graduates. And I guess you were saying that there's a lot more consumer and cheaper stuff, and you're also saying it's a harder world for new college graduates. So we may all be on the same page here. I love that resounding agreement there.

Thanks for that. I'm trying to understand what page we're on. Yeah, I mean, I think it's just an accident of where we ended up. I mean, if we'd gone to Microsoft, we would have worked on what are effectively consumer products. But there was, it was a different time in that there were fewer number of high technology companies addressing consumers directly. Because it was too expensive to even expect that. And now some of the bigger companies that weren't back then are now.

You know, Cisco's been trying, Cisco's still an enterprise company, but, you know, they've tried various times to directly sell things to consumers with not much success. And SGI wasn't, and that was perhaps their big mistake, was letting the NVIDIAs and the 3DFXs,

well, back then, and those companies, kind of start undercutting them in ways that they maybe didn't expect correct me if that's a total fallacy no I mean I think that's you know my understanding of the events of the time was that that was fairly you know that's a fairly correct assessment. I mean, it's... And they lost a lot of talent to those places. Yeah. Well, I mean, they had a cash... It's a classic problem in business, right? You have a

big cash cow, high margin business, and then you see in the future that you need to jump across to something that is, or at least looks like it's lower margin. And, uh, it's, it's difficult to, to, to make that jump and most companies can't do it. And, and certainly I, I remember at the time, uh, there were a lot of presentations about what, what margins were in the PC industry. And you would look at that, and you'd look at the business you were doing, and you'd just say, I can't make that work as a business model. And I think the margins that NVIDIA makes today

are actually very similar to the margins that SGI made in its day. But a lot of that has come through very aggressive cost reductions that maybe would have been inconceivable if you were kind of used to doing things in a certain way, which SGI was. Well, as you mentioned, we went to school a while back. In my notes it says 15 plus years, because I wasn't, I'm not ready to face the next reunion. And we did go to college together.

In fact, at least one year we all roomed in the same suite. Yes. And so the question I have is what did we get right and what did we get wrong over in starting our careers? One thing that comes to mind is I don't think I understood what a startup was back then. So getting a job, any job, where somebody was going to pay me regularly was very exciting. Oh, that was so exciting.

And I don't know if it would have been feasible to get a job at a startup back then. I think it was good that we went to the big companies. I feel like HP trained me right. Yeah, and Cisco did a good job. I saw what good management was. And I saw, I mean, they put the new college grads. Then you had a little pool. And you all went through the same stuff.

And you learned stuff. And then you got split out. And then they sent me to management class, even though I really wasn't ready. I liked that part. I felt like going to HP was great for me. That was before it split into Agilent, so it's not the HP you know today.

And Cisco did that for you too. We didn't go to a lot of the joiner parties, but they did exist. You know, the after school specials. We did some of that, but Cisco did a good job, and Cisco did a good job.

And I did end up at a startup four years or so, three and a half years after starting there. I guess it's just, oh, you know, that was the original internet boom and we missed it somehow. Felt like we had a good foundation instead and I wouldn't trade.

And Nate went to a startup. I mean, SGI, it's failed, so it must have been a startup. I don't think SGI was a startup back then. It was definitely more chaotic, I think, than the companies you went to. I feel like throughout my career, I've had very little formal training of any kind through my employer I mean

perhaps my employers would beg to differ I wouldn't say I had any formal training I certainly never went to a management well okay maybe I've had a few days of training in various ways,

but I definitely feel like my approach is pretty self-taught in a lot of ways. And I didn't have strong... I worked with a lot of smart people, but I didn't necessarily have strong mentors. Yeah, Chris, you had a mentor at Cisco. Okay. I mean, definitely. Yeah, Chris, you had a mentor at Cisco. Okay. I mean, definitely. Yeah, I mean, it wasn't formal. And he wasn't the most organized,

but he was super awesome. I mean, he was really smart. I'm not sure who you're referring to, but... The one you followed to Procket. Yeah, that wasn't an official mentor. I mean, that was just a work relationship that was good. You still talk to him. No, I'm not saying...

He's still trying to call you into going to new startups. No, he's not. Almost. What I'm saying, to go back to what Nate said, that wasn't formal. Okay. That was, you know, of course you're going to meet people who you get along with and who you learn things from. But,

you know, I didn't go to any classes that Cisco put on for anything. I'm not even sure I made it for orientation the first day because I'd already been working as an intern. Yeah. And yeah, I think one startup, medical startup,

much later, they threatened to send me to management class, but they never did i certainly worked for people who had management coaches following around that was kind of yeah but i don't think you get to do that until you're older and much feebler than any of us are nate did you summer at sgi uh yeah i was a summer intern before i went summer to sgi we lived together then, too. I know, we did.

Even though you might not have seen me at all. No, I remember you. Because I remember you left your damn alarm on and went off for a week's vacation. I don't think that was vacation. Oh, right. I think I was in Japan or something like that. So, we all went, we all got summer internships, and then we all went straight to those companies.

And Chris and I never stopped working for them. We did the summer thing. No, I did some work over the semester, too. And then over the semester we continued work. And I did as well. I did, too. Yeah. Because it pays so much better than work-study.

Well, and I hadn't finished. Yeah, yeah. Turns out when you write software, it always has bugs, and they expect you to continue to support it. And this is why we quit. That's the main reason to quit. Stop supporting your old terrible code and start writing some new terrible code elsewhere. A major reason in me leaving my last company,

which was AMD, was that my inbox filled up. My inbox has been flirting with 404 unread messages. I just like that. I'm never going to read them anymore. Inbox 404. Yes. Yes, yeah. No, I find that is a huge problem for me, though, is that I go places and, you know, you start off

and you come into an organization and, you know, yeah, they have some idea of what you can do and and you know you go and you learn everything about what's going on and and you have all this free time to kind of work on that set of problems and then you become the expert there and then but then you also kind of expand yourself and expand yourself and at some point uh you know at some point you kind of i frequently find that i end up with too much on my plate And I'm really bad at giving things away And so that's

I don't know if you two have had that problem or not I've seen that problem I give things away very easily I'm just like, look, here's a neat problem You should totally paint my fence Right I'm very good, look, here's a neat problem. You should totally paint my fence. I'm very good at tossing work over.

I think I'm lazier than you, Nate. So as soon as somebody else is willing, I mean, if I don't feel like my job is threatened, if I give everything away and they're going to fire me, but if somebody wants to take something on that's sort of mature and I don't want to think about it anymore, I'm pretty happy to give it away. Oh yeah.

I mean, I'm happy with, I'm happy, I'm happy to give away things that I'm not interested in, but I do find that the number of things I'm interested in grows, uh, rapidly. And then there's usually some kind of responsibilities that come along with

that, that, that are, are maybe, you know, that's the usual thing, right? Most, And then there's usually some kind of responsibilities that come along with that. That's the usual thing, right? Most work is actually work rather than thinking about cool problems all day. And kind of early on, there's a lot more of thinking about cool problems. And then later on, there's a lot more, you know you already thought about it rearranging the cool problems and maintenance just isn't as much fun even if it was a neat problem to do trying to figure out all the areas where you messed up it's

just yeah yeah yeah that that's been interesting uh because I've been working on the same project for quite some time now quite some time and you know we definitely had a pretty big cast of people who

in normal Silicon Valley style we had a cast of people who were at know, in normal Silicon Valley style, we had a cast of people who were at the project for various points before the end, and who probably thought they left with their part in great, quote, great shape. And they were all wrong. They were all wrong and you junked their code, or they were all wrong. They were all wrong and you junked their code or they were just wrong? Well, I mean, I think, you know, I would say that a lot of the lessons that we have learned at the end, I think you wouldn't have, if you had left any time earlier, you would have had a different set of assumptions. And that's... Is that because something changed after they left

or people weren't adequately measuring? You know, there were no metrics then to say, well, this isn't as good as you think it is? Well, I mean, I wouldn't say they were wrong in major ways, but it has been interesting to see. And you guys have productized things in the past as well, so I'm sure you're used to seeing this. But you design something, you think that certain things, you have certain things you think are important,

there are certain things you don't really know, uh, where in the design space you need to be, but you have some general ideas and, you know, you have some idea of what the relative ordering of importance is. And then, and then you might think, well, you know, when, when we engage with the real world, here's what, here's where the set of problems are going to be. And's the extra work we're going to need to do to fix that. It's just been interesting to get into the homestretch and to see what's really been the set of issues.

I think it's been a very different set of issues than I thought would be the big problems earlier. Well, that last 10% of getting things done is always so painful. It's gotten to the point where now when I reach feature complete, I start feeling like, oh, now I'm 25% finished with this project. There's so much that comes after that. And yeah, there's been a couple of times where I've wanted to leave after feature complete and have been glad because you do learn so much more after that. And it wasn't what you expected.

All the planning in the world can't always tell you where it's going to break down. There's a trap there too sometimes. On a couple of products I've worked on, they've, like you said, you don't quite know where you are in hitting the requirements or the market or where your design should be. And the solution they chose was, well, we'll just design this thing so that it can do this huge wide range of things, only one of which will probably end up being the final solution, but we'll spend an extra, I don't know, an extra 10% per unit

or millions of dollars of NRE developing some general solution that can later, we'll figure out later where we want this tuning parameter to be. But then you figure it out and you've got all this extra hardware that basically never gets used because it sits in one position or something. And I think that's kind of a worse place almost than choosing the wrong answer because, well, I don't know. You can end up failing because you can't make any money because you tried to be too general.

Right. You have to have some flexibility, but you can't over-design such that you completely miss the market. Chopping vegetables with a Swiss Army knife is pretty stupid. Sometimes Swiss Army knife is not what you want. Right, right. Yeah, that's a good metaphor. Of course.

You said you've been doing this for a while. How long have you been at this job and is it the longest you've ever been at NVIDIA job? It's definitely the longest. I guess it's five years now we started in, or I started in 2009. I only made four and a half at ShotSpotter. What's your longest, Chris? Ease. What was your longest, Chris? Ease.

What was one of the laser companies? Well, Cisco was, if you count internship, it was probably four, four-ish. Laser company. Or did they just seem really long? Yeah, three or four has been my longest. I don't know exactly which one, but most of them have been two or three.

Yeah. I'm usually... Not all of them my fault. 20 months and I start to get bored. That's pretty short. 36 months and I'm looking for a new job for sure. Shots Butter, I lasted longer because it was such an amazing product.

Well, if there's new things coming up that are interesting to get involved with, that's great. If it's, we made this product and now we're going to support it for the rest of our lives. Or if, you know, one company was like,

okay, we're still not selling anything. Why don't you make a fifth revision of this internally? You know, that gets really irritating. So, you know, if you don't ever make a fifth revision of this internally? That gets really irritating. If you don't ever see any payoff, and I'm not talking about financial payoff. I'm talking about seeing your stuff hit the market. Then that can be really depressing too. Not just getting bored with something that's done. I left LeapFrog.

I had worked on my toy line and then they canceled every single thing in my toy line. And I was so depressed. I wasn't going to wait the next three months to get a new toy line. It was just so annoying

to have my work be tossed. Despite everything that I loved about LeapFrog, it just wasn't enough. I think there are two, well, you see it both ways sometimes, right? So I've certainly seen companies where they run projects to the very, very end, and then they cancel them. Yes.

Or they do a bake-off internally. Right. Either you're competing against your own product, cancel them. Yes. Or they do a bake-off. You know, right. Either you're competing against your own product, some other product within your company, or they're hoping against hope that they're going to hit some market and they work people to the very end and then they realize that they just missed it and they cancel everything. And then the other – and then they realize that they just missed it and they cancel everything

and then the other and engineers hate that and then the other way to do it is to change early as soon as you think that you're going in the wrong direction pivoting yeah

pivoting you pivot before you sunset sure what? Pivoting. You pivot before you sunset. Sure. But that also tends to really annoy engineers, I think, and managers and everybody, in that they feel like they're getting jerked around, and why didn't people see where this was going in the first place? Or when you go back and forth.

Yes, yes. We're headed here. Oh, wait, no, we're going to go there. Oh, back to the first place. And you're like. Yeah, and that happens. That happens a lot. Well, that's often when, again, when management or whoever's in charge

doesn't really understand what they're trying to build or what the market really looks like. Sunset. You've never heard sunset? That's the weasel speak for I'm shutting this project down. Oh, I didn't. Yeah, okay. I guess I have said. Oh, I'm going to check my email again now that I realize that. Are you being sunsetted? No. Your role in NVIDIA has changed over the last five years. Yeah, I started out as an individual contributor. Writing code and doing design.

Yes, yes. And you know, so I started out writing code and at some point my manager left to take another job and I was put into his position.

Did he giggle as he was walking out the door? I just want to know. I've seen how hard you work, so I suspect that there's he might have left with great glee. It's interesting. Do you feel like you were tricked? Or was he taken away in a straitjacket? It's interesting.

I don't know that he had quite the same approach to the job that I do. He left me in a pretty good place with a good team. But, you know, I was less successful than I wanted to be in giving away some of the technical responsibilities that I had. And I had more trouble than I thought kind of keeping myself out of those kinds of things. So I think I ended up turning it into a couple jobs for myself. And maybe if I'd known anything about management and full-time jobs for yourself, it's been close.

Sometimes it's, it's been very close. Yeah. It's supposed to moonlight at different companies. Let's get two salaries. Give him another social security number. You guys do make fun of me for my hourly wage. And I think that's very

fair. And your team has grown a lot since the old manager left. How many people are you managing now? You don't have to give me a... Feel free to give me a round number here. It's oscillated, but

in round numbers, I've managed between low 10s and low 20s. That's a lot for one person. It's a lot for a first job as a manager, I'd say. And I do have some, well, and to have some technical input and responsibilities as well. You know, there's a lot of different jobs that you have or can have as a manager, right? There's sort of the people management, there's the project management,

and then there's technical direction. And my particular role, I think all three are kind of expected of me. And I definitely interact with people who, within the company, we sort of have a matrix management structure. And so there are people who only actually have one of those kinds of roles. And I think I'm kind of disappointing to some of those people because I don't do what they want done because I'm just constantly triaging my own time in some way that makes sense to me.

Well, I mean, your management must be happy. You could be apparently split into three separate people and I hope you ask I'm three people at least give me two I mean that would be fair maybe halfway I don't know.

And you do all this, again, totally remotely. Even the people management, you only come into Silicon Valley every couple months. Right, right. So my team is spread across the U.S., so it's mostly, you know, the time zone part of it is manageable. You know, we do interact with international get up at, you know, you can meet with people at 7 or 8 in the morning on East Coast and then talk with people on California time as well. You might stay up and talk with people in China.

Yep, yep, yep. People in China and India come generally at the end of the day or the very, very beginning, depending. What tools do you use? This is a stupid question, but what tools do you use to communicate within a company? I have some clients in San Francisco, and we do Google Hangouts for meetings,

and that sometimes works pretty well. There's a lot of IAM. A lot of IAM, which I'm not sure I really like because it feels like they can always interrupt you and it does feel like the bandwidth is extremely low and yet i always have these very deep technical conversations with people that probably would have taken five minutes over the phone but take like a half an hour over iam so what do you what do you do since you have to talk to so many people um well for for one-on-ones, it's generally the phone.

And that's, I guess that's a personal choice, but I'm not a, I guess, I mean, we could use video conferencing, but we just, I just haven't really gotten that going. That would require you to get out of your jammies, you know. Right, right. Well, I mean, there's that aspect, but then there's also, well, the video conferencing, generally the video is not very high quality and the audio is not very high quality. And I find that in a one-on-one,

I want to hear the person's voice and understand not, not just the words they said, but, but, uh, you know, see if I can understand, you know,

the emotional side of it and what, what they're kind of trying to get at when they did that. And I guess I've just been sort of uncertain as to whether I would get that with the current video conferencing solutions. I know they've gotten a lot better and I should probably give them a try. But I always feel like with, well, I have had some Skype conversations with some people and they've been fine. But generally, there's always some kind of issue that you don't have with the phone. And so it's just been easier for me to use the phone for those kinds of talks. I get pretty frustrated when you're about to have an intense talk with someone and it turns

out that the tools are getting in the way, totally getting in the way. Right. Yeah. I mean, internally, like if I go into the office, then I can have video conferences with people that are high quality and you can see see and talk with them but then it's usually that you have you know some number of people in each of the different sites and you know

it's the high quality video conferencing and you can just you know it's not so much of a one on one thing there many to many kind of right and the many to many I think it's less important to really see some of the details or hear some of the details.

What other tools? I do use instant messaging. I agree with Chris that it can be quite interruptive. But I don't know. It seems like for short things, there's some value. And I think some people are more, they feel like it's better than picking up the phone. It's certainly. For me, for sure.

Yeah. It breaks my flow less. And you were saying that there was, it could take a half an hour to solve something that would have been taken over the phone, except now I have a record of it. Especially if it's like steps for reproducing a bug. Over IM, it's so much easier.

Isn't that just laziness, though? I mean, you can take notes. I do take notes, but when I take notes, they're from my perspective. On IM, both people kind of agree to the notes. No, and I use IM all the time. I just have mixed feelings about it. I would rather be interrupted to save somebody ten minutes if it's a five-second question.

And you've got such a big team that being able to solve small problems often before they can snowball into larger ones probably is really useful. Well, yeah. I think IAM's good. I think I've gotten better with it in that I've learned that sometimes I can ignore it for a little while. Yeah, me too. I think when I first started using IAM, I felt like, well, if someone IAMed me and I was really there, I should answer immediately. And I think I've gotten better now at, you know, does this look like something I could put off a little bit longer? Do you use IRC or group chat or any of the multi-person IMs?

Yeah, there is some of that that we do as well. Yeah, I use IRC. There's some internal IRC. What's the public channel? Oh. Yeah, right. That's a thing that... I think officially most big companies are fairly restrictive about security.

And so I don't know... I guess you could use Skype or you could use some of these Google Hangouts or whatever, but I don't know exactly how corporate security feels about that. And it's one of those things where I'd probably have to go ask someone. And if I went and asked them, I'd probably never get an answer. So probably if I asked about whether I was allowed to use my phone, I would never get an answer. Probably if I asked about whether I was allowed to use my phone,

I'd have a hard time getting a response on that either. I feel like that kind of sets the space. The corporation has a standard set of, here's what we tend to use. We use WebEx or we use whatever. We have this conference calling system. And I tend to use that rather than going out to try to find my own solution. Yeah, they paid a lot of money for that. Oh yeah, if it's a big company, might as well.

Right, right. Well, I mean, I guess over time I feel like I've become less DIY in the IT space of my job. I heard a great little phrase about open source and DIY. How it's, there's the free as in beer and the free as in freedom. But a lot of the open source is free as in free puppy. It's a heck of a lot of work and you're going to regret it. Right. The more classic one is that it's free if your time is free.

Yeah. Have you ever had problems with remote workers and how do you solve them? With people who work from home and them finding their day is broken up so much they don't get anything done. I definitely find that some people can cope with working from home better than other people. And certainly there are, you know, just thinking back on my own time telecommuting, there were some jobs where I was, you know, very, very effective and other jobs where I was less effective. Was it more about the job or more about your home life?

That's an interesting question. I think for me, it's probably mostly been the job and then the people that I've been working with. I think, I mean, there is some, there's a couple of things, you know, if you're working remotely, you have to be pretty, uh, proactive about getting information from other people and you have to be more noisy than you would be if you were in the office and you all just, you know, happen to stand around so-and-so's cube and listen to what was going on. But then also your coworkers have to work with you and realize that they need to include you on things.

Well, that's where I think I am kind of takes the place of popping your head over the cube wall. Right. When I had remote workers, if I could pair them with people in the office, of course, I was in the office, so that helped, and make sure that people kind of had buddies so they didn't fail to get the critical information

that was passed along with the water cooler. And that worked out pretty well. But I only learned that because when I started that job, I had a buddy and he was remote and he was the one teaching me everything he knew about my job so that he could go back to doing his job. And then I realized that my role for him was making sure that he didn't get stuck out there. He was in Ohio and I was in California and he needed that water cooler talk. Right, right. You had some questions that you brought for us to talk about.

Is there anything here you, it's quite the list. This is like six podcasts worth of questions. I've got nowhere to be. Well, that's one of us. Let's see. There was this one. Lock free but racy.

Lock free and racy but correct code that clearly is a pass on that question let's just pass well there was this one management for psychopaths and the clueless or boon to humanity that was kind of a great question

I'm totally going to use that on somebody else, too. I don't know if you ever read the link that I included there, which was fairly lengthy. The Gervais Principle, or the Office According to the Office. Yes. Yeah, that will be the link notes. Yeah, that was... I found that to be an interesting set of essays.

What would I say? I don't know if there's anything I can safely say and keep my job. Unless you want to have a discussion. I know that, so Alicia, I know you and I... Differed? Well, I don't know. We have some different thoughts about management and the role. It's been interesting for me moving into a management role because I think when I came out of college,

and even today I would say that I don't really view myself primarily as a manager. I generally look at myself as someone who comes in to a project to get something done. And I see that there is a trap that a lot of people fall into in that they think of themselves as, well, at least I see it as a trap. And they see themselves as managers first and people who get things done later. And so then there's a lot of, well, there's a lot of useless activity, I think, that happens in some places. He's calling schedules useless activities. You don't know because you weren't here part of this, but Nate and I have had part of this conversation.

Yes. And we were talking about project management, and you separated it out nicely. There was people, project, and technical direction as three separate functions of a manager. And I know that you do a lot of the people management because one of the reasons you come to the area is to do reviews. And that always seems really hard.

And having done them, they are really hard. And technical direction seems like the fun one, especially for the three of us. Project management, I liked project management. I don't like Microsoft Project itself just because I seldom use it. But what tasks need to be done and how long will they take and where's the bottlenecks and how do I fix those and where do I need more people? And just assuming people are cogs and just moving things around. I do like that, but I remember you and I talking about how you were being asked to produce a schedule, and you're like, that's dumb.

Well, it's, how would I put it? I think you said, that's dumb. Yeah. It was late. I think it depends what you do and what it is that your team does and how predictable that is. Well, it depends on the project as well. I mean, there are certain things that are more tractable than...

I mean, if you have something that's around a year long and you're piecing together hardware to make some thing, that's different than we're making a system that's never been done before and we're going to take three or four or five years to do it. Maybe I'm misrepresenting what you're thinking, but...

I think you have to have... I mean, you do have to have a schedule that you want to hit. And you do have to have everybody understand how they fit into that. have to have a schedule that you want to hit and and you do have to have everybody understand how they fit into that date or list of activities well in in our business it's it's usually a it's usually given us a date but it's usually actually well in at the do I put it? The products usually come out at a date because there is some galvanizing event.

There's Christmas or there's back to school or there's whatever. So there's some consumer-driven date or this time of year there's people getting their tax returns back or whatever. and target changes their floors twice a year and if you don't make that time you don't get it into target right so so the the person who ultimately retails your product has some schedule that's tied to a date um and and so you you have to have some product that fits into that. But then also in our industry, there is the dates by which certain technologies arrive. fab process available and you can yield well enough that you can actually sell a product for a decent price on that new thing and beat all your competition.

When you can stop getting samples and start getting production units. Right, right. So those kinds of things tend to drive the further back parts of the engineering schedule rather than the operational schedule. And again, it's good to have

an idea of where those are and when you're going to be done. But those are bold. I'm totally on board with what the end date is that is given to you by marketing and what's the date of your vendors actually providing the hardware they've promised those are can be completely flexible and i and then there's the date that you know oh we need to have it from may 1. So we're going to tell engineering we need it by March 1st, and then they're going to slip.

All right, that's fine. But I don't— They get it August 1st. Yeah. But I do think that with most projects, there's a pattern to them. Like for consumer projects, and I pulled up on my book because it's in here and I remember that, you know, there's the phase where there's requirements gathering and then system design, component selection, then you build a prototype and then

you refine what you're doing and then you do schematic capture and review and kitting components. And there's all these things you do. And software comes in here where the prototype's done, but software can't be done until the final hardware's in, and then there's some manufacturing pieces. And so I think you can almost do a schedule without having any dates. And for consumer products, sometimes, I mean, if you think you're going to be doing manufacturing in less than four weeks, you're out of your mind unless you're building something that is silly.

Right. I mean, you do need to know how long approximately each of these things takes. You need to guess. I mean, on the operational side, how long approximately each of these things takes. You need to guess. I mean, on the operational side, they know within hours, right? Yeah. I mean, there they really know how long everything takes. They know when the planes take off and land. That wasn't what you said when you were here for Christmas.

Well, there can be strange things that happen along the way. I believe they were lost in customs. Right. Yeah. So, yeah, that's a funny story, but I don't know if I can tell it. So, yeah, I mean, so absolutely, you know, that, that side can be planned very well, but then we all work on the engineering side more than that. And I think there, uh, sometimes the uncertainty is just larger, is much larger than the, than

the knowledge right i mean you don't uh you don't know how long it's going to take you to solve a problem that you don't understand that's where that's what i was saying it depends on the class of problem the kind of product but i think you can still list you know even if it's just okay step, step one, state the problem. Step two, create a hypothesis. Yeah, but you're listing things you have to do. That's not really a schedule. I find it can be the basis of a schedule, especially if you can identify that some of these are just guesses

and we have no idea how long they'll take. But at least we know what's going to happen after we identify the problem. The problem with that is that people outside engineering don't tend to look at them that way. They'll look at those dates and say, oh, okay, so this is going to take this long. Oh, unsolved problem in physics, it'll be done by Wednesday, right? Right. And so you end up with a product that I'm working on, which is now a year plus late, and everyone was convinced it was going to ship in August of last year.

And, you know, other things I've worked on where, you know, engineering will say this is going to take two years, and management will say that's unacceptable. You know, and that was our guess. And it took two years from when they decided that they were that they really wanted to go ahead with it but you know there's other things that come into that where oh this goes back to the companies who say okay we can't have it be two years it's got to be it's

got to be six months we cut and then later they want all of those things they cut and so the thing taking three years yeah but so i think I understand where you're coming from, Nate. I understand both arguments. Yeah. I know, but my main problem with schedules is that you can't put a disclaimer that's large enough on one that says this is for entertainment purposes only. Right.

Sorry. Yeah, I mean, so I think it's useful to have those meetings early to think about what is it you can actually put in the product and what's going to take too long. I think that's very worth doing. But once you've kind of committed to a path, I mean, I guess maybe I'd say my opposition is more to very short term scheduling, which I see happen a lot.

So Agile. Well, yeah, Agile, we, we might disagree with that as well. I certainly have, have not seen Agile done right. But I haven't, you know, I haven't, you know, I've been in the same place for five years, so that doesn't say very much since Agile's a fairly newish fad. if you're working on problems that are small enough that you can figure out whether you're going to be done in a week or not, then they're fairly small problems. And those are about the... I feel like my understanding of whether I'm going to be done...

If I know I'm going to be done in a week, then I know I'm going to be done in a week. And it's a fairly small, constrained problem that I can work on. If it's more of the I don't know where I am, then it seems to me that engineers, the canonical example is engineers always tell you two weeks, and that means I have no idea. And it could be between two weeks and six months or two years.

And they're going to tell you every week that it's two weeks out from then until they get down to a week. And so there you're just kind of using your own judgment as to when you think it's going to get done or you need to force them to, to break it down a little bit. But I guess it, you know, I think where you and I may be, well, actually where my strong reaction comes from is, is it's,

it is very much in Chris's court in the, in that I see people create schedules and then they create metrics behind schedules. And once people create metrics, then they stop understanding any of the disclaimers behind the data. And that's what bothers me, is that I see a lot of times where people create something that kind of they think visualizes where they are.

And where they really are is that they have two to three hundred individuals working on something, and each one of them has to get done. And they don't understand, well, you know. This is like those graphs in the bug tracking software that shows you how many have been entered and how many have been closed and that's how far you are in your project except it doesn't show you the 5 000 that haven't been entered because nobody's actually used the product yeah you haven't entered testing yet so it looks great you know we fixed all of the bugs except nobody's tried it yet so you know we haven't found any of them really.

Right. And then you tend to get yourself caught up in activities that may not really help you. Because you're just closing bugs? Let's go and close all the bugs. And, you know, because that makes the metric look good. And then people will go and do that. But, you know, did it advance where you were on the project? Well, maybe. I mean, maybe in reviewing all those bugs

you found something that you thought, boy, I really do need to get that done by this milestone and it was buried under all these other bugs. Maybe it increased the stability, but maybe you just spent three days reading bugs that never mattered. is just in oversimplifying the problem. And I definitely find myself frequently at loggerheads with other people because I feel that they've oversimplified something that is actually not as easy as they say it is. That's why I have a problem with Agile, because one of the precepts of Agile is

any problem can be broken down into small enough problems that you can work on them in a you know, a sprint time frame. And I think for a lot of things, that's just not true. They're ultimately reached an atomic size of problem that's still, I have no idea how to do this. You know, if you're doing something real that requires, you know, invention or creation of, you know, a genuinely new thing. Yeah, they probably didn't find the Higgs boson. With Agile, right. With Agile.

Although, well, yeah, okay, I'm not going to get into that. You wanted to, though. Maybe the danger is this. If you have these really short sprints, and if you have a schedule that you really try to nail down, then you'll usually try to get engineers to commit to something before they actually know the right solution. And so they do the easiest solution instead of the right solution. They'll do something to get that result in the first two weeks.

And then you'll say, okay, well, so you got that first thing done, so now how long is it going to take you to the next thing and the next thing? And they don't realize that they're, because you're applying this pressure, they don't necessarily realize that they're on the wrong path. And they get further and further behind as they're kind of digging a hole. And I've seen that a lot, I think. Well, I've done that. I mean, just recently I've had things to finish in a sprint, and it's had a large number of points.

I'm sorry to be using all this terminology that I hate. And I'll get something that works, and it satisfies the feature but i'll know it has problems and i'll generate three or four new tickets at the end of the sprint to go and really finish up this feature or you know through finishing it i decided i learned that the designers hadn't figured out what they wanted exactly and go back to them. So yeah, it's done, but it's done, but hail Hydra. You know, I cut off one head and now I have four. And I think that's actually the best case. As Nate was talking, I was thinking those times that I've written something to fill a checkbox and then written something on top of that to fill the

next checkbox and the next one. But I didn't go through and make it robust enough on all the sides. And I didn't make it usable. In fact, I made this long teetering pole out over the ocean, that as soon as you put the least bit of pressure on it, you're just going to fall to the water. And yet, you wanted a bridge. It's a bridge. It goes all the way across. Just don't stand there. And that's not a good way to make a product. And the more it's like science and the less it is like making a web page, the more likely you are to make an accidental toothpick bridge.

So on the other side of this, though, there's the, you know, you want to finish something and i just ship it i know there are engineers who given given no time pressure will and i'm i'm this person will never finish and so how do you balance that against i mean what do you actually what's your ideal mechanism then for for dealing with time and dealing with milestones? I don't know if there's an ideal mechanism. Is there a better one? You know, it's important where it is some sort of long-lasting thing that you're doing that it have conceptual integrity and that the, you know, it be something that people are willing to build on for a long time. So, it is important that they get going down the right path. Definitely there are people who will, as you say,

over-design and take forever. Or even just procrastinate. Or procrastinate. Or work on the fun parts but not the bridge supports. Yeah, yeah. And I think if you have a large enough team that starts to become less of a problem because you have other engineers who will fill in the supports around them

or possibly even design a replacement for what they were doing and then possibly even design a replacement for what they were doing. And then, you know, that just kind of comes out in the wash at review time. You know, it's definitely not good when somebody gets completely designed out or their stuff gets completely thrown away. But, you know, sometimes you end up down false paths or you end up with something that's much bigger and clunkier than it needs to be. And you have to understand that,

you know, somebody else may end up filling that in if, you know, if that does happen. But, yeah, it's tough. I mean, it's really tricky to get the right thing there. I don't think you can perfectly allocate people to problems ahead of time. And so some of it just kind of happens on the fly someone has someone is you have to have enough backup that you're able to kind of get to the end with a good bridge even if somebody goes off and builds something that isn't actually useful in the end

that's kind of the problem I have with software methodologies, too, is they all profess to be the one true way, right? It's like, oh, if you do this, you know, your project's going to be smooth. If you do Agile, you know, all this is going to, you know, we're doing the right things, here's this manifesto. And I think they don't really solve the problems of working with large teams to produce things. I mean, they're all, I think you have to have a methodology, but you also have to recognize that

it's not, it's not the methodology that makes the product. It's the people and the team. And it's, you know, having some agreements about how to work together is useful, but those are not, those are not the things that are going to cause you to be successful or cause you to fail. I mean, unless you go completely wild. And you do the full Agile methodology? But I think that comes back to scheduling. It's like, well, if only we did the schedule the right way, we would have been able to make this project. And I don't really think there are any projects that stand or fail on the quality of the schedule or the

quality of the process behind how you schedule. Right. But you need to have something to guide you. Yeah, I mean, you mentioned earlier, Lisa, treating people as replaceable cogs. It's not a good way to make a schedule that will stand up. I mean, I see that done a lot. You know, you don't refer to them as people. You refer to them as resources and say, I need more resources to solve this problem or something like that.

And I, you know, when I think about the people on my team, I have 20 individuals. They all have, you know, 20-ish, you know, varies from day to day. But, you know, they all have their own strengths and weaknesses. And there are certain problems I would put certain people on and certain problems I wouldn't. And, you know, or problems they'll be better at a little bit later. Or, you know, it's not that I have a set of problems and a set of people and I just have to draw lines between them.

You hope that there's enough overlap between people and problems and enough maybe interest in working together that you can get better stuff. And when I do schedules, I don't, you know, do a schedule on day one and say that's it. And yet I'm not one of those people who needs to iterate it every week to keep it up to date. I just occasionally like to know what's going to come next and then what's going to come after that in case it needs to be handled sooner rather than later. For me, it's all about tent poles and making sure you know where the long ones are and the short ones are

and bottlenecks and making sure that it's not my team that's causing the bottleneck. If you ever come up with something better than schedules, I would be fine with that. I mean, right. So there does have to be communication between teams to understand what's coming when and what you should build so that somebody else is not going to be blocked on you. And sometimes it's just unavoidable they're going to be blocked on you and you can flag that early. But it's not necessarily a solvable problem in every situation.

I mean, I've been in many situations where the answer is, well, we need to go back in time and a year ago we need to hire someone. Or kill someone. Right. So, I don't know. I find it, you know, sometimes you just find yourself in a jam and, you know, there is no great solution and you just have to accept that you're going to, you know, not get everything done that you wanted to get done on the schedule you wanted to get it done on. Oh, that's, yes. I think we've beat schedules to death.

All right. Well, let's go straight to burnout then. I heard you and Christopher talking earlier, not recording, but outside in the lounge chairs, about midlife crises, but I think that has to do with burnout.

God, I hope you guys weren't planning more Teslas. What? Do they make more? You had burnout on the list, but it was not a question. So I guess I don't have to ask it as a question. How do you feel about burnout? I love it.

How do you avoid burnout? Or are you... Are you now or have you ever been burnt out? Yeah, that's a... I think I've probably... You recover from burnout. Yeah. I think I have burned out of most jobs, I think. And so I'm probably the wrong person to ask about burnout.

But it's something... Or the right person. Or the right person, yeah. I mean, I'm the wrong person to talk to about managing it, as we discussed earlier. But it's definitely something that... It depends. Well, let me give you a chance to collect your thoughts and ask Christopher. You've certainly done the burnout thing.

How do you... I think there's different kinds of burnout. I mean, there's being exhausted from overworking, right? And you're just sick of it. Yeah, the three 60-hour weeks back-to-back. And that tends to be something

I think that you can, you know, as long as you don't do it for too long, you can recover from. I think there's more insidious forms, though, where you've been doing something for a long time and you don't do it for too long, you can recover from it. I think there's more insidious forms, though, where you've been doing something for a long time, and maybe it's just kind of a slow cognitive drain where you're not performing at the peak of your ability anymore. You're still engaged, but you're not as interested necessarily as you were. And that's kind of a slow burn now. And I've seen that in myself sometimes, just, you know, taking days to do things that would take hours normally.

Or getting stuck on problems and then finding, you know, it was a simple stupid thing that if you'd been really paying attention, you would have caught it earlier on. That kind of stuff worries me actually more than the dramatic, oh, I've had it, I'm tired, I'm exhausted, I'm physically wrecked from doing this, and I just need to put it away for a while. Because you don't notice the kind of cognitive burnout as easily. And that's the one I struggle with more,

because these days I haven't worked a lot of 60 burnout as easily. And that's the one I struggle with more because I don't, these days I haven't, you know, worked a lot of 60-hour weeks. But that doesn't mean things aren't still tiring or that you don't still overuse portions of your brain that need a break. So I don't know how to deal with that one because that's almost, you know,

okay, stop doing this. but this is this is what i do so so that's burnout of engineering that's not burnout on a particular job yeah or it could be a particular job if you're working on something that you know requires you to use your your brain a particular way well it's for a long time. The main reason I love shot spotters is because of the violence. It was cool, but I just couldn't deal with it daily. I'm talking about maybe solving a certain type of problem over and over and over again.

So let's say you work on I don't know, optimization. Maybe you're always doing optimization stuff and you get really good at it, but you've done it so long that you've kind of worn out that part of your brain. Maybe you'd be less burned out without even a break, but moving on to a different area. Yeah, Dave over at the EEV blog, the Amp Hour Guys, says that a change is as good as a vacation. And I think there's some truth to that.

Although I do engineering in so many different forms, it's hard to change. Well, that's another kind of, I mean, I think you can go the wrong direction that way too, and just be so scatterbrained, which I have definitely done.

Are you calling me scatterbrained? No, I'm saying you as in the royal you. But you know what I'm saying. I've got four things, and this goes back to what you're saying about having to do six kinds of management plus technical stuff. You don't get to put your full attention on each style or on each problem. And that can be draining too

because you're constantly switching back and forth. The context switching of managing 20 people. So Nate, which sort of burnout do you have? Probably all of the above. I mean, one thing we didn't discuss was organizational burnout, which is just, you know, are you... Playing the politics? Well, no, I mean, just are you having fun are you... Playing the politics? Well, no.

I mean, just are you having fun with the people that you're working with? Yeah. And you definitely see that a lot. I mean, that might be one of the main causes of people saying, I'm fed up and leaving. You know, they'll always say it was for some reason that wasn't that, but, you know... Spend more time with your family. Right.

But at some level, right, you can easily get frustrated with the cast of characters that you're working with. And you get tired of hearing the same excuses and get tired of solving the same interpersonal problems. I am very familiar with that from a burnout. And that usually is the one that is most likely to cause a flame out, which is when I rage and rage and hate everything.

Just want to burn it all down. Not that I actually would. There's no actual fire involved in this activity. But yeah, that sort of, that's when I leave jobs. I think that's true. I think that's when I've left jobs. I think you're right. It's organizational burnout where you just keep having the same fights with the same,

usually with me, it's been management above me. It's like the same fights and the same arguments and explaining the same you know why you can't draw seven red perpendicular lines green and transparent ink you know but i've had that conversation it's like this is how physics works if you haven't seen the expert, we'll put it in the show notes because it's going to be part of the engineering vernacular. And Andre, thank you for sending it to us. Also, everybody else who sent it, thank you. But definitely the red lines analogy, you need to see the expert video.

I've been in meetings and had to explain the geometry of circles to people to convince them why a certain display they wanted was not possible. They wanted something that was... Anyway. Somebody at ShotSpotter wanted us to detect broken glass instead of gunshots, but they wanted it only to be glass that was like window glass, not like broken bottle glass.

Yeah. No, I... Somebody at... I don't currently have a contract with these people, so somebody at a previous company asked why we couldn't just plug the sensor directly into the iPad. And this was a sensor that had to go to a giant console with lasers and spectroscopy

and a huge computer to do the computation. And the end part of it was a long tube with a little light sensor at the end. And they went, why can't we just plug it into the iPad? Because this isn't a fantasy world. Yes. Yeah. But people, non-technical people, Because this isn't a fantasy world. Yes. Yeah.

But people, non-technical people, bless their hearts. We have a lion in the shape of a kitten? Yeah. So, yes, organizational burnout. I think that's probably the most difficult for engineers to handle because with problems that you do over and over again sometimes you can find interest there if you could push yourself through them organizational burnout though ah it's got even thinking about there's only one solution to that there's quitting it's harder to me to find solutions to, I have to keep doing this job, and it's not really not interesting, but I'm losing my edge

because it's the same crank, you know, turning the same crank over and over. I fight boredom with new music, and that's why our music library is so large. Yeah, turning the crank, if you can get past that. As soon as the music can write my code. So, Nate. Burnout. Anything else you'd like to say about that? No, I don't think so.

Sorry. That's fine. I want, well, I guess I think we'll call this about done. I have just a couple smaller questions for you. But you've certainly earned a meal by now. A small meal. A small meal. No salt. What?

No, I have good stuff. Anyway, before we get back to Nate, if you listeners are an electrical engineer or a technician located somewhere between the Bay Area in California and Reno, Nevada. Look at iFluence, iFluence.com.

They make a head-mounted eye tracking system, funded but in early stages. What I did manage to learn about them, it sounded really cool. They need prototype help as well as design, so it is a build job. It isn't posted on their site, but you can email them, info at ifluence.com, and that's E-Y-E-F-L-U-E-N-C-E. The site link will be in the show notes. I'm not getting paid as a recruiter, but I would like you to mention the podcast, Help Me Earn Brownie Points, which I need since I pulled their show. And now, Nate, you are hiring for your team.

Yes. For your 20-some team. People could work for you. They could, or they could end up working for someone else. But yeah, we're looking for people who are interested in working on problems that are, I'd say, at the intersection of compilers and operating systems and computer architecture. And do you have any specific jobs in mind?

I don't think they've been posted on NVIDIA's website yet, but they probably will be in the next week or two. Are you interested in people talking to you or emailing me and I forward along resumes? Sure, sure. I've always been interested in that. So if you want to talk to Nate or consider his job for, what was it again, Nate? Definitely embedded software.

Oh, sorry. So we're... I guess I didn't really explain my group very well. Yeah, I guess we could have started with that, but that was like an hour ago. So what do you do? So my group is a software group within the CPU architecture team at NVIDIA.

And you guys released a really big chip recently from that group. A processor was announced recently, which is the Tegra K164. And the microprocessor in there is our design. And it's got a lot of bits, more than the normal number of bits. More than the normal number of bits. I think they said it's a 64-bit ARM design. Thank you. But it has a secret hidden 65th bit, I've heard.

Well, we haven't announced that yet. Oh, damn it. I didn't know what I... Okay, so the Integra K something or another, which I'll have to look up. Just Tegra, there's no N. Oh, really? Yeah, Integra's a car.

It's a good thing I had to do this professionally. It's not a car anymore, it's an old car. You've just dated yourself. Okay, so CPU group, architecture group. Yes, so we're a software team within the CPU architecture group. And we are, I don't know how to describe what we do, but it is a bunch of problems related to compilers, operating systems, and computer architecture. And brand new chips.

Brand new chips, yep. We work with the rest of the architecture team to figure out how best to design NVIDIA's next CPUs. So compilers would definitely be something you would look for? Very interested in experience or interest in that area. Very interested in experience in operating systems, understanding of the ARM architecture, and just general knowledge of performance tuning and CPU architecture. Optimization and power and all that stuff. Yep, we're involved with that as well. performance tuning and CPU architecture.

Optimization and power and all that stuff. Yep, we're involved with that as well. We work on a lot of cool problems. More on the software side, but pretty low-level stuff that runs on NVIDIA's in-house CPUs. How important is it to understand graphics? I would say that that's a bonus, and we've certainly hired people in the past

who've had only experience in graphics, but NVIDIA solves a much wider spread of problems than that. Cool. So if you feel like he was talking about your skill set, send me an email, show at embedded.fm or hit the contact link at embedded.fm and we will get you connected. So Chris, any last thoughts?

Oh, come on. I asked this of all the guests. You cannot be shocked that I asked this. And none of your guests ever have last thoughts. Occasionally, they come prepped when they actually read the whole outline, which most of them don't. But that's fine. I'm not your guest. I'm just the co-host, so.

Oh, I'm sorry. Well, never mind. No last thoughts for you. Now, Nate. Now that I've had time to prepare last thoughts. Any last words? I mean, thoughts? I hope dinner's good.

My guests this week have been Nathan Tuck and Christopher White. Oh, I guess I was a guest. You were introduced as a guest. Oh, I screwed that up. As always, I've very much enjoyed speaking with both of you. Thank you. And listeners, thank you

for listening. If you'd like to submit your resume, get connected with Nate, suggest guests, or make comments, hit the contact link embedded.fm, or email us, show at embedded.fm. I do like to hear from you. Also, since we are mutters this week, I would like to say hello to Dan, mutter class of

2011, who sent me email last week. As always, thank you to Christopher White for producing the show. He's made some changes to levels and volumes, balancing your calls for making it louder with my dislike of compression. He's great that way. And now, one final thought. This one from C.S. Lewis. I was quite amused by that. Friendship is born at that moment when one man says to another, What? You too? I thought no one but myself.