Good evening. Welcome to the technology lecture series that Sermon Audio puts on with the cooperation and support of the Computer Science Department. And we are very thankful for the opportunity to have tonight a speaker that Dr. Schaub will introduce. And I'm thankful for all of you coming. And so I'm going to open in prayer and then turn it over to Dr. Schaub. Let's pray. Heavenly Father, we thank you for your care for us. We thank you for your mercies, which are new each day. And even as we gather here to hear a discussion about how technology should be used, we would ask for insight from your spirit as we hear these topics, that you would bless this time and may you be honored. So we ask this in Christ's name, amen. On behalf of Sermon Audio, I'd like to thank you all for coming to tonight's talk. I have just a couple of housekeeping items here. First, I want you to know that we do have three $25 gift cards that we're going to be giving out in a drawing afterwards. And the way it's going to work is that we're going to be taking notes during the talk, and we'd encourage you to. as well and we'll be asking questions at the end and if you answer correctly then you will have an opportunity at one of those $25 gift cards. Also afterwards we have some snacks and coffee available and we want you to feel free to stick around and maybe talk with our speaker a little bit if you have some questions for him. We're going to try to keep this to just under an hour, so out of respect for your time. Our speaker this evening is Brantley Coyle. Brantley is an inventor and businessman. He invented the first commercial virtual private network and holds the fundamental patent on network address translation, which is a key networking technology used in every cable and fiber modem out there. It's a very significant bit of technology. He currently runs a company that provides network storage solutions and in addition he's a committed Christian who is deeply involved in his home church. Brantley has thought deeply about the state of the tech industry and its relationship to our 21st century American culture and he's going to share some of those thoughts with us this evening. Please welcome Brantley Coyle. I have prepared an outline so I can talk for most of the hour. If I don't prepare, I'll talk for two. Thanks for showing up. I really appreciate this being possible by the kindness of the department and of Stephen Lee with Sermon Audio and Stephen Schaub. And Jim here has been very friendly and very helpful. I first want to thank you. But mostly I want to thank you for coming out here tonight. I was told how many people are in the department. So just a second here. Let's see. No, I'm kidding. So I appreciate you taking the trouble and coming out. I hope to make it kind of worth your while. Because this is unusual. Can you hear me okay? I will just leave that there. Okay. This is very unusual for me to be able to talk in front of committed Christians about computers. Those are two things that I've done, but never in the same talk. So I appreciate the uniqueness of this. I also appreciate the weight that will be on your guys' shoulders going in the future, because the current state of computing and software development systems is not the best. It's pretty bad. And you guys, particularly as committed Christians, with an idea of what created order is, are gonna have to straighten it out. I'll keep working as hard as I can, but obviously I'm not gonna be around as long as you guys are. So I hope to be able to give you some insight and some help. both in understanding and also maybe some hints about getting a job when you get out. There are a lot of job openings, but there's an incredible number of people who think they can get them. At other universities that I've been affiliated with, they have department sizes like 1,500 people. And that isn't even the biggest of universities there are. There are a lot of people out there. Well, I hope to be able to explain to you tonight why you guys have an unfair advantage with everybody. First, the title of this talk is Plumbers, Preachers, Programmers, Culture, and Code. So why didn't I name it Plumbers, Programmers, and Preachers? Plumbers, Preachers, and Program, mainly so I could trip myself up when I'm trying to give the title. It kind of sounds like a sermon, doesn't it? You probably sat in a sermon and had to, well, it's sermon audio, so. But those three activities have something in common. First off, only one's a profession. Do you know which one's the profession? Plumbing, you're right, because you have to have a license to be a plumber. You don't have a license to be a programmer, and you certainly don't have a license to be a preacher unless you work in a denomination that has its own licensure, but that's still not the public license. So that's the three things they have in common. So you guys are learning a trade. It's not a profession, it's a trade, and it's a very good trade. I love programming. I've loved it since I decided it was my calling. And I'm glad that it's your guys' calling, too, that you guys have that calling. When you learn a trade, there are four things you're being taught and you're paying attention to. And this is true of whatever trade it is. And in fact, it's true of education in general. You're being taught a vocabulary. you're being taught some phrases and words that mean things, that when you're at dinner with your pastor and you're talking to Stephen Lee and Mr. Jim, he's understanding about 20%, right? So you learn the vocabulary, and then you learn the concepts behind that vocabulary, and some concepts that we don't have words and phrases for, but they're concepts nonetheless. So you learn those two things. And then you learn paradigms and idioms of the particular area you're working in. Programming languages have idioms. If you're going to make a loop to traverse something like a linked list, there's a certain way you do it. And if you're going to have an approach in general to something, you have a paradigm. So you learn those three things. The fourth thing is creativity. You have to learn and be taught how to creatively apply those. To do that creativity really well requires you to fully understand the vocabulary and concepts that you're using. So that fully comprehensively understanding is the problem that we're facing now. The complexity of the technology, and among a couple of other things, prevent one from actually being able to fully understand everything. That's not true when I started. So I still code. I code almost every day except Sundays. So I program, and I have done since the late 70s. Computing has been in history for eight decades, or touched eight decades, halfway through the eighth decade. And I've touched six of them. And the people I knew that taught me had seen it from the very beginning. And in fact, I've had the honor of meeting the guy that built the very first operational computer called the EDSAC that was in Cambridge in 1949. He used to show up to a conference that I was at all the time. So as a Christian, now you guys are gonna need to learn how to do this, and you're having to do it in a hostile environment. How did I become a programmer? Well, back in the 70s, 20-year-old, very prayerfully considering what to do. I was praying to understand. A friend of mine had taken a Fortran course. That's a programming language. And it was one of the two dominant programming languages when I came along. And he said it was kind of fun. He liked it. So I thought I would try it. So I signed up for Statistic 221, and I show up, and a guy comes in, an old geezer, older than I am now, actually, and he had a nose that was, it looked like it was gonna explode, just like I couldn't hear what he was saying as I'm looking, oh, I hope that, and he rambled for 50 minutes. And in that rambling, he mentioned that when he first got his brand new PhD and got his first class, there were two sections of that class, and they got all mixed up, and he had to spend the whole class straightening up, and that's the last time he ever prepared for a lecture. And it should. And I thought, man, this is not good. So I went to the department, and I went to the secretary there. Ms. Harriet Tripp was her name. And I said, I'm in this A section of Stat 221, and there's this old geezer in there. And I know you may be being kind to him and all that, but I just think maybe it's not. And she said, oh, well, would you like to speak to the head about it? Well, yeah, yeah, I would. I would like to speak to that. So she opened the door, and there sat the old geezer. And I said, hey, Dr. Cossack, I just wanted to say how great I feel about being in your class. So that was my introduction. So he gave me an assignment to do in programming. I did it. It just added a couple of numbers, and that was it. I looked up from that green bar printout, and I've been doing this ever since. And I've been really hooked. A friend of mine graduated a little later, and let me tell you what it was like when he went to his first job. And then I'll tell you what it was like when we hired some people at a startup that I helped start, and the difference. He was told when he got the job to report to a large Eastern company and to be prepared to work in the Unix operating system and would be writing the C programming language. We didn't have any of those classes, so he studied to figure that out. He shows up in his car in a big parking lot. He went into this really well-done building. He was met at the door by his manager. He was taken and introduced to the team he would be on, which was about 10 to 12 people. One of them was called the chief programmer. And this was the guy who had the vision for what they were doing. The other people on the team, some of them were documentation people, and several of them were programmers. Some of them were programmers that worked just on the tools. Some of them were like clerks, because this was back in the 70s, so there was still a lot of paper stuff to deal with, which we don't have anymore. And this was a chief programmer approach to development. This guy learned a lot. He wound up being a chief programmer himself and retired not long ago after a long, satisfying career and having learned a lot and created a lot of software, various software that a lot of people used. Now, and let's go to 2018. And you have another grad and he gets a job and he shows up in Silicon Valley. And he shows up at a startup, and it's about 60 to 120 people. He goes up. Nobody really says too much. They're friendly and all. And he goes and someone shows him to his desk. Now, my friend in the 70s had an office. It wasn't a big office, but it was an office. It was about 10 by 10, had a desk. The phone even had a switch to turn it off, and he had some bookcases for his manuals. We used to have to have manuals, now we don't have to do that. I just have another screen for that. So, but he's shown, instead, the friend's shown to a big room with these tables and screens for the laptop, and they're all in a big group. And then he learns that they're doing something called Scrum that day. So he goes in and has this meeting. And they're doing agile development. And it doesn't seem to be really any developer, per se. They all kind of do whatever they want, which means everything kind of gets included, because nobody's going to say no to yours, because then they'll say no to theirs. And that'll create just a really big problem. And anyone can change any of the code. There's no one owns the code. The guy in the 70s, what we had is we had ownership. If it broke and it was your code, you might get a call at 2 in the morning if it was an important software to have to fix it. And as a result, if you read through those codes, you would see that they made sense and they were clear. And they were clear because they were written to be read by someone who didn't know what it did, usually the person who wrote it six months ago. So this was what was there. Now it's just change it, change it, change it. It didn't turn out very well because the guy that in 2018, he was there about two and a half years and the company folded. Some of the people he worked with were pretty depressed because they had been through company after company after company. There was a kind of attitude at the startup of working for less and long hours, neglecting your spouse, because we're going to hit it rich on stock options. So we get lots of stock options and reduced salary, but that almost never works out. You're actually hitting it rich in Silicon Valley with a startup is about the same odds of being struck by lightning in the bottom of an empty swimming pool. So they all just really get burnout. I had a friend that I knew that I had met years before, and he was a very gung-ho, exciting guy. And he worked hard, and he was reasonable, and he did good. By the time I saw him again, he just said, why bother? He was just very bad code, minimal code, minimal work. And he said, they're just going to throw it away. That's the problem of a lot of the situation today. And I see that everywhere. Now, I'm not a Luddite. It isn't like I want to go back to the good old days, because I punched cards, and I used terminals that were 80 columns but 24 lines. When I first started, they were telling me I was spoiled because I got more than one run a day with the cards. I don't want to go back. I'm very happy with the level of silicon that we have now, right? So I don't want to go back. There are a lot of people who figured out how to do this trade that we have callings for, you guys and I have a calling for, to how to do it right. And it's more satisfying. It's more fun. It's less buggy, so it actually works right. It's more secure, and that's becoming an ultimate issue. And it's easier to use at every level, not just the user user, but you as using a library. or someone else using your code in their system. It just becomes easier to use. And we have learned how to do this, but it takes a different approach. One of the things you guys probably have, I've seen your curriculum, I've talked to Dr. Schaub about it and stuff. And I think you guys have a great curriculum that covers all the parts, which I came out and actually had lunch with Dr. Schaub before, because I knew I was going to be speaking about this. And I wanted to make sure you guys had the resources, and you do. So first, I'd like to describe what a computer is. Now, I guess you guys probably might know some of this, but maybe you hadn't thought about it this way before. And some people listening that want to do this, maybe not. Well, to start with a computer, it's made out of rocks. It's particularly a rock that has an area on it where it can actually vary the resistance conductivity through an area of the rock. And in fact, some of them are made so that they are on, and you put voltage near them, and they turn off. And some rock areas you can make that's off until you put voltage and it turns them on. If you put those sideways, they can complement one another and you can make a switch. The rock area is called transresistance or transistor. and having the both is complementary. And the way you make them is you use metal on top of oxide, which is an insulator, with silicon underneath, CMOS. So if you've heard the word CMOS, that's what it is. And I'm sure you will hear the word CMOS at some point in your curriculum here. Well, that's the first layer of the computer, but what do we do with it? Well, what we do with it is we make a calculator out of it. So we have a calculator. Now, we call it an arithmetical logical unit because it does all the number things you're used to, but it also does some weird things like shift bits back and forth and other logical operations like ANDing and ORing. So that allow them to do that. Then we take those areas of the rock, those transistors and gates, and we can put them together as register. We can turn it back on itself where it can remember. So you can set it and it'll stay set, and you can clear it and it can stay clear. This is called a flip-flop. Right? So you stack flip-flops together, and you've got a number. You can stack eight of them. You can stack 16, or 32, or 64. You put several of those up, like 16 is a very popular number. And that gives you what's called a register file in the computer. Those are numbers you keep. So then the computer, you pass through the ALU one or two of those, and you put them back in the registers. Well, 16 is not a very big number. Don't worry, I'm accelerating. So we actually make this thing over the side called main memory, using the same similar kind of things with the transistors. And the main memory can be really big these days. And so you've got the registers, you've got a calculator, you've got the main memory, and then you've got a piece that gives it the automation, because all a computer is. No matter whether you're doing AI, whether you're doing graphics, or audio, or video, it's just an automated calculator. So it's simple. And I won't go into the control section. We can talk about that if you want to afterwards, or you'll get it. But this is all a computer is. Now, when we try to make it go fast, it gets a lot more complicated, right? So you do all tricks to get it, try to get speed out of it to make it do quickly, like you can have more than one ALU, for example. You'd have a bunch of them, keep them all busy at the same time, things like that. But my point I want to make is, It's pretty simple in concept. There's no reason, there's no mystery like sitting in lit class trying to understand how they got that out of that. Right, it's very shade tree like. I mean you could, this is things that just make sense. Okay, so the fundamental of the computer is simple. We can make the software simple too. We can make it all work the same. When my buddy got his job in the 70s, Unix was, C rather, C reference manual in the book was only 28 pages. So that fully described the language sufficient to use it, okay, 28 pages. If you go today and get your C++ manual or book, it's over 1,000 pages, okay. And, well, he's just not as good a writer. No, there's too many vocabulary and concepts in it. Dennis Ritchie, who I had the blessing to know, invented C at Bell Labs from a language that his colleague, who I also know, Ken Thompson, invented a language called B. And Dennis took it and made it C. The next one would have been D, I don't know, but it was a very understandable language. You could completely understand the language, as you can tell, by 28 pages. The actual compiler itself was only about 200,000 instructions, Linux, for example, now has instructions, is almost 20 million bytes of instructions. So Unix turned into Linux, C turned into C++ and Rust and various other languages that are very complicated, have an awful lot of concepts and things. And the company went out of, the startup actually went out of business. And I created it anew. So what caused these problems? So I've kind of given you an idea of what caused the problems. Well, the culture caused the problems. And as Christians, we're well aware of the cultural problems today that we have to deal with. Well, how did that affect software? Well, it had a great effect on it. It had an effect that, first off, the idea of postmodernism, which happened after modernism, since it's called postmodernism, about the time the Berlin Wall fell, way back before your time. The nihilism as a cultural thing really took place, so the universe is meaningless. It was created randomly, they say. Well, that randomness means that you can't understand it. Well, our understanding of the universe started really well, started in the Protestant Reformation when we could study the laws and we knew we could search out the laws because we believed there was a law giver. and that we could understand his created order. So we started studying. Well, that had a reflective effect on actually the tools we use in the operating systems and the idea of working hard to make it understandable, to create things that are understandable. But if you don't have this idea of understandable, then you don't pursue it. You don't actually even do the effort. That's a high, this idea that it's not, that the universe isn't comprehensible is a major contributing to the problem with software today. The second problem is how we develop software now. So my friend in the 70s had the chief programmer team approach, where they were actually had, you try to limit the number of minds. They were actually working on an idea, so you got a clean concepts. You had one guy thinking and he's thinking this. People would help, he'd get ideas from everywhere. It wasn't like nobody was contributing, but he would pick and choose. C programming language was one guy. And he wrote the code and everything. That wasn't a chief programming team. It was one guy. Unix was two guys, two, Ken Thompson and Dennis Ritchie. And what we use as computing today pretty much was invented by those guys in the early 70s. It didn't take a lot of people. But they had an idea. Everybody knew who Ken was, and everybody knew who Dennis was. And while there was no org chart, everybody knew that they were superior because of just who they were. So you wind up with a hierarchy. You go ask Dennis, and you put a lot of value in it. Well, today, in postmodernism, there's no authority. Authority's bad. Paternalism is bad, right? Well, you can tell where that came from, right? If you make no authority and fathers are bad, then our heavenly father is bad, too. So you can tell where all that's going and where it came from. Well, that affects even our software. Because now, you go and you develop code as a team with an agile, where there is no one better than the other. They're all the same, and everybody's opinion is just as good as yours, which isn't true. I mean, I've been in rooms with programmers a lot better than I am, and I start very quickly figuring out who they are so that I can have them give me, well, what would you do here? And you start listening to them. And the chief program team was management listening and putting in the position of people with the authority to make the decision of how they do it. a good fortune even later after this to work for people that got that and gave me the opportunity to do that. So that egalitarianism is a problem with the way software is developed today. And at the end, I'll give you some ideas about how to deal with that, because you're going to get into that. You're going to be part of that. The third problem, though, is a really bad one. And it's something to be very careful about and to avoid. And that's the idea of greed. So I raised money in Silicon Valley. We did a company. And we sold about $100 million worth of storage products. And it was really good. People liked it. And I've been servicing those people ever since. The problem is they spent $200 million doing it. And the reason they did that, could do that, is they had, I raised venture capital. And the venture capital really was trying to, you know, you give them some money, and you give them some more money, and you give them some more money, and then you want to get 10 times what you gave them back in five to seven years. Okay, so everyone is motivated by greed, everyone. The company, before I got venture capital, actually we would have about two hours a week the staff talking about customers of what we need to do. What would be the best thing? Who's doing what? How do we help them do that? And California is a VC in this second kind of company. That lasted about 10 minutes. And then they never talked about a customer again. Now, to be fair to them, they thought they knew how to deliver to the customer. And I questioned that because they wound up having to spend more money. than we took in to do it, even though people really liked it. So this greed is a terrible problem. Well, how can they do be so greedy? What made the environment for that? And this next step here is key for you to understand where you're getting into and what the big shift is. For a long time, we lived in what is referred to as Moore's Law. Have you guys heard of that? Okay. And Moore's Law is usually expressed in the number of devices of transistors that you could fit on an area of that rock, right? And by rock, it's a silicon ingot. I know you guys are smart enough to know what it really is. Doubles every 24 months. Okay, but that's not really the issue. The issue is, what does it cost? So when silicon first started being used with transistors in 1958, there were transistors before that. There were computers before that. Early computers used vacuum tubes. So I mean, we were trying hard. Whatever it took to not do the calculation by hand, we wanted to do it. So the silicon transistor, 1958, $120 a piece. IBM bought a bunch. The ICBM folks, the Intercontinental Ballistic Missiles guys bought a bunch, right? So they were $120 a piece. Any guess on what the cost of a transistor now is? You too can have a million transistors for the mere price of a penny and about a third. 1.3 cents will buy you a million transistors today. Okay, so what does that really mean? Well, it means that the cost of calculating data has been dropped by that amount. So if you're in business that has to calculate, like insurance business or some other business, you have a value proposition. You have a cost structure. You have a price the customer pays. If that cost structure keeps Dramatically going down, you have a problem. You cannot adjust your company that fast. So you get out of business. It's called disruption in Silicon Valley. And if you think about all the companies, certainly at my age, I know all these computer, like this computer company, Digital Equipment Corporation. No, you've never heard of it, right? Yeah, they're gone. They've been gone. Data General. IBM's still here, but it's not IBM. Lenovo makes the computers that IBM used to make. So all this disruption, the closer you were to the epicenter of processing data, the more likely you are to not even be in business anymore. Well, what that meant is there were these opportunities for new businesses to replace them. You want a bookstore? So you start a bookstore, corner bookstore. Got the thing, you grow a little bit, buy a bigger space, maybe rent the space next door, knock out a wall. And then some guy named Jeff Bezos decides to have a bookstore with every book in print in it. And bookstores win by how many books they have, and you're gone. could totally disrupt it. Well, how can he afford to do that? Well, a reduction in the cost of the computing, so he can grow his farm. I have people, friends that work at Amazon, actually. So I get to see some of the inside. And they constantly reducing the cost of it, or they did. Okay, so that's why you had this disruption and upheaval, and an opportunity to make chaos, because as you build things quicker and quicker and quicker, they get messier and messier and messier. So this greed for trying to get rich quick, because it's a gold rush, because you could be, maybe you could be Jeff Bezos, right? You could be the next Facebook. You could try to be those things, because everything was changing so quickly. And they were changing so quickly because the costs were going down. And the cost was going down because the costs of transistors were going down. Processors are made on wafers about that big. They cost so much per wafer. That's the cost. You spend billions of dollars to make the fab, and you have many layers on that, and it's that big. And if you can make a lot of devices, then you can reduce the cost of the individual device. And that's what they were doing for years and years and years and years and years. Guess when the lowest cost, that transistor, that million for a penny and a third, guess when that was? You're thinking maybe last year, last week. 2011. So they're not getting cheaper anymore. So the disruption is not there. Like Facebook's still in business because nobody's disrupted them because. So this new disruption is going to be more efficiency. And more efficiency is what you guys are going to figure out how to do because you're using simpler tools. You're using the tools simpler. So how to fix it? So the way to fix it, what you guys can do, so one of us get in your job, and my advice, and it's worth what you paid for it to come here. Some of you are going to get, one of you are going to get a gift certificate. So some of you paid negative amount. That's pretty cool you did that. So take this with a grain of salt, but I really believe it's true. and I really believe it is compatible with the godly view of the world, is that if you study very carefully and become well equipped with the C programming language, which is still used everywhere, it is rated like the third most popular programming language, but it's everywhere, right? Your knowledge of it, no matter what job you're applying for, that you know C and you're not just that you know it and you learned a little of it, but really learn it. And it's not hard. It's 28 pages, right? So it's not like, oh, you've got to learn all 1,000 pages of C++. Now, you may learn C++ and all those things are great. I'm not saying don't learn anything. Don't learn other things, but really dig into C. The original Unix was 52 system calls. That gives you an idea of how complex it was inside. If you could really learn that, the Unix system calls, which are now kind of immortalized in a standard called POSIX, P-O-S-I-X. And you learn the POSIX system calls, which you can do from any other operating system. I think it's available in Windows. You've got it in Windows. You've also got it in Linux, buried in there somewhere. But you can look on it and see what are the POSIX calls and learn those really well. The other thing to learn really well, although you will not be writing any programming in it, is assembly language. Now, very few people write in assembly language for the simple reason that it is not as productive as writing in a higher level language like C. But by writing assembly language, you will learn what the computer actually does, what this automated calculator is really like. I had a friend of mine that got a job. He had worked for the startup, and he went somewhere else after. And I said, what are you doing? He said, well, I work for a company making Python code. I said, oh, you're writing a lot of Python? No, not at all. I'm looking at Python code. And I generally can get most of the Python system, which was a back-end web system, about 100 times faster in a few days. Well, how are you doing that? Well, I know C. I know what the computer is. I look at the Python code, and I go, well, take that out of that loop, because I know what it really costs. So even in Python, he's able to help. And by the way, Python, there was a study done, and they took a Python program, and they rewrote it in C, and tried every way to make it go faster. And they made it go faster by 600,000 times. So if you wrote a system, a back-end system that's a cloud and it's written in Python, what would your call structure be if you only had one 60,000th the number of machines? It's not quite that simple, right? Because there's a lot of other things involved. But you get the idea. of how to be more. So you learn those things. Two other things before I'm done with that, what you need to learn. And all this is here. It's great that all this stuff here is Bob Jones, that you can learn it. One of the others is FPGA, so that you can actually play at the gate level and understand. That's FPGA's Field Programmable Gate Array. You guys have a digital class on digital structures and stuff. The level of knowledge of that doesn't have to be as high, unless you want to go get a job doing FPGAs, which there are a lot of demand for that. So whether or not Bob Jones has a big lab of that, it's all so affordable. You guys can learn it on your own. The other thing to learn, and this I was glad to see you guys had this, is compiler technology. And you go, well, I'm not going to write a compiler. I once interviewed a guy at a place where I was working with COBOL, which is the other of the two popular languages way, way back in the day. Common business-oriented language, or as somebody says, compiles only because of luck. or completely outdated and badly obese language. I think that was the other. It's a chatty kind of language. But anyway, here to here, I'm interviewing a guy, and I say, so we do COBOL here. How much COBOL do you know? And he says, oh, I don't know any COBOL, but I can write you a better compiler. And well, thank you very much. But learn compilers not so that you can write a compiler, although maybe you will. But I am amazed as to how many times knowing how a compiler works is applicable to many other situations, tokenizing input. And since a great deal of computing is text, the web is text, HTML is text. And you don't just do raw HTML, right? You have something that creates the HTML. Everywhere you look, the posts are text. So how you process that, if you know compilers, you're able to do it in a more sophisticated and a lot of times easier way. So just the technology and compilers wind up being very useful and applicable in many, many other cases, which lets you make a simple thing where someone else would have to make a very complicated. Complicated thing. So those are the things you should really work for when you're going into interviews. And now you go to the interview and you get talking to them and you can mention these things and they will come up and you can, this will make where the interviewer will know that the interviewee actually knows stuff rather than fluff. By the way, I would try to avoid companies that give you stupid interview questions. I don't know if they're still popular, but for a while is. So you're two ants, and you go into a tube, and these are logic puzzles that are just a waste of time. I interviewed at Bell Labs, and I got the job, actually. And Dennis Ritchie actually interviewed me, or one of the people that interviewed me. And he sat down, and I sat down in his office and said, well, what have you been doing lately? And I said, what do you mean? He said, well, programming-wise. And I started talking to him, and he started asking questions. And we got his, well, that's been about an hour. OK. I said, aren't you going to interview me? He said, I just did. And those are the best interviews. And I tell you that because if you hear that, then you might want to let weigh heavily for the positive for that company, because they probably know more of what they're doing than the other. So let's say you go ahead and get the job, and you're in there, and it may be chaos. But remember, you're always a business of one, right? The W-2 employer is your customer, and you work hard to try to help him, OK? And you try to look around, who is the chief programmer? And you try to help that person. And you defer to them for the conceptual integrity of the systems you're making. You try to influence things. And you try to go places that maybe have more of these things. And then maybe a couple of your friends get together and you start your own company, right? If you start your own company, then I got some advice for that as well. First off is the purpose of a business, the reason for it, is to find and help customers. That's why you make a company. And to prosper your employees and vendors. You should make a reasonable good living. It's not to get you rich or the investors rich, if there are any. You give them a good return, so you prosper them too. But it's to find you have a purpose in doing that. You can do that if you're a W-2 employee in a firm. You can do that if you have a startup and you put your website up and you start doing things to try to help people. So I really want to ask you guys to consider how to make things simpler. And I've got some things you can read about that to learn more about it. First thing I would say is read The Mythical Man-Month by Fred Brooks. He explains how to do things simpler. He also explains the chief programmer team in that. anything that Professor Wirth wrote. So his name is Niklaus Wirth, but in the U.S. we call him Nicholas Wirth. He designed the Pascal programming language, the modular language, and then the Oberon. And I knew him pretty well. And he's also a person who makes things simpler. Not everybody likes his writing quite the same as the others. I'd also read anything from Brian Curahan. And he's had several co-authors, including a very old book called The Elements of Programming Style. And I'm going through that a bit at a time on LinkedIn now with a little post about each. There's some 200 little rules of programming. These people at the labs learned how to actually do software, and they're completely ignored. Well, if you don't ignore them and you learn them, the odds are high you will be able to surpass your buddies who didn't learn those and are kind of washing around in a sea of non-meaning, right? So 25 years ago, one of your colleagues decided to go out on his own. and to do his own programming and do his own system. And he's still here and he's done pretty well. And a lot of sermons you can listen to because he did. So it's up to you guys. I got maybe only another, I don't know, 20 years. Certainly Moses did better. Where I am, Moses is still out in the field with his flocks. being prepared. So do you ever notice that, Moses, at 40 years of being spoiled by the folks and the Pharaoh, at 40 years of being out there with smelly sheep, and then 40 years taking a bunch of God's chosen across the desert. I think it just got worse and worse for Moses. So my time, we will wind up at the Jordan at some point, and you guys will be continuing, and I hope you remember a little bit of this, and this helped you, and maybe help you try to get a compass, because a culture is a problem, and it's a problem with our trade as well as any other trade. So I hope this has been useful, and happy to answer any questions. I can wait longer than you can. Yes? So I'm not a computer science guy, so I don't know much about programming. I thought it was very interesting. But I'm just curious, what is your favorite programming language, since you know a lot of them? Yes. I do know a lot of them. And I understand the question. I appreciate the question, especially after nobody was asking a question. But I appreciate the question, and it depends. For what? So the best programming language I use, what I do is called embedded systems. So my stuff kind of is, it runs inside. So the camera over there is embedded, has embedded software running in it. The storage system is embedded. And the idea is to make it easier to use, right? It just does one thing well. Right, which is a Unix idea, making software that does one thing well. C works so well for that. Some people have tried to get me interested in Rust, and I've looked at it slightly, but if you're going to develop apps in a browser, there is no C. In fact, you're limited there pretty much to JavaScript. on the back end for different things. I tend to, because there's a premium in a company of being a monoculture, mostly monoculture, of one language, I pretty much do everything in C. Our business software is in C. We generate the HTML using C. But that's not necessarily the best way in every situation. For example, if a person doesn't know C, that's probably a bad choice. Although we can fix that really easily. Another question? Yes? So I'm an engineering major in aerospace engineering specifically. Cool. And I would say that I've had a couple internships and know a lot of people that work in microelectronics engineering. And I would say a lot of people in microelectronics are, even the engineers, are good programmers and are really good at making things more efficient. On the mechanical aerospace side that I've been on, I've noticed a really huge problem that they have is that finite element analysis, really fancy modelings and simulations, will take days to run on multiple supercomputers to actually get, because it's just solving billions of differential equations. And I've often thought, I feel like there's a market out there for improving and making that more efficient. from a software standpoint. And I guess my question is, do you think that's something mechanical engineers need to fix? Or do they need to have computer science people come in and fix that? Probably, well, the trade of writing software could be learned by anyone. And especially if your domain is narrow, that it could be either one. But what you really want to do is make sure that whoever is doing the software thoroughly understands what you're trying to do. You know, what is the finite element doing? Why are you doing finite element analysis? So they have an understanding. So sometimes it's better for the mechanical guy to learn how to do the software and do it. Sometimes you can get someone who could sort of understand that, but it's a mistake just to say, oh, it's a software problem, fix the software problem. Because they're not going to have the little insight that goes, oh, wait, we're wasting time because we never need that. Yeah, well, but it says in the requirements you've got to have it. Yeah, but we really don't have to have that. If we don't have to have it, how does it work? Right, so that's the fourth element of creatively applying the vocabulary concepts and paradigms to be able to achieve whatever you're trying to achieve. Do you think it's something that is reasonable to be done? Or do you think by the time, I guess, do you think that software's maybe developed enough where you can't really make it fast? Or do you think we can always make things faster and better? I think you can always think of something new. So there have been the free lunch of Moore's Law where it would get faster just by waiting, right? You know, I can make it twice as fast. Well, how do you do? I wait 24 months. And now it's twice as fast because I can have twice as many transistors working on it. But that's not really the creative. Gordon Moore said in 2012 that Moore's Law was done. He's the guy that they named it after. He had a paper in 65 where he said, I've noticed these, now we're putting more than one device on a piece of silicon, that every, first it was 18 months, and then it was every 24 months, they're doubling. And he said, so now you've got a reasonable, Morse said in 2012, now you've got a reasonable size wafer that only costs a few hundred dollars that has a billion transistors on it and seven layers of wiring, okay, well you can do a lot of creative things with that. And in your case, it would be the question of, is there any silicon creative ways you can deal with it, which gets back to the field programmable gate array, which is a way of figuring out. So I would never say, oh, no, we've learned everything. There's no point of physics. We've learned everything. And then quantum mechanics showed up, right? So there's always the fruit of creative work. Having said all that, I don't know anything about the domain. So I can't actually have an opinion on it. Another question? Yes. Did I? Oh, did I mention data structures? Ah, I am sorry for not mentioning data structures. Did I really not mention data structure? I believe it. It was in the list. It's a key thing. Absolutely. It should have been in the list. I should have read it instead of just keeping me down to an hour. Data structures is how we can organize how we think about the memory we're using. So you've got this main memory. In your laptop, it's a little micro DDR. In the bigger servers, it's a vertical DDR. And there are billions and billions of bytes in there. And how you deal with those and how you understand and think about them and work on them has been developed over time using data structures. And the data structures are linked lists, trees, and hashes. There's a book by Brian Kernaghan and Rob Pike on the programming. What is the name of it? It's TPOP, the Practice of Programming. They go through all the data structures and give you examples of how to do them. And also you have a good data structures class here. So very key, very key. Thank you. So link lists, trees, hashes, and have those cold where when someone's talking about it. I never write a link, I never use a link list library. I write it. It's five lines. I mean, you just don't have to use a library for these ideas. They should be just, you should know them cold and be able to implement and debug them. Thank you for asking that. Yes? You made a compelling case for the need for simplicity to get things under control. And I'm certainly inclined to agree with you. I do have to wonder and ask your opinion on this. Can simple, genuinely simple CPU designs ever be performance competitive enough, in the general case, to attract an audience? Because yes, the elements of silicon design, CMOS and so forth, you can describe them very simply. But if you look at the floor plan of a modern server grade CPU, out of order, speculative execution, That's not simple. No, it's not. And if you try to replicate that in an older, simpler style. Oh, no, no, no. Yeah, very good. It won't be performance competitive. Yeah, thank you for the. So when I said I wasn't a Luddite, I don't want to go back to the old days in that era either. There is a list of things that you do. and how that's done currently are not that bad, really. I mean, of all the places where we have complexity that's out of control, mostly it's software, but the hardware there is some too, but not as much because there's real real estate, right? So they really have costs of things. But I still think that if you have a finite analysis thing you're doing, And it really matters, and you take that to making your thing go well, to microelectronic design, and you look at your cafeteria buffet of ideas, You pick the ones to put in to work the specific, the application specific. And you can get simpler for that. A lot of FPGAs go into a system, for example, that reduce the need to run software really fast because you're doing it with actually logic. And when we can actually then transition and have a foundry where you can get a couple of dozen parts, I don't know if that ever will happen, then you could actually do things that are very efficient to reduce it. Now, that particular case of the microelectronics is particularly hard. But since you guys are not quite the big engineering school, that wasn't foremost on my mind. But in many places, a simple processor, and the other thing I will say is that understanding this concept of an automated calculator is not untrue. In fact, Intel particularly, I don't like Intel architecture. That's no secret. People know it. And it's not that anybody would. I mean, I knew some guys that worked at Intel. They didn't like it either. They kept trying to change it, right? But the one thing I did like is the fact that They made it very hard to notice anything underneath that you had the model of a calculator. You fetch an instruction. It goes in an instruction register. The little bits flow out and cause it to do different things based on the contents of that register. And then it goes and gets the next one. In reality, underneath, they were doing a lot of fancy stuff to go fast, like they would have multiple calculators, and they take a bunch of instructions, they digest it into a bunch of different instructions, and they start feeding that through there to keep all these guys busy. It's amazing they got it to work. And of course, if you remember the floating point fiasco, they don't always get it to work. They proved that was correct. That's right. They just didn't test it. That's right. That's right. So other question? Yes? How does one navigate trying to find a position or internship based upon merit, but also using the network of people they know and they've met that spiderwebs out? Because you don't want to get a handout, but you also can sometimes struggle to find a position without relying on the people you know. There's only one. Anti-social media, I don't like calling it social media, there's nothing social about it. LinkedIn has still, I think, is the best venue to get on and to be on and to talk about. And a lot of places, if you're careful, everything you post on the internet always lives on the internet, right? So you got to be judicious about any time you post anything on LinkedIn or whatever, just like any other time. But people can get to know you, and they'll start coming to you. So as you're going through, you can post interesting things. And headhunters are looking to fill jobs. And so then you'll start getting all these people, maybe, asking you. And then you look. You certainly use the people you know, because if somebody says, hey, there's a great place, let me tell you about it, that's worth 100 people you don't know more than that asking you questions. So I think the marketplace. for people getting out of school, really, or anybody, it really is probably LinkedIn. So I post there regularly. It's the only place I do post other than my website. So you can go there and check me out there if you want. Did that help? Yes, thank you. Other questions? Well, I can see by the old clock on the wall You guys probably need to leave. I really appreciate it. It's been a pleasure and it's always great seeing all these people turn out for me. Thank you very much.