Transcript from Between Midnight and 6am with Gustavo Pezzi, Chris White, and Elecia White.

EW (00:00:06):

Welcome to Embedded. I am Elecia White, alongside Christopher White. As you may know, I'm someone who enjoys taking apart toys and Christopher likes some retrogaming. So we're excited to talk to retrogame-tearer-aparter, Gustavo Pezzi.

CW (00:00:27):

Hi, Gustavo. Welcome.

GP (00:00:29):

Hi, everyone. How are you? Glad to be here.

EW (00:00:31):

Could you tell us about yourself as if we met, I don't know, at a games conference?

GP (00:00:37):

Ooh. That's a very existential thing, right? Who am I, and what do I do? Right. So I am Gustavo. I have been working with technology for as long as I kind of remember being born, I guess. But right now I work as an educator, right?

GP (00:00:55):

So I am a teacher at a university. And I also have my own kind of side projects where I teach things that I usually cannot teach at the university, so ... really my hobby, and the things that I get excited about, and the things that I believe students get value from.

GP (00:01:11):

So that is usually what I am lately. I am an educator. So I think that is my quick pitch.

EW (00:01:19):

Okay. And of course, since I've been teaching and really want to always talk about education, we will be touching on that too. But that involves the Atari.

EW (00:01:30):

So before we get there, we have lightning round, where we ask you short questions, and we want short answers. And if we are behaving ourselves, we won't ask, "How," and, "Why," and, "What about Zork?"

CW (00:01:42):

Zork wasn't on the 2600. Best Atari 2600 game of all time?

GP (00:01:48):

Best Atari game? River Raid.

CW (00:01:51):

Oh, I remember that one.

EW (00:01:53):

What was your first computer?

GP (00:01:56):

My first computer was a 286, actually, IBM PC.

CW (00:02:02):

What's the best game of all time on anything?

GP (00:02:06):

Ooh. There's a lot of nostalgia there for me, but I like a game, it was called Full Throttle, I don't know if you guys remember. It was from LucasArts.

CW (00:02:16):

Yes. Yes, -

GP (00:02:17):

Yeah, yeah -

CW (00:02:17):

- the guy with the motorcycle, and it was one of the LucasArts adventure games. Yeah, yeah.

GP (00:02:20):

Yeah. That was it. Again, there's a lot of nostalgia and probably a lot of historical context. And why do I like that, why do I like that game so much, but yeah, that just changed me. It was just incredible. A lot of it is storytelling, so I really like that. That was very good.

EW (00:02:36):

What is the best microprocessor, and why is it the 6502?

GP (00:02:41):

Oh, man. I will get in trouble for saying that, but it is not the 6502. I know. I know. I will get in trouble for saying that, but it's not.

CW (00:02:49):

Only with me.

GP (00:02:50):

I know. But there's a lot of technical reasons why it's not. But I actually think it was the 68000.

EW (00:03:00):

Okay, yeah.

GP (00:03:00):

I like the 68k, yeah, from Motorola. Again, there's a lot, I can go a whole day explaining why I think it was. I mean, the assembly for that was super friendly for programmers, but yeah, I still think the 68k holds the title.

CW (00:03:16):

Charles Mingus or Ray Brown?

GP (00:03:19):

Ooh. I love Charles Mingus.

CW (00:03:22):

Alright.

GP (00:03:23):

Yeah.

EW (00:03:24):

Why isn't Pong your favorite game? Isn't it the quintessential game?

CW (00:03:29):

It's incredibly boring.

GP (00:03:31):

Well, it would be if I have to pick a game to teach the concepts of game design or even basic electronics and things like that, yeah, that would be. But again, it's all about fun, right? I think Chris is right. It is all about what really gets my blood pumping. So yeah, probably Pong would not be the one I would pick.

CW (00:03:51):

Favorite fictional robot?

GP (00:03:53):

Fictional robot? Let me think about that. I really don't want to say R2-D2, but -

CW (00:04:01):

It's okay. You can.

GP (00:04:02):

Okay, fine. I'll think about that later, and I'll probably come back to something smarter, but yeah.

CW (00:04:07):

I mean, it is the correct answer. So -

EW (00:04:12):

Do you have a tip everyone should know?

GP (00:04:15):

Don't overlook the basics. ... Don't overlook the basics, right? Don't overlook the fundamentals. They are very important. Complexity can get super overwhelming. So always go back to the basics.

EW (00:04:42):

That seems like a really good transition into the Atari 2600 and why we're talking about that today.

GP (00:04:49):

Absolutely. Absolutely. Right. So ... people usually talk to me and they find out that I teach Atari 2600 programming, right, especially using assembly language and really low-level stuff. And people think that, "Oh, my God. You must be this incredible game connoisseur or someone that is just passionate about games."

GP (00:05:12):

But weirdly enough, the reason why I picked the Atari or that I teach the Atari 2600 is, I think the word is simplicity, right? I see most students, they come to me, and, especially now, right when I was beginning, things were a lot simpler, but especially now, people already start working with the browser and they start working with these super complex frameworks.

GP (00:05:36):

And I can only imagine how it is to be a beginner programmer right now. It must be super, super overwhelming. And again, not just guessing, right? That is empirically what I hear from people and I see from students at university and everywhere.

GP (00:05:53):

And I don't know, I just always ... had this gut feeling that when I was growing up and whenever we were just starting out, things were a lot simpler, right? We didn't have as many complex pieces to work with. You go on YouTube and then someone says that this language is better and that this framework is better. And then it just gets crazy.

GP (00:06:13):

So I just thought, "Why not just go back to the basics," right? Absolutely basics, right? ALU processor, stack, things that people just kind of read in books, but they don't actually understand. And they might be using those things.

GP (00:06:27):

Of course, they might be using those things on the servers and computers at home, or even at the PlayStation and things that they have at home. So I always thought, "Why not go back to the basics and really remove all those layers of abstraction?" So I think the word, like I said, is simplicity.

GP (00:06:42):

I use the Atari 2600 because it is so rudimentary, right? It's so simple. You cannot overcomplicate what is presented. You just have a box, you have some circuits, you have a processor that communicates with memories, that very basic von Neumann thing that you cannot escape from.

GP (00:07:01):

And, well, it seems to be working, right? People have been really liking going back to the basics and kind of limiting themselves in order to not get completely overwhelmed by complexity. So you just have the simple building blocks. You understand how they work. You send instructions to the processor.

GP (00:07:20):

There is a program counter, it goes up, you create a loop, and then people are just like, "Aha. So that is how things work." So that's pretty much the reason why I picked the Atari 2600.

CW (00:07:31):

For my own selfish education, can you describe really briefly what the 2600's architecture was like? Because I didn't have one. I had an Apple II Plus.

GP (00:07:41):

Yeah. Yeah.

CW (00:07:42):

But I knew about them, and I played at friends' houses, and stuff, but I didn't -

GP (00:07:45):

Yeah. Yeah.

CW (00:07:46):

Yeah. How do they work?

GP (00:07:46):

Yeah, absolutely. Yeah, absolutely. Absolutely. That's a great question. And so everyone understands what we are talking about, right? If you had an Atari 2600, you received this box, ... you had this cabinet that was wood and plastic, right?

GP (00:08:02):

So if you opened that thing, you had a board and that board is basically composed with the heart of the 2600, which was the 6502 processor. So the 6502 processor was this extremely cheap processor back then. And then, because it was super cheap, it just got super famous, right?

GP (00:08:22):

Everyone was using the Apple II, the Commodore 64, the NES, right, the Nintendo entertainment system, all these super popular machines, they used this 6502 or variants of the 6502, because it was cheap. So that was the main processor. And the 2600, or people called it the VCS, right, the Atari VCS.

GP (00:08:45):

The VCS had also a chip which was responsible for sending instructions to the television set, which we usually call the TIA chip. So these are ... the three main components, which is, 6502 processor, the TIA chip, which is responsible for generating the signal to the TV, right, to generate the scan lines with the CRT beam, and you also have memory, right?

GP (00:09:10):

So you have this chip with actual RAM that you can just write to and read from. So these are the main three chips that you will find on the board. And of course on that board, you have connected the joystick, right, the joystick input. You have, well, power, electricity, you have RF modulator.

GP (00:09:31):

But I think the basic architecture is 6502, the TIA chip that generates signal output, and also the memory, right? You have RAM. So I think this is it. That's what you have to work with.

EW (00:09:44):

But where do I get a 2600? You must not use them in your course. Is there an online simulator?

GP (00:09:53):

Yeah, there is probably the de facto emulator and simulator ... which is the Stella, right? So there is something called Stella, which... Stella was actually the original name of the project, the 2600. It was supposed to be called Stella.

GP (00:10:10):

So then you can go online and just download this simulator called the Stella emulator, right? So yeah, that's what most students use. For example, if you are programming the 2600 with me, you're probably not going to go and program directly for the hardware, right?

GP (00:10:28):

I kind of teach a little bit about that, how to write an EPROM or use an EPROM writer to generate a ROM for those things. But usually the students, they're just happy downloading the emulator, programming, generating the binary, right, the assembly binary, and just running on the emulator.

GP (00:10:45):

So that is usually what students kind of use. And I guess for all purposes, it is helpful for them to understand, right? You can actually see the register. You can see the values of the registers, the values of memory. So you actually have this kind of visual helper, that is a lot easier to understand what's going on inside the machine.

EW (00:11:08):

So it sounds like you are teaching microprocessors and how they work.

GP (00:11:14):

Yeah. Again, I'm teaching the things that people that work with high-level programming languages don't stop to think that much about. So again, the very low-level things like ALU, yeah, microprocessor, ALU, the instruction set that you have, how do you move bits, how you flip bits around, and how they manipulate bits to make things happen.

GP (00:11:39):

But also, right, how do you communicate with this other chip that generates outputs for the TV set? Or how do you communicate with memory? How do you work with the stack, right, if you have a stack? So, yeah. I would agree.

GP (00:11:53):

I do teach in the specific course, in the 2600, it is mostly about the 6502, and how to kind of poke the 6502 to make things happen on that limited box that you have in front of you.

EW (00:12:05):

But when I look at your site, Pikuma, P-I-K-U-M-A, I mean, I see that a little bit, but it looks like it's game engines and graphics.

GP (00:12:19):

Right. So the 6502 processor and the Atari VCS, the Atari 2600, that is just one of my courses, right? So I teach this kind of retro programming, and assembly, and low-level programming with the Atari 2600. But I don't teach just Atari 2600, right? So I always like to go low level.

GP (00:12:44):

So I mean, I do teach other things like C++ game engines, or even how to create a 3D render using C. So I always try to keep this kind of low-level approach to things. And also everything is from first principles, right? I try not to use libraries, or I try not to use just a framework that has an API, or even OpenGL, or things like that. I just go from first principles, like, "How do I draw a pixel on the screen?"

GP (00:13:12):

And then from that pixel, how do I draw a line on the screen? And from that line, how do I draw a triangle? And from that triangle, how do I draw a 3D object? So it is not simply just microprocessors. I try to cover things that people usually don't get the chance, or not even universities teach anymore, right, kind of the low-level things that evolve to be OpenGL, or the things that evolve to be these complex physics engines that we have today.

GP (00:13:43):

Yeah, it's super amazing to use these super powerful, complex tools that we have in libraries for physics and graphics, but how do they really work under the hood, right? What are they actually doing under the hood at the very low-level details?

EW (00:13:57):

Christopher likes learning from first principles. I think he went back to get a master's degree in physics, just because it irritated him not to understand the first principles.

GP (00:14:05):

There you go.

EW (00:14:07):

But ... I want those libraries. If I do it myself from first principles, everything looks crummy.

GP (00:14:14):

Absolutely. They do. And again, people usually think that I am very radical when it comes to this, but I'm not. I'm completely sober when it comes to this discussion, because what I'm doing here is just about offering a place where you can just kind of come with me and learn if you want to, right?

GP (00:14:34):

So if you have that itch, that if you want to learn these things, then you can just go and kind of, "Yeah, sure. Come with me, and we're going to learn, and have fun." But again, it's just for fun. I'm not completely crazy to dictate and say that the 6502 has any place in the industry today, for example.

GP (00:14:52):

Do you understand? How can I say this ... My approach is mostly about education, right? So I am trying to offer something that if you want to understand these things, this is what you have. And you have all this appeal of using a processor that probably was the processor that was used to create all these games that you played in your childhood or something.

GP (00:15:13):

So yeah, if you want to do that, that's absolutely fine. But not everyone kind of likes that. And also, not everyone needs that to be a productive practitioner. Again, I'm completely sober when it comes to that.

GP (00:15:24):

I have thousands and thousands of people, incredibly great programmers, and people that, they are productive. They deliver. They are reliable. And they really don't know, and they don't have to know these things. And that's absolutely fine, Elecia.

GP (00:15:36):

And again, one is not better than the other. My point is just, if you want to have some fun and come with me, sure. Let's just do that. I'm just trying to offer some options, right, if you want to learn these details.

EW (00:15:48):

How does this fit in with your day job?

GP (00:15:51):

Ooh, that's a great question. So it fits in between midnight and 6:00 AM when I can record my videos. So, yeah. So, yeah, so I'm currently faculty, right? So I teach, and yeah, that's not easy, right? So you have kind of office hours and teaching, but also, I was always interested in these things, right, into this kind of low-level understanding.

GP (00:16:17):

And in my day job, again, my background was mathematics. So I tend to teach mostly statistics. I'm teaching data science now. So I'm teaching all these very pragmatic courses and very industry-focused courses.

GP (00:16:34):

And since I do have that itch to kind of go back to the lab when I do know the students also want that. That is why I decided to start Pikuma.com just to say, "Okay, let's see if people enjoy these things, and let's see if there are other students out there that would like this content."

GP (00:16:50):

So yeah, it's usually between, yeah, let's say 10:00 PM, I start recording. Not just because of schedule, but because of noise. So if you are starting to record, if you try to record any lessons here, especially in a big city like London, you have someone building something beside you or a dog walking and barking.

GP (00:17:09):

So 10:00 PM is a good time for me to record. Yeah, ... and then at 7:00 AM, I'm ready to go to university again. So that's kind of my day routine, I guess.

EW (00:17:23):

I mentioned that one of your courses is about physics simulation in games, which is kind of a vast field. It's physics and CS, because you're programming, and calculus. Are you expecting people who come into the class to know most of these things or not, because it's hard to learn them all at the same time?

GP (00:17:48):

Absolutely. It's incredibly difficult. So, okay. There's a lot of things in that question I just want to unpack. So first of all, right, physics for games. We have to understand that physics for games is just a very, very, very small subset of what we understand as physics as human beings, right?

GP (00:18:04):

And if you look at the whole spectrum of physics, we are just dealing with some very small set, right? So if you think about physics for games, you're talking about Newtonian physics, right, how things move, how things collide, what happens when they collide. That is usually what we understand by game physics.

GP (00:18:23):

So just to be clear, this is what I'm covering with this whole game physics stuff, right? It's just this ... subset of physics that kind of make sense in the game, right? We are not looking at the atomic properties and how these nanoparticles interact.

GP (00:18:39):

Because unless the whole idea of your game is about the relationship of these particles and things, I don't think you actually have to code it. It's before Einstein, I would say. It's the whole Newtonian physics, ... very high-level understanding of collision, mass, gravity, this type of things.

GP (00:19:01):

But again, it's super fun and it's usually what games need. And again, remember when I said about the Atari 2600, right? The reason why I'm creating these courses to teach Atari 2600 is not because I'm just in love with games and extremely game-related things.

GP (00:19:19):

There was a reason behind why I chose the 2600. It's because of simplicity and to teach game physics also is not just because I want to create extremely fun games with physics. The reason why I'm teaching is because I want to expose the beauty of the mathematics that go behind all those things.

GP (00:19:41):

And again, the same way that people didn't take the time to understand how an ALU, or a processor works, or how it communicates with memory, or how DMA works, they don't usually stop to understand how calculus influences computer simulation or how even basic trigonometry can be used for this type of fun things with games.

GP (00:20:06):

So if I have the option of creating this physics simulation, and while at it, teaching these people basic trigonometry, because I see more and more, right, people, they graduate high school. They even go to college, but there are a lot of gaps in their understanding of applications of those things, right?

GP (00:20:26):

Maybe people, they leave high school understanding how to simplify an equation, and they know numerator, denominator. "Oh, I can just cross these things." But what does it really mean, right? Do you understand exactly, what are you doing when you take a cosine of something?

GP (00:20:41):

Do you understand exactly what is going on? Why do you take an integral in this place? This is why I created a course. And to answer your question, you said, "Don't people need to kind of understand these things already?" Not really, right.

GP (00:20:54):

I think, for example, if you want to take the physics course, a basic understanding of high-level algebra is enough. I kind of cover everything. I try to at least cover everything in the course, right, to make it self-contained. So I think that is always one of my goals as well.

GP (00:21:09):

We don't have to have this incredible background in mathematics to program a physics engine. It's kind of, again, first principles, right? You go, you start to experiment, you see the numbers, and then you try to find a connection. I think that is the whole goal.

EW (00:21:22):

Do you cover linear algebra and matrix operations?

GP (00:21:26):

Oh, yeah. Absolutely. Yeah, absolutely. Again, when I say calculus, not only calculus, but yeah, linear algebra, it's probably the most omnipresent thing in most of my courses. So in the physics engine course, I do cover a lot of linear algebra, a lot of vectors, a lot of matrix manipulation.

GP (00:21:45):

There's a lot of ... line collision. There is a lot of these nice things, but also for example, in the computer graphics course, right? So if you were talking about drawing triangles, and rotating triangles, and transforming things, that is a lot of matrixes there, right?

GP (00:22:01):

You have matrixes. You have vectors. You have transformations. You have projection. There is a lot of beautiful mathematics there. So yeah, I cover a lot of those things.

EW (00:22:09):

It's funny. I knew all of the matrix stuff from college, but when I tried to use it, I wasn't very good at it after school until I picked up a book about computer science and actually game simulation. Because the CS form of matrix manipulation makes so much sense.

EW (00:22:31):

I'm completely accustomed to arrays and how they go together, but just drawing it on a piece of paper and trying to find eigenvalues was -

CW (00:22:40):

Well, linear algebra was not taught well, at least at our college. It was taught by the math department. And it was linear algebra, and a lot of theory, and the matrix stuff, and eigenvalues, and eigenvectors. But I don't remember any applications at all in that course.

EW (00:22:55):

No.

CW (00:22:56):

And so I didn't really learn it well until physics when, it was like, "Okay, this is what this stuff is used for."

EW (00:23:02):

Yep.

CW (00:23:02):

"And here's how you understand it." And I was like, "Oh, okay. These are basically little functions," and getting an intuitive sense for what was going on instead of just, "Here's some theorems and stuff, and let's - "

EW (00:23:12):

And some numbers.

CW (00:23:13):

" - talk about the inner workings of linear algebra," which is of interest, but not of interest to people who want to use it necessarily.

EW (00:23:21):

But then if you go to machine learning, you need to have all of that well-internalized.

CW (00:23:25):

Yeah.

EW (00:23:26):

And yet people don't. I said that I like doing the higher-level things. Machine learning, I'm totally the opposite. I'm like, "You need to know first principles. You need to understand how the integration works, "

CW (00:23:37):

Yeah.

EW (00:23:37):

" - and how the derivatives are going to affect your gradients." And other people are just like, "Yeah, I use DALI."

GP (00:23:44):

Exactly. "I just import TensorFlow, STS, and continue from there." Yeah. No, yeah. I completely relate to what you're talking about. Again, that's what I live for, right? This whole education thing, I'm passionate about it, I really love it. Because I did exactly the same thing, I studied, high school, with probably the same curriculum as you did.

GP (00:24:07):

We always go to the same thing. ... I think it's all about context for me. Again, it might be just my brain that works like that, but if I don't put things into context, again, they are just numbers on paper for me, right? I just go and I manipulate those numbers, and I get the eigenvalues. ...

GP (00:24:26):

And again, the examples that people tried to use as a context before, they also didn't resonate with me as a teenager or as a kid, right? So it's always about, "Okay, you have this system of linear equations that you're trying to get," well, you know, right?

GP (00:24:42):

Again, I always say that if you put a dollar sign in front of a number, you just kind of lose my attention. But if you don't really kind of put these into context, I mean, it's very hard to kind of get the attention of people and hold their attention, right, and also make them motivated to come to the next class.

GP (00:25:02):

Because, "Okay, fine. I understood a little bit about how these dollars things are working and I optimize something or divide," but what better to motivate people than seeing something moving on the screen, right? Seeing kind of that vertex rotating, you asked to rotate that vertex and then the triangle rotates as you expected to see in that formula.

GP (00:25:23):

And then everything kind of makes sense. I think that was the divisor for me when I saw that students were like, "Okay. So that was why all those things that I pretended to learn before are used," right? So, yeah, there's a lot of beauty machine learning now.

GP (00:25:39):

All this linear algebra from machine learning, that is something kind of, yeah, I have to kind of teach at university. That is usually what I'm mostly focused on. I just found out that I have to teach R next semester ... Yeah, so mathematics is something that I see more and more people understanding the reason why. When it was in the '90s and the 2000s, it wasn't very cool to learn mathematics, right?

GP (00:26:07):

I mean, you had all these jobs, like, "Yeah, you will be an engineer. ..." There was a very kind of purist way of looking at mathematics. But now I see kind of mathematics and even physics, there's a lot of STEM disciplines that are really getting kind of into the good eyes of people.

GP (00:26:26):

And it's cool to be a nerd. It's almost like I see there is this kind of shift in the way that people are thinking. It's very cool to understand the math, right? Math is almost like this superpower that you get that you can use to make things happen, right?

GP (00:26:42):

And if you really understand how math works, it differentiates you from the rest. That is also a very good point, I guess.

EW (00:26:51):

In addition to having your own course set, some of which is also on Udemy, and having a regular lecturing job at a university, you also are mentoring for Classpert, which is where I teach my course. But you're not mentoring for my course. You're mentoring for Building a Programming Language. How is that going?

GP (00:27:16):

That's going super well. So yeah, again, the Classpert people, it's an amazing initiative that they have, right? So I knew about your course and I knew about your book, of course. And I knew about the Classpert thing.

GP (00:27:30):

And then Classpert contacted me and they said, "Look, we saw that you taught Lua," right, "the programming language that we use in the Classpert course is the Lua programming language." And I do have a history of Lua, right?

GP (00:27:43):

So Lua also, it was created in Brazil, right? So I knew these people from before. I knew Roberto, which is the creator of the language. So I had this history with Lua before, and then Classpert contacted me in and they said, "Look, we're going to have a course. Roberto is going to be the main lecturer, because he has a book on it."

GP (00:28:05):

"And we decided to kind of have this course that focuses on building a programming language from first principles and from scratch." And I was like, "Well, that's absolutely what I'm all about," right? We're teaching computer science topics from first principles and teaching computer science topics at the fundamental, right?

GP (00:28:22):

And yeah, ... I mean, this is the first cohort, so I'm still in the eye of the hurricane kind of answering questions and evolving the course. But yeah, it is absolutely great. I mean, just for people that don't know, it is a course that focuses on creating a programming language from scratch, right? So you go, you start creating a programming language, you start creating things like expression.

GP (00:28:48):

So how do you create a parser, something that goes and reads an expression from a text file, and can actually compute, and break those things apart, create a model, and parse an expression, and give you a result. And then you evolve, and then you create a variable, right? You have an assignment, and you create a variable.

GP (00:29:05):

And then after the variable, you can create a block. And then after a block, an if statement, and then an else statement, and then a while. And then, again, ... the fundamental, right, the building blocks, those things that we learn, if you know low-level programming, program counter, that thing goes in increments, right?

GP (00:29:23):

You have an instruction pointer, and then you have to simulate those things, sending to memory, fetching from memory. So, yeah, I thought it was a beautiful class, and it's going pretty well, very, very well.

EW (00:29:34):

Some people have have asked, I know, at Classpert they have asked, "Why is Building a Programming Language a useful course?" And it's somewhat like your physics courses that, it's about understanding the first principles.

EW (00:29:49):

It's not necessarily that you're going to build a new physics game engine. It's not necessarily that you're going to build a new programming language, but understanding how is so important.

GP (00:30:01):

Yeah. Well, we say that we don't use it, right? When I was younger, I used to say that. "Oh, I'm never going to use this." I used to go to the computer science class and learn complexity of algorithms. I was like, "I'm never going to use this." But just to open up [inaudible] about this whole programming language and why is this useful?

GP (00:30:20):

My first job, I remember that I used to work with this kind of computer graphic. It's like a CAD software, right? So I used to be a programmer for this CAD software, but it was a CAD software for architects. So the architect used to kind of move and drag and drop furniture blocks. So you can render the view. If you have a kitchen or a bedroom you can render and see those things in action.

GP (00:30:42):

And then one of my first things that I had to do, one of my first tasks, I had to create a module that the architects, they had to enter an expression that was supposed to dictate, for example, how does the door of a certain furniture open?

GP (00:31:02):

So I had to expose this kind of very small, what we call domain specific, language, right? So I had to expose this little scripting language for the architect so they can dictate, where is the pivot point of the rotation of the furniture door? What is the angle? What is the curvature that it opens at?

GP (00:31:21):

So we think that we are never going to use these type of things, but out of nowhere, sometimes you just have to. It is useful. You have to expose this small little language or something that is very specific. And then it's very important to understand, how do you parse this input that the user is typing? How do you parse those things?

GP (00:31:40):

Operator precedence, right? You have to think about those things. You have to think about loops and whiles, and you have to create those things from scratch. So yeah, I think it is funny that we always think, "Oh, maybe it's not that useful." But every now and then sometimes it is useful, right?

GP (00:31:55):

And the more you understand, and the more you understand how these things work under the hood, then the more you are free from tools. Because the tools, they are going to come and go, and the more you understand the building blocks of how those tools work, then you are free, right?

GP (00:32:11):

You own that knowledge. You don't depend on the tool. So I think that is why things are useful, even at something like building a programming language from scratch, it's always there.

CW (00:32:21):

And it's not even that you need to be an expert in everything or, -

GP (00:32:25):

Sure.

CW (00:32:26):

"Geez. I have to know how to write a programming language from scratch and remember how to do it for the next 15 years in case it ever comes up."

GP (00:32:33):

Yes.

CW (00:32:34):

You just never know when you're going to be, like you say, given a task that you need to at least have the right words, the right terms to look up, -

GP (00:32:46):

Yes. Yes.

CW (00:32:46):

- the right -

GP (00:32:48):

Or to talk to other people about things.

CW (00:32:50):

Yes, yes.

GP (00:32:50):

Yeah.

CW (00:32:50):

Or just to know, "Okay, this is the domain of problem that I'm solving. And so here's how I can go find things that will help." Like you say, tools, maybe you're so ignorant of the topic that you've been given that you don't even know what the tools are called.

GP (00:33:04):

Yeah.

CW (00:33:05):

And so just going through a course like this, even if you don't retain it all, even if you're not able to sit down five years later and knock out a C compiler, in my experience, stuff like that gives you just the little bit of head start to know how to start solving the problem, even if you don't remember exactly.

GP (00:33:26):

Absolutely. I completely agree with you. Yeah. And also everything now, ... it's about cooperation, right? You don't solve anything by yourself. So I always tell my students the more you understand the jargon, and the lingo, and the words that people usually talk and they refer to when they're talking to these things, it's better for you to also discuss, and also find new solutions to things.

GP (00:33:57):

Because as you are talking about things, and as you are fetching from your brain that knowledge that you have, it's a lot easier for you to come up together with a new solution or something that kind of makes sense. Yeah, it's all about understanding, right? Understanding, and again, if you understand how things work under the hood, and if you open that black box, then I think everything is a lot easier in the future.

EW (00:34:21):

I have this question here about, is teaching on Pikuma different than on Classpert because of the Classpert cohorts? But I realize you're a lecturer. You always have cohorts. It's not having cohorts that's odd for you, isn't it?

GP (00:34:38):

Yeah. It's very different. I would say that Pikuma, the whole concept of recording a course, and not being there real time, and having kind of students do things self-based, it's different than what I'm used to. Yeah. ... It's very familiar for me to go and point my fingers at a blackboard, and explain things, and look into people's eyes.

GP (00:35:02):

But also online, right? If you have a cohort, and then you have Discord, and you are talking, just ping-ponging ideas with people, that is somewhat easier. But if you just kind of create something, it is a lot of preparation. You have to think, ... "What is the knowledge that the students already have," right?

GP (00:35:21):

So what is the baggage that they're bringing? Are they going to be able to follow the flow and the whole roadmap that I have? I think it's a lot more preparation, I would say, for this type of things, because it is not agile, right? If you are on a cohort base, you can kind of steer as things are going. And if you have just a recorded lecture, you just have to really kind of think a lot more about the planning of that thing. Yeah.

EW (00:35:48):

One of the problems with my course is that my quizzes are terrible, according to the last cohort. They're too hard.

GP (00:35:56):

That's rough. Yeah.

EW (00:35:57):

How do I fix that?

GP (00:35:59):

Right. So you're saying that they're horrible because they're too hard. I'm not saying that there's actually a bad thing.

EW (00:36:05):

They said that they were like puzzles that they had to figure out what I meant, which is not what I want to have happen.

GP (00:36:10):

Wow. Isn't it life, right? Isn't life like that?

EW (00:36:13):

That's true. Okay. So they're just students, and they're whining. And I should ignore them.

GP (00:36:17):

No, no, I'm not going to say that. So, yeah, I always say that my scene is to actually do the opposite. Sometimes I try to overexplain things maybe that I shouldn't. I kind of understand. There is a different type of personality, right?

GP (00:36:41):

And ... I'm going to be completely a grumpy person now and say that, I think this is just a sign of the times as well, where people are very used to get everything super fast and not sit down and kind of try to savor the moment of trying to solve something.

GP (00:36:58):

So that is my grumpy response, but I would say that I try to give, always, examples. So if I give just a quiz or a multiple choice question, I always try to give an example kind of in the question that would kind of help them reason, and give some tips, right?

GP (00:37:15):

I think, maybe that's my approach. If I'm asking them how a processor works, or how a certain formula is actually working, or these type of things, I try to always put things into context. So maybe that will help them kind of know where to look for examples or even go in stack overflow and look for that specific example.

GP (00:37:37):

There's always some answer there that might help them kind of find the solution. So I don't know. Maybe just adding some context and giving some example in the question. But again, Elecia,I will have to look at the course that you created to see what's going on.

EW (00:37:53):

I just need general pointers at this place. And it's funny, my first cohort didn't complain about it. The second one did, so I'm never sure what's happening.

CW (00:38:04):

Yeah, N = 2. That's statistically significant now.

EW (00:38:06):

Yes.

GP (00:38:07):

That's it. Yeah.

EW (00:38:08):

We have a couple of listener questions.

GP (00:38:13):

Okay.

EW (00:38:13):

The first is from Brian, who asked, "What is the most ambitious porting project to the Atari 2600 that you have seen?"

GP (00:38:23):

Porting project for the Atari 2600 that I have seen.

EW (00:38:26):

I mean, is Tetris on there?

GP (00:38:29):

Well, yes it is. But again, I'm going to answer something completely selfish, which would be actually from one of my students. So again, I wouldn't say that it is significant in terms of the most well-polished ... But there was one of my students that I was completely blown away by this thing actually.

GP (00:38:47):

It's just the things that you never even imagine that will happen. So one of my students, he just created a port of a game. It was an old Commodore Amiga game called Shadow of the Beast. I don't expect you guys to remember that, but there was this game called Shadow of the Beast.

GP (00:39:04):

And then one of my students, he just decided to create a port for the 2600. And that game, it looks so good. And I was so blown away by what he did. Actually, yeah. So the name of the game now that he renamed it, right, is called Soul of the Beast. So you can just Google and you'll find it's so well-made.

GP (00:39:23):

He did such an amazing job. I was so proud of that. And so I would say that that might be my favorite. I would probably pick that one as the most significant port for me at least. It was super, super fun.

CW (00:39:35):

I just clicked the link, and it's running it in my browser right now.

GP (00:39:38):

Exactly. It runs on your browser. Yeah.

CW (00:39:39):

It's the first link, it just comes up and starts running an emulator.

GP (00:39:42):

It was incredible. Yeah. So yeah, it is a port of the Shadow of the Beast. And it's an old game actually. It has been ported for a lot of other consoles and machines. But when I saw that someone that kind of learned with me was able to do that and win awards on that game, I was just like, "I cannot believe that this is happening."

GP (00:40:01):

That was incredible that day. So, yeah. So I would say that that was the most significant for me at least, very selfish answer.

CW (00:40:08):

What's interesting is that those consoles lasted for a fixed amount of time and the game developers for them, -

GP (00:40:15):

Oh, they never die.

CW (00:40:16):

- they learned along with the emergence of arcade games. They were learning as they went and making games. And now you still have these conceptual consoles in existence and people who have had the advantage of 30 or 40 years of further development of concepts of programming and stuff.

CW (00:40:36):

Going back to that, the things they can do are now much more impressive, I think, than -

GP (00:40:41):

Much more impressive. Yeah

CW (00:40:42):

- what the people in the '80s were struggling to accomplish.

GP (00:40:45):

Absolutely. And also it's so much easier to find information about things. Back then, I remember, I had to learn programming assembly for the first 6502. It was just a book, just one book in the library of the city, that I just went there and I kind of rented for months.

GP (00:41:03):

And it was just this kind of Apple II 6502 processor, which I didn't understand. I didn't have an Apple II. So ... as a kid, it was very complicated for me, but there was just one book. That was all I had. And now you have information. You have actual developers from back in the day, creating blogs.

GP (00:41:20):

And you can read the things that they did, and you can read all this bit magic that they were using. It's super fun nowadays. I cannot think of a better time to be alive, to just learn about these things, things everywhere. It's incredible.

EW (00:41:34):

Actually, that brings up another question from Brian, which is about the optimizations that game developers use. I mean, we've heard about incredible, just making things small and weird, optimizations, because they didn't have the space. Do you teach those?

GP (00:41:56):

Yeah, so I try to keep everything as simple as possible during the course, but you will see that every now and then in the middle of the course, I throw some spices of historical things that happened or how a certain game solves a certain problem.

GP (00:42:15):

So I try to just put things into context again, "Oh, if you're trying to do this with the CRT display, this is what this certain game had to do." I might not go and spend three hours explaining all that optimization and really squeezing all the bits, but I just, maybe, throw it out there.

GP (00:42:34):

So people at least know that those things were used, but absolutely, this is a huge, huge thing. I had a student once that said like, "Oh, you were trying to approach 2600 programming from this whole educational perspective." And he said, "But that was not how people did it back then, right?"

GP (00:42:49):

"People were just like cowboys doing things as they tried to do things and squeeze everything that they can." I don't know how to solve that, because I'm a teacher. So I try to kind of go from the more educated point of view. But I completely agree, back then, the things that people had to do, ... you try to make as much as you can out of nothing, right?

GP (00:43:08):

... Well, especially for the Atari 2600, you have to squeeze everything from that machine. And I think one of the biggest things, I was just learning programming for the NES last week, and the things that people had to do in terms of compressing data, right?

GP (00:43:25):

Because if you just have a certain amount of memory, you have 32k usually, right? You have 32 kilobytes to store the entire ROM of a game. And that includes data as well, right? So if you have, for example, a Super Mario Bros level, everything needs to fit, right? The actual data of the level has to be in those 32k.

GP (00:43:43):

So the ways that people compress the data or create this kind of meta, the tiles of the game, they need to create metatiles, and group things into blocks, and compress things, using these different compression methods. I try to cover all those things, but of course, every game is different and every game has a different way of approaching this type of compression thing.

GP (00:44:03):

But yeah, it was a crazy time, right, with the optimizations that people had to do back then. I try to cover them and explain these things. But again, you would spend a lifetime learning about these things. And some people actually do spend a lifetime talking about the Atari 2600, and the NES, and all these things. Again, you can spend a lifetime learning and teaching about these things.

EW (00:44:24):

One of the things that I like to share is the graphics from Stanford or the graphics bit twiddling hacks from Stanford.

GP (00:44:31):

Oh, yeah. I love that. Yeah.

EW (00:44:33):

It's so nice, because they put together all of these different, small algorithms with optimizations for different reasons, like if you're out of code space, or out of RAM, or out of processing power. And I like the comparison of what kind of algorithms solve which kinds of problems. Instead of just optimize it, it's optimize it for, and I think that's so important.

GP (00:44:59):

Yeah. I always say, again, there is a lot of passion, because people come to the course and they want to learn about the Atari. "Oh, it was my first console. I want to learn to program." But you have to understand that ... all the optimizations that we're doing and all this kind of bit manipulation and bit flipping, they are useful for the Atari, right?

GP (00:45:20):

So, again, you have to always put things into context, understand what you are programming for. And especially back in the day, right? You cannot create so many generalizations of things. For example if you were talking about Pac-Man, you are talking about the bits that compose the graphics of Pac-Man.

GP (00:45:40):

You cannot think, for example, as entities and components, I don't know if you ever learned game engine programming, but there's a lot of abstraction and generalizations that we create right now, right? If you talk about an entity in a game, people are talking about this entity can be Super Mario or Sonic, or pick a point that you have to pick, you create this abstraction, right?

GP (00:46:00):

If you're working with a modern game game engine, you have these abstractions. You have this generalization that you create. Back in the day, you don't have the space, or the processing power, or any resource to think about these generalized ideas of creating an entity that moves.

GP (00:46:19):

You have to program the Pac-Man for that specific frame, for that specific time interval, right? You have to really tailor your game for what you are doing. So it's a different way of approaching, again, you are limiting yourself, but I think that by limiting yourself, it forces us to think about what's going on at the low level of everything, including today, right?

GP (00:46:43):

We try to escape from it, but in the server, in the console that we're using, yeah, maybe a different architecture, and maybe some incredible, different ways of moving data around, but you still have a processor. You still have digital signals.

GP (00:46:57):

You still have to work with negative numbers. You still have to work and think about how to represent floating point numbers. All these things are still around, so it's still useful for us to learn about these things.

EW (00:47:07):

It is. And yet I used to spend a fair amount of my time optimizing things. And now I don't. I guess that's not true, because my current project is all out of space again. But the processors have gotten bigger.

GP (00:47:25):

Yeah.

EW (00:47:25):

And the code has gotten flabbier. And that's okay, because it doesn't have to be super efficient anymore. But I do like hearing how it can be, because sometimes it does need to be.

GP (00:47:38):

But I do agree things are faster, and we do have processing power and CPU cycles to spare. A lot, right? So you can just create this incredible complex algorithm that shouldn't even be looping that much. And it's fine. It's okay. It delivers what it has to deliver. Again, sorry, there are schools of thought, right?

GP (00:47:58):

There are several schools of thought that say that this is why we have the crazy software landscape that we have today, and we should actually be paying more attention. So there's a lot of thoughts when it comes to these approaches, but I tend to agree with you.

GP (00:48:13):

There are, again, different industries, different requirements. Maybe you have deadlines. Again, there is no right or wrong answer here. Sometimes you just need to quickly do something, deliver, and test, because if you just spend so much time optimizing and then you spend two weeks optimizing, your competitor already released something.

EW (00:48:31):

Yeah.

GP (00:48:31):

It fails. It got back, they fixed it, and they got your client. So ... you cannot isolate yourself and just think about the technical aspect of it, because we are immersed in .... capitalism. And there's business and there are different constraints at play.

GP (00:48:47):

So, yeah. It's not an easy answer to just say, "Oh, yeah. You have to always optimize," or, "You should never optimize," also. That is also probably the wrong decision. So, yeah. Again, every case is a case, right Elecia? You have to look at, what are you talking about? What is the project that you're working with?

GP (00:49:06):

My reality is that I don't work so much with low level in my kind of day job or what I teach. And I didn't work with low level in my industry years as well. But even though, you have to always ask yourself, right, is this worth it? And you see a lot more frameworks and a lot more software methodologies that they just rely on failing, right?

GP (00:49:29):

So if you go, and you fail fast, and you fail hard, that's what you want. And then you can just go and adapt. And optimizing can be a tricky thing to do and sometimes is the wrong thing to do as well. I agree.

CW (00:49:39):

I think the question often is what are you optimizing for? Because when we say optimizing, we think, "Okay, I'm going to go into these loops and make them fast. And so they use less resources." But what are you optimizing for? Are you optimizing in the larger sense? Are you optimizing for release date?

EW (00:49:51):

Tech market.

CW (00:49:52):

Are you optimizing for how much this board costs? Because that might mean that you have to write more compact software if you need a smaller part. So there's all sorts of questions beyond optimizing code.

GP (00:50:04):

Absolutely. Or sometimes as a business decision, you just say throw more hardware at it, -

CW (00:50:09):

Yeah, exactly.

GP (00:50:09):

- and forget, and just get on, because it's cheaper, right? At the end of the day, it would be cheaper to just throw this super cheap hardware, it gets the job done, delivers in 0.5 seconds to the user. That's all they want. That's fine. So, yeah.

EW (00:50:22):

Speaking of hardware, you asked me an interesting question in email about EEs. And I haven't clued Christopher in yet.

CW (00:50:30):

Oh, no.

EW (00:50:30):

So could you ask it again?

GP (00:50:33):

Right. So my question was basically, I try to read things and I end up reading a lot about this whole reduction of offer in terms of electrical engineers, right? So if you look at the graph of graduates and even job offers, it seems like EE is in decline.

GP (00:50:56):

So I just wanted to kind of poke your brains a little bit, because you probably have been immersed in this world with the division between software and people from the EEs. And what do you see in this kind of ... alleged decline of EE offers and the EE market?

GP (00:51:16):

Do you think people are still going to go always for the kind of software world, or is there still a place for EEs in the future?

CW (00:51:26):

We had a long discussion about this on the Slack, the podcast Slack, a few weeks ago, because somebody posted an article and a graph that claimed -

GP (00:51:36):

Yeah.

CW (00:51:36):

- that EE, I think it was students are declining at universities and such like. And I wish I had it in front of me, because I thought I had said some things that were cool, but now I don't remember any of them.

EW (00:51:52):

You can pause.

CW (00:51:53):

I don't even know where it is.

GP (00:51:56):

Come on, man. Just open there, -

CW (00:51:58):

We talked so much.

GP (00:51:58):

- and it'll sound super cool. It'll sound super smart.

CW (00:52:01):

I don't know which channel it was. So let me look for it, because -

GP (00:52:04):

It's probably the same article that everyone is sharing. If something gets into Hacker News and then ... everyone is sharing on Twitter, everyone is sharing on Facebook, it's the same thing. Yeah.

CW (00:52:16):

So yeah, I saw that article that I think you're referring to. And just from my own experience, I don't feel like much has changed in terms of working with EEs or the interaction between them, how many of them there are. There always seems to be fewer than we need on a team. That's my first impression.

CW (00:52:44):

It's usually one or two people per project for these small embedded kind of projects where there needs to be a board made and sometimes a non-form factor board, and that kind of thing, and support for that.

CW (00:52:57):

I do think there's some truth to the fact that programming and coding, that ... this salary explosion that's happened with things like Facebook, and Google, and the Silicon Valley companies really pushing up salaries, draws people away from hardware to software.

CW (00:53:21):

I think that's definitely the case. But if I'm remembering right in that article, there was just a lot of anomalous stuff that didn't make sense to me, like the graph had a big pulse of software beating out EEs in the early '80s, which didn't make a lot of sense to me.

CW (00:53:41):

And it was unclear kind of what the sources of data were and how good the data was about what was happening. And the data was suggesting that basically universities are producing fewer EEs, and there's just less interest in it.

CW (00:53:57):

And so I think it's a mix of truth and maybe exaggeration. I don't know what the truth of of it is. Elecia, please comment.

EW (00:54:08):

I think that there is probably truth to the fact that there are fewer EEs. When I started my career, it was often one to one, one EE per one software engineer. And that was because the complexity of the software was matched by the complexity of the hardware.

EW (00:54:32):

The hardware engineers had to deal with EE PROMs and being able to flash them. And they had to deal with power-on boot sequences that were very complex, because the chips were dumb. And ... I don't want to say ESD isn't an issue now, but ESD was a huge issue then. I mean, you just breathed -

CW (00:54:54):

I still don't believe in it.

EW (00:54:55):

- around it.

CW (00:54:56):

I still don't believe in it.

EW (00:54:57):

And they had so much more to worry about. And now they buy a chip. The chip says, "Give me three volts, and I don't care about the rest of it. You power on. Just power on." It has its own memory. It has its own flash. And so all these things they used to take care of now are single pieces.

EW (00:55:17):

And now I can have one EE per five or even 15 firmware engineers. Because the firmware engineers have a lot more to do, because the software is more complicated.

CW (00:55:30):

So you're saying it's been optimized.

EW (00:55:32):

I'm saying we've optimized away the EE's. But yeah, the EE problem, the EE amount of work has decreased as industry tries to make their job easier and cheaper while the firmware side has increased, because they've made the EEs' jobs too easy. And now we have processors that are too big.

EW (00:56:01):

So I'm not seeing it as a problem, except if we're saying they're going away entirely. But I don't think that's going to happen, because antennas are always going to be a problem, and power is always going to be a problem.

EW (00:56:15):

And so while they may not need to deal with how do you have two RAMs that you can only access one or the other at a certain time based on the processor, yes, that really happened, now they have to deal with different problems.

EW (00:56:29):

But a lot of their job is putting together the Lego blocks that companies give them and figuring out how to smooth out the edges instead of having to design the whole thing.

CW (00:56:40):

And a lot of the people I work with in firmware are EEs. They're people who write firmware, but they also do hardware. Half the people we have on this show are firmware engineers who make their own boards or former EEs who are doing firmware.

CW (00:56:59):

So I don't think it's a simple and/or. And ... I have now found my comments. One of the things that article said was EEs are in short supply, and they threaten the industry. And there are no job openings and low pay.

EW (00:57:14):

Wait a minute, wait a minute. There are no EEs.

GP (00:57:17):

So dramatic.

CW (00:57:17):

There are no EEs, and nobody wants -

EW (00:57:18):

And there are no jobs for them.

CW (00:57:19):

And there are no jobs for them. Therefore the industry is threatened.

GP (00:57:21):

So dramatic.

EW (00:57:23):

Supply and demand.

CW (00:57:23):

That doesn't make any sense.

GP (00:57:24):

I know.

CW (00:57:24):

You can't have both of those things together. If the industry is threatened, the industry will adapt, and hire more EEs, and raise prices.

EW (00:57:30):

And pay them better.

CW (00:57:31):

If the industry isn't threatened, then they just don't need as many EEs. And so some other people asked, "How are they measuring these things? What is the measure of popularity?" It had a graph of popularity. So how do you measure popularity, right? Which universities?

CW (00:57:46):

So there's a lot of truth to things like the industry evolves, but I'm not sure, if you look at the graph and take it at face value, it's been a crisis for 30 years.

GP (00:57:58):

Yeah.

CW (00:57:58):

And at what point, so I'm not pooh-poohing it and saying there is nothing going on, but also, I don't know the truth of what's going on either. And certainly from the article that prompted a lot of people to ask questions about it, it's not clear what's really going on.

GP (00:58:14):

Yeah, that's fine. I mean, if I transpose that to software, everything that you guys are talking about, the problems that you're solving, and how things evolved, and sometimes you don't have to think, like I said, it's being optimized, right. That happens in the software world as well.

GP (00:58:31):

But again, it's always about, you rely on a certain solution, and then you just kind of glue things based on that solution that is already being implemented. But I don't know.

GP (00:58:43):

At least during my 30-something years of life, I've seen that ... real actual change in technology is a lot more connected to hardware than with software, weirdly enough, right? I shouldn't be saying that, but I always see that huge dent of our lives and everything that changes, there's a lot of hardware involved.

GP (00:59:02):

And I kind of feel a little bit sad that people are taking this kind of easy route to just kind of glue things together, and sell a solution, and glue things together that are kind of based on something that has been, quoting, optimized.

GP (00:59:15):

So, yeah, I still always think that there is a lot of market, especially in innovation, if you're talking about hardware and EEs. There's so much, so much, so much.

EW (00:59:28):

I have a couple more questions about Pikuma. First, where does the name come from?

GP (00:59:35):

Oh. The answer is not as cool as people would expect. The name Pikuma, it was a native Brazilian word, and I just love the sound of it. So basically that's it. Pikuma is, in Brazil, if you have a fire, right? If you just have a bonfire or something, and you have those little sparks of flame that sometimes get out of the fire. I don't know if if you know what I'm talking about.

EW (01:00:06):

Yeah.

GP (01:00:06):

Those little kind of golden things. Yeah. That's kind of like a Pikuma. I just love the sound of the word as well. And my wife always loved the sound of that word. So I decided Pikuma. No other reason for that. There's no smart nerd reason. Just that I like the sound of it.

EW (01:00:23):

The little sparks.

GP (01:00:24):

Yeah. Little spark. Maybe you can kind of force a little spark of knowledge or something, but I'm not going to go that far.

EW (01:00:32):

And how did you set up Pikuma? You have your own, I don't know, delivery system?

GP (01:00:41):

Yeah. So, I have kind of a third-party LMS, right? So I hired and I pay for a hosting thing that, they host videos, and they host the quizzes, and the text, and all the resources. So I do have an LMS, which some people call Thinkific. I think they're Canadian. It's very good. It's very reliable.

GP (01:01:04):

So I use them as this kind of main LMS port. But then, yeah, I mean the website and everything else is just kind of me writing HTML, CSS, and kind of building, gluing everything together, and yeah, throwing it out at the world and seeing how it works.

EW (01:01:18):

And I'm going to point out to those people who haven't been in the world of teaching, LMS is learning management system. Took me a while to get that one.

GP (01:01:28):

Got it. Yeah.

EW (01:01:29):

And you have a free bit shifting course. It's only a couple hours. Do you want to tell me about it?

GP (01:01:35):

Right. So ... yeah, free bit shifting is just a very, very quick, quick introduction to, for example, why would you even shift bits left and right? And why is that important, and why that was important back in the day for game developers, right, if you were programming for MS-DOS, or even some older machines that didn't have a math coprocessor.

GP (01:02:01):

Why would people shift bits left and right? And why were a lot of older games using bit shifting left and right all over the place? So again, that course is basically just a trial, right? So if you want to see my delivery style, if you want to see if you like that or not, if you like the context, it's just on trial. So if you want to check it out, yeah, that's the goal of that course.

EW (01:02:23):

What do you mean there are people who don't do bit shifting all the time? That's important.

GP (01:02:29):

Not anymore, I would say, but -

EW (01:02:35):

Gustavo, it's been a pleasure to talk to you. Do you have any thoughts you'd like to leave us with?

GP (01:02:42):

My thoughts. Sure. First of all, I just want to say that it has been super cool to speak to you guys, but I would like to tell all the listeners that if I can give you one advice, it's, do not overlook the fundamentals and the essential building blocks of life.

GP (01:03:05):

Sometimes we tend to skip steps and only after we are old, we realize that we should actually spend a little bit more time understanding the basic building blocks of things. So that was a motto that I realized later in life. And as soon as I realized that, learn the fundamentals, spend time with the basics, that really changed the way that I learned.

GP (01:03:29):

So if you really want to kind of deep learn things, pay attention to the building blocks. Don't go too crazy over the high-level mathematics classes from MIT and all these things. Yeah, sure. They're amazing. But look at the basics first, right? Make sure that you understand the basics. They are super, super important, and you can go a long way only with the basics.

EW (01:03:54):

Our guest has been Gustavo Pezzi, teacher. Check out his course on pikuma.com. That's Papa, India, Kilo, Uniform, Mike, alpha, dot com. Of course, we'll have a link in the show notes to that, and a number of other things.

CW (01:04:11):

Thanks, Gustavo.

GP (01:04:13):

Thank you very much, everyone.

EW (01:04:15):

Thank you to Christopher for producing and co-hosting. Thank you to Felipe and Jason at Classpert for introducing us and to our Patreon listener Slack group for our questions. And of course, thank you for listening. You can always contact us at show@embedded.fm, or hit the contact link on embedded.fm.

EW (01:04:31):

And now a quote to leave you with, from Jorge Luis Borges. "So plant your own gardens and decorate your own soul, instead of waiting for someone to bring you flowers."