Embedded - 436: 20 GOTO 10

Episode Date: December 2, 2022

Chris Svec joined us to talk about kids programming and how well the Joel Test has held up. Svec’s son (“The Kid”) developed an interest in programming by playing games. Most of his programming desires are around building games of his own.  Any time we talk about kids and programming, Scratch comes up. It really is that neat and is The Kid approved. Some resources to get you started (actually, getting started is easy, you may want a book to do more than the basics): The Everything Kids' Scratch Coding Book: Learn to Code and Create Your Own Cool Games! by Jason Rukman  Scratch 3 Programming Playground: Learn to Program by Making Cool Games by Al Sweigart (hey, we know that guy!) griffpatch on YouTube  Digipen.edu had two courses The Kid (and Svec) took. Both are free on YouTube: Introduction to Game Design Lessons DigiPen Basic Game Development Series Finally, in a shockingly unrelated twist, we talked about the Joel Test for determining the health of a software development organization. No determination was made on how good The Kid finds his current position. Transcript

Welcome to Embedded. I am Alicia White, alongside Christopher White. This week we're going to talk about programming kids. Wait, that didn't come out right. Programming for kids? Programming of kids? Programming by kids? Something.

And we'll probably cover the Joule test. The Joule test? Joule. Oh, so we're going cover the Joule test. The Joule test? Joule. Oh, so we're going to check diamond hardness and clarity? Okay. Our guest this week is Christopher Svek, who is not a co-host of this show, but is a frequent and much appreciated guest. Hello, Christopher Svek.

Hey, Chris and Alicia. How are you two doing? We're doing all right. Check back in an hour. Hey, Chris and Alicia, how are you two doing? We're doing all right. Check back in an hour. So you have switched jobs, and I know that we cannot talk about your role. Do you have a I am not responsible for what I say statement? Sure, I should say that I'm not responsible for, or rather, I guess I'm responsible for what I say,

but I'm definitely not speaking on behalf of any company I've worked for past, present, or future. And I'm just here talking to a couple of good people about whatever comes up, and it's not in any way related to employers. Can you declare future liability like that? I don't, I don't think you can. I wonder if I could declare that I,

I am talking for a future employer. Could you do the opposite? No. What if your future employer is a time travel company? Hmm. I bet the NDA for time travel companies is really, really hard to, uh,

to write. Okay. So we're going to go on to lightning round now. What? I don't have anything. We have no questions, so it's up to you to ask them and we'll answer. All right. Now I got it. I got it.

Here we go. Favorite Thanksgiving side. Mashed potatoes. Favorite Halloween candy. That's a tough one. Reese's peanut butter cups. Favorite Halloween costume that your child, henceforth referred to as, quote, the kid, has worn. Mario.

Super Mario. What's your favorite video game? Oh, that is a tough one. My guilty pleasure that I go back to and play whenever I just want to turn my brain off is Diablo 3. My latest game that I've been playing with a kid a ton is Mario Kart 8 on the Switch. Do you know what XYZZY comes from? Oh, yes. Which of the, is it Colossal Cave?

I think it's Colossal Cave. It's one of the old, one of the first adventure games Colossal Cave? I think it's Colossal Cave. It's one of the old, one of the first adventure games, text adventure games, and I think that brought you back to the start or something, right? It did indeed. I encountered this last night in a brand new video game, which I found

amusing and irritating. What is your least favorite? Oh, sorry. No, your turn. Your turn. What was the last nonfiction book you read and how was it? Oh, last nonfiction book I read. I'm reading one right now, which is, I'm looking up the title here. Um, it's called the way we never were. And it is about basically we have all this nostalgia for, you know, the golden age, the 1940s or 1950s or 1960s or whatever. And the book is a look at how most of the things we believed were better back then in the golden days were just completely not true.

And in fact, things were objectively worse on many axes. So I'm just starting that book, and it's pretty good so far. But the 80s, though, those were better. The 80s were solid. I'm going to say the 90 and it's pretty good so far. But the 80s, though, those were better. The 80s were solid. I'm going to say the 90s were pretty solid, too. Round wound, ground wound, or flat wound? Ooh, flat wound if it's a fretless, otherwise round wound. Do you have a tip everyone should know?

No. You asked this of a lot of your guests. of your tips do you think this guy has he's probably been here four or five times and he's given all the tips yeah i don't have any good tips anyway what is your least favorite uh nope that's a terrible question to ask somebody who's declared their liability uh what's your least favorite lightning round question yeah um it's probably the tip everyone should know because i feel like I don't have any. Many of your guests have great ones. I do not.

What is your favorite lightning round question? And have we asked it yet? I always like when you have the lightning round questions for guests where it's clear it's just for them. And especially when Alicia has like the murder bot, Martha Wells. I didn't even know what she was talking about. Yeah. I mean, you definitely had a bunch of questions in there where like, okay, you've clearly read her books and you know, you, you kind of, you kind of go geek in there to, to a

similar thing, like Chris's question about flat wound, round round or ground wound. You know, these are, these are the way different types of bass guitar strings. And so I, I appreciate that geeky insight into your guest. Okay, so let's talk about your kid. We're not going to say his name, and if we do, we're going to bleep it. Even though we offered to call him Mario, and he said no, which I thought would have been hilarious. That's right.

But the kid is how old? The kid is nine. And when did he start wanting to program computers? So the kid, like many kids, started playing video games. You know, we have a Switch, and so we played a number of Switch games. He particularly was drawn to Mario and to the different various Mario games and he played them for a while. Um, and at some point he, he started to ask me, how, how did they, how did they do this? Like,

is this, you know, he knows that I've, I've done, I'm, you know, I'm a software engineer and I've done a lot of software and, you know, he knows that there's code in the robots. We've done various different um online and in real life coding um coding simulators and simulators is maybe a bad uh bad word for but uh different types of programming exercises you know dealing with logic telling the turtle bot to move you three squares, that kind of stuff. And he seemed to think that was interesting.

But when he got into games enough and he realized, wait a second, people make these games and somehow they must program them. That's what you do, right, Daddy? And he said, well, yeah, kind of. So we ran it around and I knew Scratch was a thing. I knew that the, um, the MIT has this, uh, graphical block language, block programming environment, actually, it's more than just a language. And so we, um, we went over to Scratch's site and they had some, some decent little like intros and tutorials. And, uh, that's, that's kind of how we, how we started initially.

I do want to say that, like, I did not push my kid into programming, and everyone, I shouldn't say everyone, I hear many people say things like, oh man, every kid should learn how to code. And I don't know how much I agree with that. I feel like software, coding, programming, whatever you want to call it, can be mind-numbingly boring for people

who don't find it sort of intrinsically interesting. So I have a lot to say. Well, hang on. It can be mind-numbingly boring for people who do find it intrinsically interesting. That's true. That's true. You heard it here, folks. Programming is mind-numbingly boring. Mind-numbingly boring. No, I think it's fascinating. But as I describe what I do to normal humans, I'm like, yeah, this sounds insane. It sounds like I have a real problem that I sit here and type at this infernal machine.

And try to convince it to do what you want, even though it truly does not want to do what you'd want. That's right. That's right. It just wants to do what you tell it to do. It's kind of a jerk in that way. It doesn't want to do what I want it to do. Exactly. Okay, so he found games and decided he wanted to make his own games. Yep. Yep. And at first it was, it was just a little

bit, you know, he's kind of interested in it and I didn't want to push it, right. I didn't want to be like the overbearing father. And so, you know, he played with scratch a little bit here and there, but nothing, nothing, uh nothing too too big um and then at some point he maybe maybe we got super mario maker i think we got one of the super mario maker games which are these games it's basically a level designer for the the switch and so you the player can actually create levels using all the different blocks and superpowers and all this stuff and you can make your own little mario game And it's a sandbox, but it's pretty fun. And so at some point, he wanted to kind of say,

hey, how could I make my own next step? How could I actually make my own game? And so the internet is a wonderful thing, and we found a couple of videos done by DigiPen Academy, which is a, I think it's like a game, computer science game development focused school in college in, I think it's in the Seattle area. And so DigiPen, they also offer K through 12 classes. I think they have onsite stuff. They have some homeschool classes, whatever. They have this two different YouTube video series that were just like basically made just for my kid. One of them's

I'm sure we'll end up having links in the show notes here, but one of them is called introduction to game design lessons, which is five videos that teach you just enough scratch to kind of get into and figure out what, what is fun in a game? What, what, how does a game get fun? How does the game not get fun and then it lets you play with a little sandbox game they've created to make things faster slower you know better worse whatever and then you get to experience what actually makes a game what you know how do what does the sound do what does the animation do what does the actual like change the game mechanics do and so that was again i feel like it was made, made for my kid. And the second one they had is kind of the next level. And that's the basic game development series. And that's, that

is a take you by the hand and walk you through creating a asteroids type, not asteroids, sorry, a kind of a space shooter kind of a game. And the guy who who the guy who teaches it um who does the uh the videos actually uh is is an employee of digipen and he does just a fantastic job his name is doug swick um and it is clear that they understand like the theory of game design they make games and they understand the educational aspects. And so those were just like, basically, once we hit those, there was no stopping. No stopping my kid. There are a whole lot of different areas to game design. There's the artwork and the interactions and the story arc.

The sound. Right. Which parts are interesting in the graphics? Yep, absolutely. There's, there's, yeah, basically, it's actually kind of similar to embedded. If someone says, oh, I want to learn embedded. It's like, well, what do you mean? There's 73 different, you know, different unique things that you could spend the next 20 years diving deep into. And what happened to resonate with my kid is kind of the coding and the game design part. Like how does the game work, game mechanics,

and those have been kind of the bigger interests for him. There is similar content on YouTube nowadays where if you want to get deep into, oh, you want to learn how to do 2D sprite animation kind of stuff, or you want to do sound design for games. And DigiPen has some content for that stuff. I'm not sure how much of it is online and free. I know they have classes and stuff because they teach it. But, yeah, I mean, it's all over the map.

My kid is kind of centered on the programming and game design piece of it. And these videos were just perfect for it. And DigiPen is a university. Right. So you're not randomly choosing YouTube videos. Right. I was actually pretty darn wary of, you know, sitting my kid down in front of any random YouTuber, right? So I'd never heard of DigiPen before.

I basically started Googling for, like, kids guide to game design or however I stumble on it. But they have proven to be trustworthy, at least in their videos. How long has he been interested in coding? In kind of getting into the game stuff is basically January ish this year. So roughly a year at this point. And he recently made a mental breakthrough. Yes. Can you tell us about that? Yes, this, this was a, I mean, I'm probably an annoying parent at this point, but, uh, you know, you asked me, so I have no choice but to answer. He realized that you can use a Boolean as a zero or one. So a Boolean in a mathematical expression evaluates to a zero or one,

and you can use that to multiply by another number. And then your result will basically be either, you know, zero, if the Boolean evaluates to false, one if it evaluates to true times whatever number. And he ended up using that in this idea. And I thought that was great. Of course, knowing that lots of bugs come about because we forget that Booleans are ints too or ints are Booleans too. But to see his mental model of the world kind of open up was pretty cool to get to hear him talk about that. See, I got the extended version of that story that involved toothpaste. There was toothpaste. There was toothpaste. And dribbling during discussions of binary,

which I thought was awesome. It's true. It's true great thinking happens happens in you know in the bathroom brushing your teeth in the shower whatever so so he's using scratch what i have never used scratch or if i have i've forgotten it um maybe it came with some sort of robot toy at some point but anyway what can you can you describe what scratch is and how it works and like what i'm curious about its limitations and yeah that kind of thing yeah i was surprised so i i knew very little about scratch but scratch is a it is a or perhaps the block-based language if you hear people talking about block-based programming environments for kids then it's it's probably something like scratch you can go it's free it's open source

um mit is the one that invented it, and they maintain it, and they actively develop it. And it is a web-based programming environment and language that is geared towards kids. And so you have... I'm bringing up a project in front of me so I can describe it. The user interface is basically on the left. You have a bunch of blocks

and the blocks let you code using blocks and limited text. And the things that you manipulate in this programming environment are sprites, which are just pictures basically. And so it starts off, you start a new project and there's a cat and that cat is the scratch cat. And you can make him move 10 steps or turn 15 degrees or turn, you know, any arbitrary number of degrees. You can make him move to different X, Y positions on the screen. So it's got basic movement kind of commands. And then it's

got different ways to change the way the characters look, the sprites look. It's got events where I can do, okay, when I click the screen or when I press the space bar, do something. Or when something else happens and then triggers some other event. It has basic control blocks. You've got your repeats, your forevers, if, all that kind of stuff, as well as basic mathematical operations. And yeah, it's probably Turing complete, and it has user interaction stuff. So I can tell where people are clicking, or what keys they're hitting, or if a sprite is hitting another sprite. So if you go to Scratch, they have a bunch of tutorials that will show you all kinds of different things you can do with it.

You can create a story with characters. You can create kind of a simple game. You can record a sound. You can make unicorns appear on the screen. Stars come out of their head, that kind of a thing. And it's got a bunch of basic stuff in there to get you started. Okay, so I have played with Scratch a few times, mostly teaching middle schoolers programming. And it's really good because it's easy to get to something you can show somebody else and be pleased with.

It's a very story-based language. And in fact, one of the tutorials they have on their front page right now is how to build a story. The idea with some of the middle schoolers I worked with, they had their characters do things, walked around and do things. And they figured out that if they, I think it was hugged and danced at the same time, it looked like they were kissing. And then they got to have a kissing function like i mean middle school girls it it was pretty hilarious but they were excited to be able to tell a story with programming because it wasn't for them about the challenges of logic it was about making something they could share. And Scratch is great for making something you can share. And it is really quite, I mean, you said Turing complete, but it's easy and very expansive.

You can make a piano keyboard or you can make just about any 80s game you can think of. And it's not super hard. And it's a huge community in that there are lots of them out there and you can see their code and everybody's kind of sharing. It's pretty cool. So if you haven't tried Scratch and you've got a kid in the 6 to 12 range or even 6 to 15 range who's never seen coding, it's a good way to just get the idea that it's not about typey typey at your computer all day. Yeah. So I totally,

I think Scratch is great, except that it is a block-based, and that's not how my brain works. Yes, yes. Well, if you, so first of all, you absolutely nailed it. It is super easy and supposed to be super easy to get from basically knowing nothing to put something interesting on the screen that you can share with a friend. Like, I don't know that that's their mission statement or that's their vision, but you are absolutely right. That is what it makes it very, very simple to do and fast to do. The, it, when, when my son started using it, you know, he kind of, I felt like he was bumping up into the edges of what he could do with it after we did those couple of YouTube videos from the DigiPen folks. And so he, you know, he kind of, kind of practiced, He kind of made little games here and there. And then we stumbled upon a couple more books that he found to give him different techniques for doing things in Scratch.

And one is called The Everything Kids Scratch Coding Book by Jason Ruckman, R-U-K-M-A-N. And the other one is called Scratch Programming Playground, Learn to Program by Making Cool Games. And there's a newer edition, a third edition of that, and it's by Al Schweigert, I think. And I'll give you links for this. Yeah, but so those books had even more sort of, okay, here's different ways to do collision detection. Here's different ways to do sort of, you know, 2D game platformer kind of stuff. And at this point I thought, well, surely he's reached the end of what Scratch can do. Because, okay, yes, I can believe it's Turing complete, but, you know, you probably have to be

an expert, you know, I'll say adult professional programmer to kind of push it more. But I was wrong yet again. My son really wanted to make a 2D platformer. And I'm thinking, oh my gosh, I'm scared to go on YouTube and search for, you know, how to make a 2D platformer in Scratch. But it turns out there is just a vast amount of really good content out there where people have done just ridiculous things and remaking every Super Marioio every every nes and probably super nes game that uh that you may have grown up with or still be playing now people have remade on scratch and a number of people have tutorials that show you in pretty kid-friendly language and and kid-friendly kind of format hey here's how to make basically a mario clone or an rpg tile based scrolling game that kind of

a thing and then this one guy his son is youtube and uh and scratch handler griff patch g-r-i-f-f-p-a-t-c-h so griff patch his stuff was just amazing and is amazing and he puts out a video every week or two and he goes through again showing how you can make basically like very good mario or you know zelda or whatever types of games using scratch and shows how kind of computer science topics can be used in order to uh in order to to make these games i feel like it's kind of a tricky computer science education that kids don't realize they're getting. So when are you studying him on C? Well, he is quite comfortable with Scratch and still learning stuff in Scratch. And so he knows that he can do more with, with other languages, but there's, there's

definitely like a comfort level with, he knows that he can be successful at what he wants to do right now. And the adult learner in me and the, whatever, whatever I am makes me think, okay, what's next kid, you know, like, let's, let's, let's move on maybe some JavaScript so you can learn how to kind of put this stuff on the web or let's get some Python or something, something, something. I need to stop myself there because he's spending good quality time making different games and inventing stuff and coming up with stuff. And so I've told him that, hey, there's other stuff you can do, see your JavaScript or whatever, but he's comfortable where he's at and he's enjoying it so we're uh we're sitting pat on that right now well it goes back to

there are many different types of things you can learn from game design and learning cs concepts that wasn't even in our list but it should been. And platformers and how to make things fun and music and all of these things, none of those are limited in Scratch. Yep. And actually, Scratch has a really good, simple sound editor. It has a really good, simple graphics editor. It has a really simple sort of costume animation sort of technique. So you can make your cat figure move by changing what they call a costume is kind of what it looks like. And you can make the legs move and the arms move. And if you do that in rapid succession, then it looks like he's running or walking or whatever.

And Scratch makes all of that easy enough and quick enough so people can be successful with relatively little effort. This goes back to something I think I talked about many years ago on the show, but I don't remember what the context was, but I think I was talking about how I learned to use computers and program and stuff and how in the 80s computers were far simpler than the things we have now. You could do less with them. They could connect to fewer things. And the way you programmed them was very constrained. You typed in things from

magazines. You could type in things from magazines. The computers generally, Commodore 64, Apple IIs, whatever, TI-99s, they all came with some form of BASIC. When you turn them on, most of them dumped into a prompt that was kind of the BASIC shell, for lack of BASIC. And when you turn them on, most of them dumped into a prompt that was kind of the BASIC shell,

for lack of a better word. But you could just type commands there and it would execute BASIC. And if you type line numbers, then it would start to construct your program. So BASIC was the operating system of these computers. And that's what you got. And that's how you learned.

And I think in the middle somewhere, we got to this point where computers are these extraordinarily powerful things and if you want to program them well you get an integrated development environment and you know you have to learn all these things which are far too advanced for kids um in the most cases to kind of start from um so i feel like this is kind of back to finding a place to make that experience happen again where here is where you are and you can just make stuff happen and see it immediately and you can learn these things

in a constrained little environment that doesn't require you to use professional tools. Yeah, let's leave debuggers and compiler optimizations to, you know, when he's 10. All those things existed in the 80s, but I think

at some point computers became so general purpose and for so many other things that they were no longer for programming. But like the early Apple II, like I said, they booted into apple soft this is a computer that's for programming yep yep i mean my first computer was a commodore 64 and absolutely yeah you you get in there and you do 10 you know space print you know your sibling

is a butthead yep you know 20 go to 10 and like there you go you're're, you're, you're a programmer, right? And, uh, yeah, if my brother's listening, you know, I stand by that statement, but, um, I actually, so Chris, that's interesting. Cause I didn't actually, I hadn't thought of scratch that way, but scratch, you know, if you go to the website, it absolutely is the Commodore 64 startup screen. Cause there it is. It's a constrained environment and you can do stuff with it in pretty simple fashion but you can do stuff sort of right away so i hadn't thought of of the scratch ui and the scratch interface as that great of an enabler like from you know this is the basics but maybe this is the new boot screen or reset screen so i like that i like that comparison because yeah

something i mean basic went away, right? I mean, BASIC came with DOS, too, and you could slightly less easily, but easily write stuff in DOS. And Windows had QuickBasic, which a lot of people learned to program in. But eventually that stuff kind of fell by the wayside. And now I think, yeah, you see people suggesting JavaScript and Python, but I don't feel like those are easy to get going. No, because you need a compiler, and you need to understand what a compiler is.

Not for JavaScript or Python. JavaScript you can just run in a browser. True. But it's weird. With Python you need an interpreter, and then if you want to write a file, then it gets complicated pretty quickly. Yeah, with Scratch, you don't have to know that there's a file backing all this stuff.

You don't have to know, you just click save and it saves in the little folder on your desktop instead of, you know, Python, you have to know that there's a.py file and you have to run it by typing some weird Python word and then space and then you get this. Yeah, so there's definitely a lot more hoops to jump through. You said on the embedded patron slack about reading JavaScript for kids? Yeah, yeah. My son had expressed some interest in like, hey, what is beyond Scratch or what are different types of languages? And so I don't know JavaScript at all, but I kind of poked around at, okay, what does Python have? Does Python have kind of a batteries included sort of game development sort of thing?

Because that's the thing he's going to want to do. Does Python have it or does JavaScript have it? So I looked around a bit and I came across that particular book, JavaScript for Kids, and it used Chrome's just built-in debugger to kind of start right away. And so like you were saying, Chris, it doesn't have basic prompt, but it's got this, you open the debugger up,

and you can start typing in JavaScript right away. And then it builds on some of the basic Canvas libraries to start building silly games. And it has like an insult generator in there, which of course every kid and probably male human on the planet thinks is a funny thing. And so there's, yeah, so it kind of seems to hit the right audience. And it's, look, you can pick it up. You can use Chrome.

You don't have to install anything and off you go. What are you going to get your son? What are you going to get the kid for Christmas? I don't want to say that because he might listen to this. Do you think it will be programming related? I don't think so, actually. You're getting MIR, aren't you? An IAR. You go, son, you've disappointed me.

Here's IAR. If you don't do the dishes, kid, you're going to get Kyle. I got you a development seat, son. I can't afford a development seat, Chris. See, but when I was not too much, or I guess three or four years older than him, I did get a compiler for Christmas. And I was very excited,

which should probably disqualify. Well, I was for the Apple II GS at that time. So it was a C compiler. Oh, a C compiler. That's C or C++? But it wasn't like Borland or anything you remember. No, they didn't have Borland for Apple II. Apple II, the Apple world was separated from all of those people.

Still is. No, it isn't. They're all gone. No, I... Somebody buy Borland now? I just mean, I, never mind. Is Turbo Python available? I don't know.

I'm kidding. Look, as long as he doesn't ask for Rust, everything's okay. No, we did not say that. It's free. Not under my roof. You can't even get stuff in it. When I bought a compiler, it came in a box. It had the box and a big, thick manual and disks and stuff.

And you had to put the compile disk in to compile, but then you had to eject that and put in the linker disk to link. I still have my Commodore 64 spiral-bound programmer's manual. I think it's great. I mean, it's nostalgia at this point, but it's pretty great.

So do you think, how do you think the transition will be when when it happens from scratch to something else do you think he will be surprised annoyed perplexed i i think i think about this um i think it's a pretty general statement because whenever i have to learn a new skill or something, if I'm fluent in something and if I suddenly have to go do something a harder way or transition to a task I'm not as familiar with, it's frustrating. And so I'm imagining he's going to be kind of frustrated because right now, you know, with Scratch and with relatively little effort, especially since he's been practicing it for a year, he's able to create roughly what he has in his head

because he knows what's possible. And hopefully with a thing like a JavaScript or Python or wherever he ends up, there is more that is possible once you get over the learning curve. But I'm guessing it's going to be like a, you know, two steps forward, 10 steps back for a while kind of a thing.

And that, my my guess will be frustrating the great thing about scratch is that you can see examples of what other people have done and you know that you can get there the other great thing about scratch is that it is not too complex so that unless someone's gone really overboard you can you can look at what people have done look at their projects look at at their code, their blocks, and with some effort, sort of figure out what they've done. I think typed, you know, written programming languages, things tend to get a little more opaque, depending how they're written and designed, obviously.

But, yeah. You're going to have to give him something he can't get from scratch, like robots or physical objects, CircuitPython controlling LEDs with an IMU. So actually, Scratch has plugins. You can use it with, I think, the Makey Makey, and you can use it with, I think, the Microbit. So it actually has interfaces to that stuff, so you can make a game controller or do those kinds of things.

Do they have transitional education materials like okay i think microbit does yeah you've you know scratch now here's how to learn i haven't seen that from the scratch project or really anywhere anywhere around that people tend to say oh you know my kid picked up python next or my pick to kid picked up javascript um those those tend to be two areas. Or people jump into things like Unity or the actual professional game engines or game design studios

where you're not so much programming the underlying game anymore like you have to do in Scratch, but you're doing the artwork or doing the game design or doing the scripting or the in-game mechanics, but you're doing the artwork or doing the game design or doing the scripting or the in-game mechanics, but you're not doing the game engine itself anymore. And so some people gravitate to different places.

What is the... I had a joke about going from Scratch to that graphical language that I want to say is national instruments. Oh, LabVIEW. LabVIEW. It seems like LabVIEW is the obvious successor to Scratch. I mean, like, honestly, so, you know, let's back up. So the very first thing that my kid did ever, actually, no, I forgot about this.

Thank you. So the very first thing I think my kid might have done with programming is i have an old lego mindstorms kit um it's probably like 10 years old or 12 years old at this point and lego mindstorms that interface is actually done by national instruments or was done by national instruments yeah yeah ni national instruments they partnered with lego and so the original mindstorms um ui which is a graphical base what was done by by ni and so it i mean your lab view thing is a joke but it's not a joke because it's the same the same company at the very least and we started we did that and my son you know we played with that and we made some made some sets and you know was able to control it um so that's actually where where he got to start i

guess even before this um i will say that you know as a as a professional programmer who's used to text-based programming languages it is very very inefficient or it seems very inefficient to have to like drag these blocks around you know if then else and you can't copy paste in the same way you can with other things and there's no version control there is no version control how old do you think he'll be when you introduce him to version control he already knows enough to uh to save projects as he's working sometimes if he's going to go and like try the next tutorial he'll save off uh save off like version one version two sometimes so at the very least, there's that. You're teaching him to be an electrical engineer?

That's true. No, he's teaching him to be any sort of creative worker. Yeah. Put the Photoshop, final, final, final. Final, final, four, final, really final. Yeah. One of the other cool things about Scratch, though, is that Scratch is a platform. They have made it... If you want to share your Scratch project on the Scratch website with anybody,

then it is, open source is the wrong word, but you share it and people can see the running program and interact with it. And then they can click see inside and then they can remix it, meaning make their own copy of it. And then they have their own copy of what you did. And they can go in and see it and poke at it and see how it's done. And it reminds me very much of the web and HTML, circa 97, 98, where you could do view source. And there wasn't much magic beyond that. So you could go and learn whatever you wanted if you were patient enough to go see how someone else, by seeing how someone else did it. So Scratch has very intentionally made that their default.

Like that is if you share stuff, other people can see it. And that's by design. And that's just wonderful for remixing and sharing and just passing along creativity. That's cool. Well, do you have anything else on this topic you would like to share? I think that's probably it it's i see people you know a hacker news scratch will come up or grab you know programming languages will come up it's specifically block based typically for kids and very i'm assuming well-meaning people but geeks will say oh it's it's bad to to you know teach kids these bad

habits that they'll learn to block based languages because then they don't have XYZ features or then they learn sloppy habits or it warps them somehow. These are people who have an idea of what being a professional programmer means and what skills they're needed. And they think that doing something with scratch with this you know not quote-unquote professional programming environment will will damage or will hinder the later learning of people and i you know maybe there's data on that maybe that's objectively true but i find that extremely hard to believe

just seeing the amazing creativity that comes out of kids. My son is part of a scratch club with a bunch of other kids from all over the place, and they meet on the weekends. And it is amazing to see what, you know, six to 12-year-olds do or five to 13-year-olds do. And they are expressing themselves. They're getting this, you know, little dopamine hit as they're making stuff and showing other people stuff. And some kids go deep into the art and some people make stories and some people make games. And I see nothing but upside there. And there's nothing in it that I think prevents future learning. I think it inspires kids to be like, hey, I can do cool stuff with a computer. And, you know, I'll learn a little bit. I'll get tricked

into learning a little bit of Boolean logic on the side. But, yeah, I see it as just a positive. There's no way to do that. There's no way to do education without making things simple and building on it, which necessitates learning sometimes what people consider some bad habits. Like, oh, yeah, you did it that way, but that was the simple way, and here's a little more complex way. I mean, we all have to do that.

I know that quantum mechanics is true, but I'd never use it in my daily life. I'm just saying the simplifications are important. You're typing on a quantum mechanics machine right now. It's physical. But do you... Sorry. Do you have one of those new quantum computers at home there? No, it's how semiconductors work.

I know. Doesn't matter. I understand. But you don't start kindergarten with wave theory. For good reason. Do you want first graders making nuclear weapons i'm not going to answer that it's all for our own good yeah i mean it's some element of gatekeeping i'm sure it's some element of you know back in my day we had to learn with the commodore 64 manual

and that was good enough for me i'm sure there's plenty of motivations for it but yeah i i'm pretty sure it's, it's just all upside. If people can learn whatever, whatever they want. The other nice thing about scratch too, I think is that, Hey, I'm sure some kids are going to come at scratch and things like it and bounce right off. Cause it just has no appeal for them. And that's, that's fine. Like that's great. There's no harm in having tried it and being like, this is not for me. Right. There's there's plenty of there's plenty of parent. Yeah. Parenting books and most parenting literature and other things basically make it sound like there is only one way to sleep. Train your child. There is only one way to potty train your child.

There is only one. There is normal development and then there is abnormal development and it acts as if it acts as if you know we have we have far more control and agency than we actually do and so i think this spills over into a lot of non-parenting stuff too but look some kids are going to like it some kids are going to hate it and if they can try soccer and scratch and flying kites and running and cooking then they'll get to figure out what they like or what they don't like hopefully at an an earlier age, then you or I was exposed to programming or pretty pictures on the screen. You mentioned that he's part of a club that's five to 13. That's an age range that I don't think of kids mixing in. Yeah. Yeah. This, this is a group that we found, we found kind of like-minded uh folks on facebook actually and

so these people are all over the country um and it was just kind of an open invite like hey show up if you want to do this and so the kids do that every you know every once a week on zoom and uh yeah it's a pretty good age range it's it's all random a couple. A couple of parents in the group organize it and run it. And they are doing amazing work to corral five to 13-year-olds and get everyone playing nice together to help kids' problems and let kids share what they want to do or share what they want to share and keep everyone from talking over each other. Yeah. All right. Well, that's about all the time we have. I have this other topic here

about the Joel test. Let's see if we can do the 12 steps to better code in less than six minutes. Go. All right. The Joel test was written by Joel Spolsky, who was a pretty influential, you know, early internet geek company founder. And he made Fog Creek software. And he also was the founder of one of the founders of Stack Overflow, should you work at a company?

And it's 12 questions that you can ask a company when you're interviewing to say, should I bother working here? And if you just Google the Joel test, you'll come up with it. But it's, do you use source control? Can you make a build in one step? I'm sorry, I shouldn't make you go this fast.

We should actually talk about this. Oh, I was going to go. No, I know. And I totally set you up for that. But now I'm saying slow down. Oh, I was going to go. No, I know. And I totally set you up for that. But now I'm saying slow down. Oh, okay. Unless you really do have to leave in like five minutes. No, no, I've got time.

It's the internet. Time is a construct. Okay, so Joel, good introduction. And then these are the questions you ask before going to a company. Because if the answer to these are no, you need to wonder if this company is, I don't want to say on the level, is a if a company is not a software company, then you want to make sure, you want to make doubly sure that these questions are answered in a way that you're happy with, as opposed to a software company. You want to see, do they value what I do? Am I going to be set up for success at this company? Or is this a hack and slash type of a programming shop and they're just going to burn through me as I burn out?

Okay, so the first one is, do you use source control? That's right. That is the first one. Which, I mean, can you imagine? Follow-up, is it RCS? He actually mentions CVS, because this is from 2000. And believe it or not, there was a time before Git, and believe it or not, other previous version control systems actually worked. I know that people hate them, and they will no doubt have valid concerns about them.

But yes. SVN forever. SVN is great. Look, I still manage all of my.csh,.hrc,.bash,.rc files in a RCS directory that I leave in my Dropbox, all right? RCS directory that I leave in my Dropbox. All right? RCS. For those who don't know, RCS was the... OG. It was predated CVS.

OG. And it was very simple. But yeah, that was the first source control I used to. Have you ever gone to a company that didn't use source control? I have not. I have. I know of many companies that didn't use source control? I have not. I have. I know of many companies that didn't. You have.

What happened? Are they still in business? Day one, install source control. Does it count if you were there before the company had software and you were the person who set up the source control? So technically, no, they didn't have source control. Mine had software, but not source control. And they had many directories.

Many, many directories. I don't think I've done that either. Okay, so the second one is, can you make a build in a single step? Push-button builds. Push-button builds. And this is basically, how easy is it to do that? Because if it's not easy, it will break every single time. And if it's a series of 37 different steps

that you have written down on a couple of sticky notes in your desk, you're gonna screw it up. And then if you're out sick, well, then ain't no one can do it right. So basically it's a forcing function to say, look, you've got to have a single thing you push, and then the build must get out the door. And it means that all, you know, I'm reading through his stuff now, like all the if-devs get compiled the right way.

All the things that need to happen, happen. So that you can hand it to any old intern, and it works. I definitely have some where you can't do the final manufacturing build without some special hand waving but that's because there's security involved and not everybody has access to the keys um and i guess i have been places where you had to at least do two or three steps yep yep i mean with the manufacturing build stuff then i i you know ideally you would have two different builds that you can make in one step where one step is the well i should say one build is the dev build which you can actually build everything because

maybe you don't need you know don't need the secret keys for that one or maybe you just have a developer you know a single developer key that all your developer stuff works on. And then you have everything that all the artifacts are created via another build step that are then, you know, whether packaged or signed or whatever it is you need to do that requires the security hoops to jump through. Hopefully that security hoop is one more step and not seven steps. And it's in a script that's checked into revision control and not written on a wiki page or written on a sticky note i will admit to the wiki page having happened as recently as 2003 as recently as 2003 oh wait a minute i'm sorry 2013 okay i was gonna say 20

years ago it's past the statute of limitations. You're fine. Time travel. 2013 is coming up on. Yeah. It was coming up on. This should be done with the script, but I hate writing scripts, and I'm sure if I do this, somebody else will come and fix it. Yeah.

Which is rude. Any documentation is better than none. Any documentation that's computerized is better than the sticky note in your desk. As long as it's revision controlled. Okay. Number three, do you make daily builds? See, two and three, this can you make a build in one step and do you make daily builds. Continuous integration servers with build on commit, they solve this problem yep absolutely absolutely this is again

this is 2000 so this is 20 almost 23 years old at this point so they're definitely there's a little bit of aging here however the the whatever time period you're in 50 years from now you still you still want to make sure the company actually and the software gets built on a regular basis gets tested on a regular basis and gets tested on a regular basis, and gets as close as you can. Like I realized in the web world, you can actually just click deploy. In the physical hardware world, it's harder to just click deploy. But if you can get it to just actually deploy to your, you know, your dev robots or your dev boards around the building, then go as far as you can go to make it really CICD.

Okay, number four. Number four. Do you have a bug database? I don't know. Is this common? Do people not have bug databases? Do people just use Excel spreadsheets? Do people just use stuff in their heads?

The company that didn't have version control didn't have it. This is more common than not having version control, yeah. But I think I've only been to really small companies that don't have it. It's more common than not having version control, yeah. But I think I've, I don't, I've only been to really small companies that don't have bug databases. Yeah. Yeah. And it's because it's only one or two engineers and they're at the beginning of the project

and. And everybody knows what's wrong. And, I mean, don't we have to write some code before we have bugs? No, it turns out you have a giant bug. Right. Your code doesn't do anything. Jira ticket number one. Exactly.

Make product. Make product. Done when product ships. All right. So far, these are all applicable still. Yeah. Yeah. I mean, they look a little bit different, right?

They have a little bit of a patina, an aged patina on them, but I think they still conceptually hold together. And, I mean, this whole bug database, if you're using GitHub, the answer is yes, you have a bug database. Or Bitbucket, or many of these have bug databases that are just part of version control. Bugzilla's still around? I used to use that. Yeah. Is Bug's still around? I used to use that. Yeah. Is Bugzilla still around?

I don't know. I used it as recently as 2013, actually. In 2013? Was this some sort of cutoff point? Maybe we were at the same company, Alicia. No, 2013, 2014, I think we had Bugzilla. Yeah, I think 2013 is when Git finally took over the world completely, and then all the ecosystem around Git, the Jira and GitHub and GitLab and all that stuff sort of, I mean, because yes, these are still applicable things,

but it's gotten a lot easier to kind of just, okay, I'm going to be in the Git universe and therefore I get continuous integration maybe. And source control tracking and bug issue tracking and all that stuff for free. Not for free necessarily, but all together. Yeah. Six.

Well, actually, we're still on four. Four? What? In the quiz, the 12 steps. 12 steps? Sorry, the 12 steps. 12 steps. Sorry, the test.

It does specify that a bug database has to have steps to reproduce the bug, the expected behavior, the observed buggy behavior, who it's assigned to and whether or not it's been fixed. That's not the bug database. That's the bug reporter. But for every... The following data for every bug needs to have... Every bug needs to have

these pieces of information. And that... That's never happened in the history of computing. I mean, I try to write bugs that have the repro method and the expected behavior and the observed

behavior, and I am shocked at the number of developers who don't put in that information. Yep. I feel like you should get points just for including the word repro in any bug report. That's like half of it right there.

Repro can't. Can't. Repro. Occasionally. in any bug report like that's that's like half of it right there repro can't can't repro occasionally i have a bug right now i have a bug right now that i believe i have fixed at great toil to myself but i have not seen it happen all i have is a screenshot from somebody else from two months ago where they said this doesn't look right so you get to imagine what could have caused the screen to look like that and then so now i have other people at the company saying hey i've been asked to qualify this how do you reproduce it and say i don't know go talk to this person who set the screenshot yeah and then yeah yeah reproro instructions are gold. It's like feedback.

It's gold. Sometimes if you can get them, they're great. If you can't, eh, yeah. This is not one I would eject a company over. Besides, you're not going to be able to see this. Well, you can ask. You can ask, you know, tell me about the last 10 bugs you have and sometimes sometimes sometimes companies like i know i've been a company where there is a constant pressure to listen people we waste everyone's time if we don't have repro instructions and it's one thing if you can't repro it because it's a weird heisen bug it's another thing if yeah but it's annoying to write

down the seven steps well guess what like we're all adults here please write this down so we can have hope of fixing it you know what else is annoying the bug yeah okay so numbers five is what you ask during your interview when they say do you have any questions for me and you say so do you fix bugs before writing new code yeah this this one this one is is the toughest one to talk about i think because i don't i've never worked somewhere that fixes all bugs before writing new code not realistic oh it's totally i don't think this one belongs or i don't think this one is a good test of anything i mean if if the company never fixes bugs then then yes, that's a problem. But there's something called, you know, priorities. Yeah. Yeah.

Now, so one of the things that I absolutely loved about Joel and his writing is his writing was, I'm pretty sure, intentionally provocative. Right. And so he has written 12 questions, which are, I'm going to say a little tongue in cheek. I don't think, I think he means each one, but I, you know, he's not, I don't think he would actually say a company will burn to the ground if they don't fix all bugs before writing new code. And he he's, his prose is excellent. Like the books, Joel and software and more Joel on software, collect a bunch of his blog posts from probably the early two thousands. And they're, they're both well worth, well worth reading. They're actually a great book the early 2000s and they're they're both well worth well

worth reading they're actually a great book club book for work because they're not super technical but they they they have great statements in them that are provocative and that you can have great discussions around i think like should we fix bugs before writing new code well his point is the earlier you fix a bug the faster and less expensive it'll be to fix that bug. So if you write a bug and you fix it two seconds later, okay, your head still has all the context necessary to fix the bug because you just created the bug. You just noticed the bug. You just fix the bug. Bing, bang, boom, you're done. I mean, for some bugs, you know, you wait a week and your memory is a bit fuzzier. You wait, you know, a month and you shipped the code, then suddenly you have to

somehow page swap in, you know, a month old version of your memory, or maybe you're not at the company anymore. And now other people have to figure out what you were thinking a month ago or six months ago. And so basically, you know, earlier is cheaper in terms of bug fixing. So I think there's a good discussion around this. That doesn't have to be like, literally, you don't write any code until you fix a bug. But what is, what's the intent? What's the intent with how we prioritize bugs versus new development? I think is a great conversation to come out of this question. I think sometimes it's hard to figure out what's a bug and what's a feature.

Some of the bugs I get are basically features I'm not done with yet. And so those don't really count. I can't write those before I have to implement the feature. The reason this thing doesn't show on the screen is because we haven't written the driver to talk to the device that gets that data. That's not a bug. Yeah, that's like a development stage expectation problem. So, yeah, that one.

Although, I mean, for these, there are 12 questions, and nobody expects 12 yeses. Lower than 10, and it's a little worrisome. And lower than 5, you should be questioning what you're doing. Yes. Okay, so number six is another one a lot of people are going to laugh at. So seven, wow, we're getting into this section of nobody. Okay, number six is do you have an up-to-date schedule?

Yep, and do you have a spec is the next one. I think maybe we can do two for one here. Both of them I feel like most programmers will laugh at. And in the days of Agile, I mean, these are both definite no's on purpose. That is true. That is true. Although I'm sure Agile people are probably screaming at us right now because that means we're not doing Agile right. Which I feel like is what most agile practitioners love doing

most is telling you you're doing it wrong um not that i'm not that i'm biased or anything um yeah so do you have an up-to-date schedule the the thing that i like about this is that he you know what is his quote his quote his program is notoriously crappy about making schedules it'll be done when it's done. They scream at the business people. Now this schedule is a engineering driven schedule. This schedule is engineers are saying, okay, here's the work that you want me to do. I will have it done in six weeks. That, that is what, that's what I think. I think that's where he's coming from on this one. And I think his stance was basically it's irresponsible as a, as a professional software engineer to not have a schedule because the business needs to know when the code will be done.

Now, does this mesh with agile? Probably not. But I've always worked on projects that have schedules that need to hit deadlines because you run inside a business. Not I've just never worked in the web world. So maybe agile is easier. I don't know. But I think that's where he's coming from with the schedule and with a spec you know a spec is a nebulous term but like do you do you know what you're building or will you just know it when you see it and does this i haven't read this in a long time and i don't have it in front of me is spec the description of the software you're building, or is it the requirements, or is it both? Because there's different things.

It's the design stage document of what you intend to be building. Because I think it's a bigger red flag when there aren't some requirements. Yes, yes. Spec indicates I know how you're going to solve, how I plan to solve this. Requirements are... What am I solving? Are the business input of what am I trying to solve?

Yeah, I think this one is more the sort of, I think he calls it, what's he, I think he calls it functional specifications. He has a whole series on this. And it's what should should be doing like how how will it work it's the code in prose yeah i don't think it's even that that level i think it's more like all right how how is it how what is it supposed to do you know how is it supposed to be backwards compatible and i'm looking at the article now um what are the file formats

it's supposed to support it's basically what it's supposed, what are the file formats it's supposed to support? It's basically what it's supposed to do. I don't think it's supposed to be, you know, here's the code in prose. I think it's a level above that. But there's two different things in it. There's what's called a PRD or an MRD, product requirements document. Is that a spec? I don't know.

We can get a little fuzzy there. I mean, usually places, there have been places that have been pretty loose on this, but usually there's some stuff. Yeah. I don't know, wiki or Confluence. But sometimes it's just one person. And it's hard to keep up to date because things change. Yeah. So it depends on what kind of company you are.

If you're a medical device company, you better have a spec because the government would very much like to see it. No, no, it's all just a prototype until we're done. And then we'll write spec post facto. Anywho. Number eight, do programmers have quiet working conditions? This has always been my favorite. This, yes, yes. This is basically realizing that noise and interruptions

causes people to get out of the zone. And you are literally paying people hundreds of thousands of dollars a year, in some cases like Silicon Valley salaries, to produce, hopefully, code for you. And by interrupting them every 15 minutes with sounds around the office, you're literally just costing yourself money. Yeah, well, I mean, this has been discussed at Infinitum,

but I think Dennis brought this list up at one company we were both at together and tried to show management. And I think it got us an office for three of us that we could close the door for. Yeah, it did share. Because earlier the company had decided, you know what would be cool? Is if we, for camaraderie, we intermixed departments a little bit more. So let's put some of the engineers interleaved with the sales and marketing people. The people who were on the phone all day?

The people who were on the phone all day with their conference phones turned up to a thousand and shouting in their phones so so yeah it was uh it was not great but yeah it's it's i yeah people need to be able to think that the ship the ship has sailed definitely with you know the open office plans of of i was gonna say now but really it's more like yesteryear. I'm not sure. With remote work, being working at home, being more work-having, then, you know, some of us can hope to have this happen some. Okay, number nine. Do you use the best tools money can buy? This one kind of shows its age.

I mean, if you're talking about hardware, then that's applicable. There's a lot of good tools that are free now. The point here is if your company is providing you with old computers and slow compilers, you're going to go surf the web. And every time you do that, you're going to lose focus. And so you should have the debugger. You should have all of the tools you need and they should work. If you're using OCD with an off-the-shelf, random,

slightly buggy JTAG module on top of... Old Smokey. On top of Old Smokey and a GCC version that's five years out of date because that's the only one you know how to use. Everyone uses GCC that's five years out of date. That's true. You can't get away from that one. But yeah, I mean, the thing, it's the old penny wise, pound foolish, right?

Because we're going to save a bunch of money on these computers. So we'll get the thousand dollar laptops that are really slow. And then amortize that over, you know, 10 engineers wasting a month, a year of their time or more. And you lose that, you lose that savings pretty fast. Yep. Yeah. Whenever I read lists like this, or, you know, any of these kind of pseudo authoritative

posts by internet gurus, I always ask myself, why did they write this? And one of the reasons I think Joel wrote this and he would probably agree was to, is it's kind of an advertising tool. What he's also saying is, Hey, I run the, he ran this company called fog Creek and their whole thing, or one of their things was everyone gets a private office with a door that shuts. And he actually went to great lengths to show how in Manhattan, in Manhattan, real estate, skyscraper, real estate, they could make this, um, financially a good idea and financially viable. And they actually got some architects to design some kind of cool like spaces. So everyone got windows and a private office and it wasn't, it didn't break the bank. So, you know, by saying, do programmers have working, quiet working, just do you use the

best tools? That's sort of advertising to prospective software engineers. Hey, this is a place that values you, that realizes that you are the way that this company makes revenue. And we are paying you to that end. And we are going to spend other money to make sure that you get the most value out of your time or we get the most value out of your time and attention so i think there's there's the advertising aspect here too but he does have a highlighted uh sentence here about top-notch development teams don't torture their programmers and i've definitely been in some development teams that seem to think that torturing their programmers is part of the fun of running a business.

Yeah, yeah. Not places you should stay if you can help them, right? My profile place is doing that right now. Next one. Number 10, do you have testers? This one is interesting. I'm not sure if this one's aged well or not. I mean, you have software test organizations

or software quality organizations, or maybe you call them DevOps or whatever. One tester for every two to three programmers. Right, that's his ratio. Wow. I've been in that situation, and it is wonderful. That's true. I mean, LeapFrog had the best testers.

But I haven't had a tester in a long time. Do we have... I'm not going to say because I can't remember well, but I'm trying to think. The last time I interacted with a test organization was one of those small companies where we had, you know, we had

at a couple places, we had the tester sitting with us, same group of cubes at the same office, and we talked back and forth during the day. It was great to have that kind of function integrated into the team rather than be something across the building. It's like, okay, I finished my weeks of stuff,

and here, go test it. Yeah, you throw it over the wall kind of thing. Having the people who are going to test your code like sitting with you as you design the code um you know i mean frankly if you can ask okay here's a new feature i need to design or here's a new you know thing i need to add how will i know it's working how will we test it you add that up front and it's going to make it it'll make it easier to test for one thing and you'll probably uncover a bunch of requirements or assumptions that you had that maybe aren't valid or you know gaping holes in your understanding because until you can define until you can tell someone okay how will you know if this thing works or not you probably don't understand it well and having a

tester there helps to force it's kind of a forcing function to help you ask that question up front and by the way actually to do the testing and tell you when you're wrong and let's face it engineers are very bad at testing their own work yes oh and he's also saying that testers cost one-third the price of engineers that's and i have to wonder about that i don't think that's depends on the test what i would pay them yeah i yeah that that that when i saw think that's... Depends on the tester. It's not what I would pay them. Yeah, when I saw that, that's the part I'm thinking, was that true in 2000?

I mean, that's a relatively unskilled tester. Yeah, that sounds pretty manual. That's not somebody who's going to review your code. Yeah, I don't know what he's talking about with that. That's very strange. But, I mean, the testers I had about with that. That's very strange. But, I mean, the testers I had at LeapFrog didn't review my code, but

they sure, I mean, I definitely, every time we finished a toy, I took them out to lunch because they did so much good stuff. A third is, yeah. That's, that's... Okay, number 11. Do new candidates write code during their interview

would you hire a magician without asking to show you some magic tricks of course not i love that example yeah but i'm not hiring a magician so that's why you want to ask new candidates to show you a magic trick during the interview exactly yeah i i have extremely mixed feelings about how to interview people. Now that more people have GitHub portfolios, this is a little harder. And I guess the whole, it takes 20 minutes to do basic coding just to make sure you can is

important. But the take-home tests that last four to eight hours, those are just wrong in my book. Yeah, I'm not a fan of that. I will say that I am still surprised how many people can't do FizzBuzz when given an hour and fizzbuzz similar questions that's where i sit with the thing it's like ask something simple and if they get it then great and then maybe you can ask something more intermediate but i've just sat through so many interviews where it's like okay here's this thing with complicated you know it's got dependencies like at fitbit when i was interviewing ios developers and i kind of was a fly on the wall interviewing iOS developers. I had a co-pilot who

actually knew what they were doing, and I was still learning. But I mean, the kinds of questions they were asking were like, okay, I've got to understand huge things about maybe frameworks that I haven't encountered yet, because they just happen to use them here. I don't know. I just think it's so lost in can you do what we're doing right now, this instant, on our code base. But that's not what you're looking for. No. Because you weed out a whole bunch of people who could pick it up in three weeks.

Yeah. Interviewing is hard. There no like magic formula to it but you you want to you want to have some basic level of you know software engineering competence um but yeah they're not going to be they might be productive day one but you're going to have a bunch of assumptions and your code base is probably five years old or 10 years old and it's not fair to expect someone to come in off the street and understand the random framework you have. And if they do understand it, then that's telling you that they happen to use that framework.

That doesn't tell you they're a better software engineer than someone who hasn't used that framework. There's that, and then there's also coding is not something you do in front of a whiteboard with somebody tapping their pen impatiently waiting for you to come up with the answer in 10 minutes. Yeah. It's a completely different milieu. It's not how you do things. But this test, this test is asking not, the test is not saying any, these are the questions you're asking a company that you might want to work for.

Yeah. The only company that I went to work for that did not ask me a coding question was the worst company. I lasted six weeks. I've been asked coding questions at probably 50% of the companies I've worked for full-time. And so, I mean, not since I've been a consultant. That doesn't count. No, I know. So you've worked at companies where...

But I knew people. See, I was brought in. You were brought in because people had already seen your code. Yeah, yeah. I mean, it gets harder the more senior you get, too, because there's been a lot of times I've interviewed people who have resumes longer than a football field, who've obviously done many things, and they get miffed.

Yeah, I don't get that. I've seen people get miffed, and I have a nice little speech about how this is just what we do, and I'm sorry if you can't answer it, that's fine. What about the questions that Shototspotter asked me? I got miffed at those. Because they were stupid questions. Okay, all right, just checking. I don't care how many pluses you put after the I.

After you've put two and you haven't stopped, the answer is this code sucks. I don't care what it does. Did they ask you a post-increment with 18 pluses? Yeah. Is it legal? What would it do? Yeah, and I said I'd fire you.

That was my answer. I actually said that in an interview, and I think that was when I lost the position. Yeah. Which is fine. It's for the best. Okay, the last one is, do you do hallway usability testing?

Yeah, so he's coming from the web world here, so I'm assuming. Yeah. I hope it's not a firearms company. I mean, some of this is the dogfooding. Yeah. Do you ever actually try your product? And do you ask other people if it makes sense? Yeah.

I'm trying to think. Yeah, let's see. I know, I think it's good. I mean, if it's feasible, it's good. So, like, consumer products, that's certainly something you want to do. Because, yeah, I mean, A, it's fun to use your own product. And B, it's a great way to find problems. Medical devices gets a little tricky.

But I did work at one medical device company that had an in-house clinic where you could go have the device used on you if you wanted. I never did. And then there was the networking companies and we did those, I mean, dogfooding. I always thought dogfooding was invented by those companies because they were always like, okay, we've got a router that's

basically working, put it in the, put it in the corporate network. See what happens. Yeah. But I think it's important. It's just hard to, it's hard to adapt sometimes depending on the product. Usability, I think is the big one. Like, I don't think some of the companies I've worked with lately have done good usability. Sometimes it's just a matter of taking a couple of screenshot printouts and saying, which button would you press here? What do you think, if you pressed this, what do you think would happen? And I remember, again, at LeapFrogrog they would have the looks like version of the toy

and a voice artist in there and the human would push a button and the voice artist would do whatever that was supposed to happen and those were the best that's funny that just sounds fun yes i did go to microsoft once and uh and they paid me to do some usability testing. I think it was for a phone. Maybe it was like the sequel to the Sidekick or something. I don't remember what it was. It was some consumer device like that. And they just had this pamphlet with like a three-ring binder.

And so I'd be pressing this piece of paper. And they'd go, okay, Okay, flip, flip, flip. Okay, now you're here. Choose your own adventure usability guide. Now, of course, you could mock something up a lot easier, I think. Not nearly as much fun, though. I want to test stuff with a voice artist in the room and then just tell them to improv it.

That would be fun. Did they dress up as the frog? No, they did not dress up. And yes, there was some improv because people always do things you don't expect. They don't dress up as the frog. I'm not interested. You must test your product

with house cats riding around on top of it, like regardless, like everyone knows that. That's just a tenet of the industry. All right, those are the 12. I think it has held up mostly, and you have to decide which of these things are important for you. I think there's some missing ones these days. What do you have that's missing?

I'd have to think about it, but I'm just thinking of recent events and companies and things and other stuff you probably want to watch out for. Things like how long do you spend with your butt in the chair each week? Yeah. I think, is the CEO a lunatic? It just may be a lunatic you're looking for. Nice.

I love that phrase whenever that word comes up. I'm all about random. Well, actually not random. I'm all about stupid associations. I think the Joel test, and honestly, again, like his couple of books and his writing is fantastic office place fodder to kind of talk about and get people's opinions and discuss, discuss hey do you have a spec do and then everyone will complain for a little bit but then it's okay why do we want a spec what's the important part of a spec and you have conversations like that and no we're not going to have a full you know completely nicely you know typewritten spec that fully defines each everything we're going to do but maybe we can surface our frustration enough to

say you know what if we just had this one thing, then that would make our lives 20% better. And so maybe out of that conversation, you come up with some new subspec or some part of a spec that, you know, we should start doing that. You know what, we should start triaging bugs differently. Because we know that if we put off bugs like this, it bites us every time. So you know what, let's take a week and let's go after those. Whatever. I'm making this stuff up, obviously. But I think there's value in answering these questions and talking about them with your colleagues. Even if some of these questions aren't 100% relevant as written, I think the thought exercise is good. I agree. I think the thought exercise is good and worthwhile.

Some of these things may be more important to other people. I do know people who don't care if it's noisy when they program. I don't know how they work, but if that's fine with them, that's fine with me, that it's fine with them, just as long as I don't... I love that for you. Modems. And...

I was hoping we might hear some of that acoustic modem on this interview, but I guess not. No. And for things like specs, you can write your own. When somebody gives you a feature or a bug, you can write your own little mini spec and see if anybody likes what you're planning. Specs don't have to come from other people. Yep, you absolutely can do it. And if you write it and if you put it on a wiki, and then if you have someone who's in software quality or test, you say, hey, I wrote this thing that describes what my feature is supposed to do.

Is that helpful? And they may take you out to lunch. Thank you for that. Right? All right. Well, it's been really good to talk to you. I hope the kid enjoys learning how to identify which companies he's going to work for. Yes, of course, of course.

It's Nintendo, by the way. He's going to work for Nintendo. That is the goal. And do you have any thoughts you'd like to leave us with? I have this quote that I have been, I learned this quote earlier this year, and I've been using it basically every week. And the quote is,

the biggest problem in communication is the illusion that it has taken place. And I'm going to say it one more time slowly because it took me a while to parse it. The biggest problem in communication is the illusion that it has taken place. So it's wrongly attributed to George Bernard Shaw, according to quote investigator, but whatever. Basically, when you talk or think you have communicated, frequently you haven't. And the message that you intended the person to receive was not actually received at all. And so it's a good idea to circle back and make sure that people heard what you wanted them to hear and that they can relay it back to you in a way that, you know, lets you know you're on the same page. Good advice. Our guest has been Christopher Svek,

director of software at some unnamed company. Thank you, Christopher Svek. Thanks for having me. It was fun to talk to you both. Thank you for listening and thank Christopher for co-hosting and producing. Christopher White. Yes, and thank Christopher Speck for filling in at the last minute when I had a scheduling mishap.

And thank the Patreon supporters for their support. And I guess that's it. I don't have a quote, so I'm just going to go with Speck's. Yeah, I think that's it. I don't have a quote, so I'm just going to go. You had a quote. Yeah, I think that's fine. Have a good week. Goodbye.