Transcript from 436: 20 GOTO 10 with Chris Svec, Chris White, and Elecia White.

EW (00:00:06):

Welcome to Embedded. I am Elecia White, alongside Christopher White. This week we are going to talk about programming kids. Wait, that did not come out right. Programming for kids? Programming of kids? Programming by kid? Something. And we will probably cover the Joel Test.

CW (00:00:24):

The Jewel Test?

EW (00:00:24):

Joel.

CW (00:00:24):

Oh. So we are not going to check diamond hardness and clarity. Okay?

EW (00:00:30):

Our guest this week is Christopher Svec, who is not a co-host of this show, but is a frequent and much appreciated guest.

CW (00:00:38):

Hello, Christopher Svec.

CS (00:00:40):

Hey, Chris and Elecia, how are you two doing?

EW (00:00:43):

We are doing alright.

CW (00:00:45):

Check back in an hour.

EW (00:00:48):

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?

CS (00:01:02):

Sure. I should say that I am not responsible for, or rather, I am responsible for what I say, but I am definitely not speaking on behalf of any company I have worked for, past, present or future. I am just here talking to a couple of good people about whatever comes up. And it is not in any way related to employers.

CW (00:01:22):

Can you declare future liability like that? I do not think you can.

CS (00:01:27):

I wonder if I could declare that I am talking for a future employer. Could you do the opposite?

EW (00:01:32):

No.

CW (00:01:34):

What if your future employer is a time travel company?

CS (00:01:38):

Mm. I bet the NDA for time travel companies is really, really hard to to write.

EW (00:01:46):

Okay. So we are going to go on to lightning round now.

CW (00:01:49):

What? I do not have anything.

EW (00:01:50):

We have no questions, so it is up to you to ask them and we will answer.

CW (00:01:54):

All right.

CS (00:01:54):

Oh.

CW (00:01:54):

No, I got them. Here we go.

EW (00:01:56):

Okay.

CW (00:01:57):

Favorite Thanksgiving side?

CS (00:02:00):

Mashed potatoes.

EW (00:02:01):

Favorite Halloween candy?

CS (00:02:03):

Mm, that is a tough one. Reese's Peanut Butter Cups.

CW (00:02:07):

Favorite Halloween costume that your child, henceforth referred to as "The Kid," has worn?

CS (00:02:14):

Mario, Super Mario.

EW (00:02:16):

What is your favorite video game?

CS (00:02:19):

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 III. My latest game that I have been playing with The Kid a ton is Mario Kart 8 on the Switch.

CW (00:02:35):

Do you know what "xyzzy" comes from?

CS (00:02:39):

Oh, yes. Which of the- Is it Colossal Cave? I think it is Colossal Cave. It is one of the first adventure games, text adventure games. I think that brought you back to the start or something, right?

CW (00:02:51):

It did indeed. I encountered this last night in a brand new video game, which I found amusing and irritating. What is your least- Oh, sorry. No, your turn.

EW (00:03:05):

What was the last nonfiction book you read and how was it?

CS (00:03:08):

Oh, last nonfiction book I read. I am reading one right now, which is- I am looking at the title here. It is called "The Way We Never Were," and it is about, basically we have all this nostalgia for the golden age, the 1940s or 1950s or 1960s or whatever. 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. I am just starting that book, and it is pretty good so far.

CW (00:03:42):

But the eighties though, those were better.

CS (00:03:44):

The eighties were solid. Eighties, and I am going to say the nineties were pretty solid too.

CW (00:03:50):

<laugh> Round wound, ground wound or flat wound?

CS (00:03:54):

Oh, flat wound if it is a fretless, otherwise round wound.

EW (00:03:57):

Do you have a tip everyone should know?

CS (00:04:02):

No, you asked this of a lot of your guests.

CW (00:04:05):

How many tips do you think this guy has? He has probably been here four or five times, and he has given all the tips.

CS (00:04:10):

Yeah, I do not have any good tips anyway.

CW (00:04:12):

What is your least favorite- Nope, that is the terrible question to ask somebody who has declared their liability?

EW (00:04:20):

What is your least favorite lightning round question?

CW (00:04:22):

Yeah.

CS (00:04:23):

It is probably "The tip everyone should know," because I feel like I do not have any. Many of your guests have great ones. I do not.

CW (00:04:29):

What is your favorite lightning round question? And have we asked it yet?

CS (00:04:34):

Mm. I always like when you have the lightning round questions for guests, where it is clear it is just for them. Especially when Elecia has, like, the Murderbot. Martha Wells.

EW (00:04:44):

<laugh>

CW (00:04:45):

I did not even know what she was talking about.

CS (00:04:47):

Yeah, you definitely had a bunch of questions in there, we are like, "Okay, you have clearly read her books," and you go geek in there. To a similar thing, Chris's question about flat wound, round wound or ground wound. These are different types of bass guitar strings. I appreciate that geeky insight into your guest.

EW (00:05:06):

Okay. So let us talk about your kid. We are not going to say his name, and if we do we are going to bleep it. Even though we offered to call him Mario, and he said, "No," I thought it would have been hilarious.

CS (00:05:22):

That is right.

EW (00:05:23):

But The Kid is how old?

CS (00:05:26):

The Kid is nine.

EW (00:05:29):

When did he start wanting to program computers?

CS (00:05:35):

The Kid, like many kids, started playing video games. We have a Switch, 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.

(00:05:49):

At some point he started to ask me, "How do they do this? He knows I am a software engineer, and I have done a lot of software, and he knows that there is code in the robots.

(00:06:03):

We have done various different online and in real life coding. Coding simulators, simulators is maybe a bad word for it, but different types of programming exercises. You know, dealing with logic, telling the TurtleBot to move, "Move forward three squares," that kind of stuff.

(00:06:25):

He seemed that, 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 is what you do, right, daddy?" And said, "Well, yeah, kind of."

(00:06:40):

So we went around, and I knew Scratch was a thing. I knew that the MIT has this graphical block language. Block programming environment, actually, it is more than just a language. We went over to Scratch's site and they had some decent little intros and tutorials, and that is how we started initially.

(00:07:03):

I do want to say that I did not push my kid into programming. Everyone, I should not say everyone. I hear many people say things like, "Oh man, every kid should learn how to code." I do not know if, 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 do not find it intrinsically interesting. So I have a lot of-

CW (00:07:28):

Well, hang on! It can be mind-numbingly boring for people who do find it intrinsically interesting.

CS (00:07:32):

That is true.

EW (00:07:34):

You heard it here, folks. Programming is mind-numbingly boring.

CS (00:07:38):

Mind-numbingly boring. No, I think it is fascinating, but as I describe what I do to normal humans, I am like, "Yeah, this sounds insane. It sounds like I have a real problem, that I sit here and type at this infernal machine."

EW (00:07:51):

And try to convince it to do what you want, even though it truly does not want to do what you would want.

CS (00:07:56):

That is right. It just wants to do what you tell it to do. It is kind of a jerk in that way. It does not want to do what I want it to do.

EW (00:08:02):

Exactly. Okay. So he found games and decided he wanted to make his own games.

CS (00:08:10):

Yep. At first it was just a little bit, he is kind of interested in it. I did not want to push it, right. I did not want to be the overbearing father. He played with Scratch a little bit here and there, but nothing too big. At some point, maybe we got Super Mario Maker. I think we got one of the Super Mario Maker games, which is these games- It is basically a level designer for 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. It is a sandbox, but it is pretty fun.

(00:08:46):

At some point he wanted to say, "Hey, how could I make my own, like next step? How could I actually make my own game?" The internet is a wonderful thing. We found a couple of videos done by DigiPen Academy, which is a- I think it is a computer science game development focused school, college, in- I think it is in the Seattle area. DigiPen, they also offer K through 12 classes. I think they have onsite stuff. They have some homeschool classes, whatever. They had this two different YouTube video series that were basically made just for my kid.

(00:09:25):

One of them- I am sure we will 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 get into and figure out what is fun in a game? How does a game get fun? How does a game not get fun? And then it lets you play with a little sandbox game they have created, to make things faster, slower, better, worse, whatever. You get to experience what actually makes a game. What does the sound do? What does the animation do? What does the actual change in the game mechanics do? Again, I feel like it was made for my kid.

(00:10:03):

The second one they had is kind of the next level. That is the Basic Game Development Series. That is a take you by the hand and walk you through creating a asteroids type, not asteroids, sorry, a space shooter kind of a game. The guy who teaches it, who does the videos actually is an employee of DigiPen. He does just a fantastic job. His name is Doug Zwick. It is clear that they understand like the theory of game design. They make games and they understand the educational aspects. Basically once we hit those, there was no stopping my kid.

EW (00:10:50):

There are a whole lot of different areas to game design. There is the artwork and the interactions and the story arc...

CW (00:11:01):

The sound.

EW (00:11:02):

Right. Which parts are interesting? And the graphics.

CS (00:11:08):

Yep, absolutely. It is actually kind of similar to embedded. If someone says, "Oh, I want to learn embedded." It is like, "Well, what do you mean? There is 73 different unique things that you could spend the next 20 years diving deep into". What happened to resonate with my kid is the coding and the game design part. Like, how does the game work, game mechanics. Those have been the bigger interests for him.

(00:11:35):

There is similar content on YouTube nowadays, where if you want to get deep into, you want to learn how to do 2D Sprite animation kind of stuff, or you want to do sound design for games. DigiPen has some content for that stuff. I am not sure if how much of it is online and free. I know they have classes in this stuff, because they teach it. Yeah, it is all over the map. My kid is centered on the programming and game design piece of it, and these videos were just perfect for it.

EW (00:12:06):

And DigiPen is a university.

CS (00:12:09):

Right.

EW (00:12:10):

So you are not randomly choosing YouTube videos.

CS (00:12:14):

Right. I was actually pretty darn wary of sitting my kid down in front of any random YouTuber, right? I had never heard of DigiPen before I basically started Googling for "kids guide to game design" or however I stumble on it. But they have proven to be trustworthy, at least in their videos.

EW (00:12:36):

How long has he been interested in coding?

CS (00:12:43):

Getting into the game stuff was basically Januaryish this year, so roughly a year at this point.

EW (00:12:49):

And he recently made a mental breakthrough.

CS (00:12:54):

<laugh> Yes.

EW (00:12:55):

Can you tell us about that?

CS (00:12:56):

Yes. This was- I am probably an annoying parent at this point, but you asked me, so I have no choice but to answer. He realized that you can use a Boolean as a zero or a one. So a Boolean in a mathematical expression evaluates to a zero or one. You can use that to multiply by another number, and then your result will basically be either zero, if the Boolean evaluates to false, or one, if it evaluates to true, times whatever number. He ended up using that 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. To see his mental model of the world open up was pretty cool, to get to hear him talk about that.

EW (00:13:50):

See, I got the extended version of that story, that involved toothpaste.

CS (00:13:54):

There was toothpaste.

EW (00:13:56):

And dribbling during discussions of binary, which I thought was awesome.

CS (00:14:00):

It is true. Great thinking happens in the bathroom, brushing your teeth, in the shower, whatever.

CW (00:14:08):

So, is using Scratch- I have never used Scratch, or if I have, I have forgotten it. Maybe it came with some sort of robot toy at some point. But anyway. Can you describe what Scratch is, and how it works? I am curious about its limitations, and that kind of thing.

CS (00:14:26):

Yeah, I was surprised. I knew very little about Scratch. Scratch is a, or perhaps the block-based language. If you hear people talking about block-based programming environments for kids, then it is probably something like Scratch. It is free, it is open source. MIT is the one that invented it, and they maintain it, and they actively develop it. It is a web based programming environment and language, that is geared towards kids.

(00:15:01):

Hang on, I am 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. The things that you manipulate in this programming environment are "sprites," which are just pictures basically. It starts off, you start a new project and there is a cat, and that cat is the Scratch cat. You can make him move 10 steps or turn 15 degrees or turn in the arbitrary number of degrees. Or you can make him move to different XY positions on the screen. So it is got basic movement kind of commands. And then it has got different ways to change the way the characters look, the sprites look.

(00:15:44):

It has 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, then triggers some other event." It has basic control blocks, you got your repeats, your forevers, if, all that kind of stuff. As well as basic mathematical operations. And, yeah, it is probably Turing-complete. And it has user interaction stuff, so I can tell where people are clicking or what keys they are hitting, or if a Sprite is hitting another Sprite.

(00:16:17):

 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 a simple game. You can record a sound. You can make unicorns appear in the screen, stars come out of their head, that kind of a thing. And it is got a bunch of basic stuff in there to get you started.

EW (00:16:41):

Okay. I have played with Scratch a few times, mostly teaching middle schoolers programming. It is really good because it is easy to get to something you can show somebody else, and be pleased with. It is 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. 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. I mean, middle school girls, it was pretty hilarious. But they were excited to be able to tell a story with programming, because it was not for them about the challenges of logic. It was about making something they could share.

(00:17:44):

Scratch is great for making something you can share. And it is really quite- You said, "Turing-complete," but it is easy and very expansive. You can make a piano keyboard, or you can make just about any eighties game you can think of. And it is not super hard. And it is a huge community, in that there are lots of them out there, and you can see their code, and everybody is sharing. It is pretty cool. So if you have not tried Scratch and you have got a kid in the six to 12 range, or even six to 15 range who is never seen coding, it is a good way to get the idea that it is not about typey-typey at your computer all day. Yeah. I think Scratch is great, except that it is a block-based language, and that is not how my brain works.

CS (00:18:43):

Yes. 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. I do not know that that is their mission statement or that is their vision, but you are absolutely right. That is what makes it very, very simple to do, and fast to do.

(00:19:04):

When my son started using it, 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, he practiced, he made little games here and there.

(00:19:24):

Then we stumbled upon a couple more books that he found to give him different techniques for doing things in Scratch. One of them is called "The Everything Kids Scratch Coding Book" by Jason Rukman, R U K M A N. And the other one is called, "Scratch Programming Playground: Learn to Program by Making Cool Games!" And there is a newer edition, a third edition of that, and that is by Al Sweigart, I think. I will give you links for this.

EW (00:19:51):

Oh, yeah.

CS (00:19:53):

So those books had even more, "Okay, here are different ways to do collision detection. Here are different ways to do 2D game platformer kind of stuff. At this point I thought, "Well, surely he has reached the end of what Scratch can do." Because okay, yes, I can believe it is Turing-complete, but you probably have to be an expert, I will say adult professional programmer, to push it more. But I was wrong yet again!

(00:20:20):

My son really wanted to make a 2D platformer, and I am thinking, "Oh my gosh, I am scared to go on YouTube and search for "how to make a 2D platformer in Scratch." But it turns out, there is a vast amount of really good content out there, where people have done just ridiculous things. Remaking every Super Mario, every NES, and probably Super NES, game 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 kid-friendly format, "Hey, here is how to make basically a Mario clone, or an RPG tile based scrolling game." That kind of a thing.

(00:21:08):

This one guy, his YouTube and Scratch handle are griffpatch, G R I F F P A T C H. So griffpatch, his stuff was just amazing. And is amazing. He puts out a video every week or two, and he goes through, again, showing how you can make basically very good Mario or Zelda or whatever types of games using Scratch, and shows how computer science topics can be used, in order to make these games. I feel like it is a tricky computer science education, that kids do not realize they are getting.

EW (00:21:50):

So when are you starting him on C?

CS (00:21:53):

Well, <laugh> he is quite comfortable with Scratch, and still learning stuff in Scratch. He knows that he can do more with other languages, but there is definitely a comfort level with he can be successful at what he wants to do right now. The adult learner in me, and maybe whatever I am, makes me think, "Okay, what is next kid? Let us move on maybe some JavaScript, so you can learn how to put this stuff on the web. Or let us get some Python or something something something." I need to stop myself there, because he is spending good quality time making different games and inventing stuff and coming up with stuff. And so I have told him, "Hey, there is other stuff you can do. C or JavaScript, whatever." But, he is comfortable where he is at and he is enjoying it. So we are sitting pat on that right now.

EW (00:22:49):

Well, it goes back to there are many different types of things you can learn from game design. Learning CS concepts, that was not even in our list, but it should have been. And platformers and how to make things fun and music and all of these things. None of those are limited in Scratch.

CS (00:23:13):

Yep. Actually Scratch has a really good simple sound editor. It has a really good, simple graphics editor. It has a really simple costume animation technique. So you can make your cat figure move by changing its, what they call a costume, is what it looks like. You can make the legs move and the arms move, and if you do that in rapid succession, then it looks like he is running or walking or whatever. Scratch makes all of that easy enough, and quick enough, so people can be successful with relatively little effort.

CW (00:23:43):

This goes back to something I think I talked about many years ago on the show, but I do not remember what the context was. I think I was talking about how I learned to use computers and program and stuff, and how in the eighties computers were far simpler than the things we have now. And you could do less with them. They could connect to fewer things. And the way you programmed them was very constrained. And...

EW (00:24:11):

You typed in things from magazines.

CW (00:24:13):

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 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. That is what you got and that is how you learned.

(00:24:40):

I think in the middle somewhere, we got to this point where computers is these extraordinarily powerful things. If you want to program them well, you get an integrated development environment. You have to learn all these things which are far too advanced for kids, in most cases, to start from. 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 does not require you to use professional tools.

EW (00:25:24):

Yeah, let us leave debuggers and compiler optimizations to when he is 10.

CW (00:25:30):

All those things existed in the eighties, but I think at some point computers became so general purpose, and for so many other things, that they were no longer for programming.

EW (00:25:40):

Oh, yeah.

CW (00:25:40):

But the early Apple II, like I said, they booted into Applesoft. This is a computer that is for programming.

CS (00:25:49):

Yep. My first computer was a Commodore 64 and absolutely. Yeah. You get in there and you do, 10 space PRINT "Your sibling is a butthead." 20 GOTO 10 and there you go. You are a programmer, right? And, if my brother is listening, I stand by that statement.

EW (00:26:07):

<laugh>

CS (00:26:07):

Chris, that is interesting because I did not actually, I had not thought of Scratch that way. But Scratch, if you go to the website, it absolutely is the Commodore 64 startup screen. Because there it is, it is a constrained environment, and you can do stuff with it in pretty simple fashion, but you can do stuff right away. I had not thought of the Scratch UI and the Scratch interface as that great of an enabler, like, this is the basics. But maybe this is the new boot screen or reset screen. I like that. I like that comparison.

CW (00:26:41):

Because yeah, 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 fell by the wayside. Now you see people suggesting JavaScript and Python, but I do not feel like those are easy to get going.

EW (00:27:07):

No. Because you need a compiler and you need to understand what a compiler is.

CW (00:27:11):

Not for JavaScript or Python. JavaScript you can just run in a browser.

EW (00:27:14):

True.

CW (00:27:14):

But it is weird.

EW (00:27:15):

But with Python, you need an interpreter, and then if you want to write a file, then, yeah, it gets complicated pretty quickly.

CS (00:27:26):

Yeah, with Scratch you do not have to know that there is a file backing all this stuff. You do not have to know, you just click save and it saves in the little folder on your desktop. Instead of Python, you have to know that there is a .py file, and you have to run it by typing some weird Python word and then space and then you get- Yeah, there are definitely a lot more hoops to jump through.

EW (00:27:48):

You said on the Embedded Patreon Slack about reading "JavaScript for Kids"?

CS (00:27:58):

Yeah. My son had expressed some interest in like, "Hey, what is beyond Scratch? Or what are different types of languages?" I do not know JavaScript at all, but I poked around at, "Okay, what does Python have? Does Python have batteries included, game development sort of a thing? Because that is the thing he is going to want do. Does Python have it or does JavaScript have it?"

(00:28:21):

So I looked around a bit and I came across that particular book, "JavaScript for Kids." It used Chrome's built-in debugger to start right away. Like you were saying, Chris, it does not have BASIC prompt, but it has got this, you open the debugger up, but you can start typing in JavaScript right away. Then it builds on some of the basic canvas libraries to start building silly games. It has an insult generator in there, which of course every kid, and probably male human, on the planet thinks is a funny thing. Yeah, it seems to hit the right audience, and it is, look, you can pick it up, you can use Chrome, you do not have to install anything, and off you go.

EW (00:29:06):

What are you going to get your son? What are you going to get The Kid for Christmas?

CS (00:29:10):

<laugh> I do not want to say that, because he might listen to this <laugh>.

EW (00:29:16):

Do you think it will be programming related?

CS (00:29:23):

I do not think so, actually.

CW (00:29:24):

You are getting him IAR, aren't you?

EW (00:29:25):

<laugh>

CS (00:29:28):

Getting him IAR. "Here you go, son. You have disappointed me. Here is IAR."

EW (00:29:32):

<laugh>

CS (00:29:33):

"And if you do not do the dishes kid, you are going to get Keil."

CW (00:29:36):

"I got you a development seat, son." <laugh>

CS (00:29:40):

I cannot afford a development seat, Chris.

CW (00:29:43):

When I was not too much, I guess three or four years, older than him, I did get a compiler for Christmas. I was very excited. Which should probably disqualify-

EW (00:29:54):

What was the compiler for?

CW (00:29:54):

Well, it was for the Apple IIGS at that time. So it was a C-

CS (00:29:58):

What was it?

CW (00:29:58):

C compiler for-

CS (00:30:00):

Oh, a C compiler.

CW (00:30:00):

That is C or C++. Nah...

EW (00:30:02):

But it was not like Borland or anything you remember.

CW (00:30:04):

No, they did not have Borland for Apple II. The Apple world was separated from all of those people.

EW (00:30:09):

Still is.

CW (00:30:10):

No it is not. They are all gone. <laugh>

EW (00:30:13):

No, <laugh> I-

CW (00:30:15):

So you can buy Borland now?

EW (00:30:17):

I just mean, never mind.

CW (00:30:20):

Is Turbo Python available?

EW (00:30:22):

I do not know.

CW (00:30:23):

I am kidding. <laugh>

CS (00:30:25):

Look, as long as he does not ask for Rust, everything is okay.

EW (00:30:29):

<laugh> No, we did not say that.

CW (00:30:32):

It is free.

CS (00:30:33):

Not under my roof.

CW (00:30:35):

You cannot even get stuff in- When I bought a book or a compiler, it came in a box. You had the box, and a big thick manual, and disks and stuff. 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.

CS (00:30:50):

Mm. I still have my Commodore 64 spiral bound programmer's manual. I think it is great. I mean it is nostalgia at this point, but it is pretty great.

CW (00:31:05):

How do you think the transition will be, when it happens from Scratch to something else? Do you think he will be surprised, annoyed, perplexed?

CS (00:31:18):

I think about this. I think it is a pretty general statement, because whenever I have to learn a new skill or something, if I am fluent in something, and if I suddenly have to go do something a harder way, or transition to a task I am not as familiar with, it is frustrating. So I am imagining he is going to be frustrated, because right now with Scratch and with relatively little effort, especially since he has been practicing it for a year, he is able to create roughly what he has in his head, because he knows what is possible.

(00:31:47):

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 am guessing it is going to be like a two steps forward, 10 steps back, for a while kind of a thing. My guess will be frustrating.

(00:32:05):

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 has gone really overboard, you can look at what people have done, look at their projects, look at their code, their blocks, and with some effort, figure out what they have done. I think typed, written programming languages, things tend to get a little more opaque, depending how they are written and designed obviously.

EW (00:32:39):

Going to have to give him something he cannot get from Scratch, like robots or physical objects. CircuitPython, controlling LEDs with an IMU.

CS (00:32:51):

So actually Scratch has plugins. You can use it with, I think, the Makey Makey. You can use it with, I think, the micro:bit. So it actually has interfaces to that stuff. So you can make a game controller or do those kinds of things.

CW (00:33:04):

Do they have transitional education materials? Like, "Okay"-

EW (00:33:07):

I think micro:bit does, yeah.

CW (00:33:09):

"You know Scratch, now here is how to Learn..."

CS (00:33:13):

I have not seen that from the Scratch project, or really anywhere around that. People tend to say, "Oh, my kid picked up Python next. Or my kid picked up JavaScript". 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 are not so much programming the underlying game anymore, like you have to do in Scratch. But you are doing the artwork, or doing the game design, or doing the scripting, or the in-game mechanics, but you are not doing the game engine itself anymore. Some people gravitate to different places.

EW (00:33:55):

What is the- I had a joke about going from Scratch to that graphical language, that I want to say is National Instruments'?

CS (00:34:07):

Oh, LabVIEW.

CW (00:34:09):

LabVIEW.

EW (00:34:11):

LabVIEW. It seems like LabVIEW is the obvious successor to Scratch.

CS (00:34:16):

Honestly- Let us back up. The very first thing that my kid did ever- Actually, 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, that is probably ten years old or 12 years old at this point.

(00:34:30):

LEGO Mindstorms, that interface is actually done by National Instruments, or was done by National Instruments. Yeah, NI, National Instruments, they partnered with LEGO and so the original Mindstorms UI, which is a graphical base, was done by NI. Your LabVIEW thing is a joke, but it is not a joke, because it is the same company at the very least.

(00:34:53):

We started, we did that, and my son, we played with that. We made some sets and was able to control it. So that is actually where he got it started, I guess even before this. I will say that, as a professional programmer who is used to text based programming languages, it is very, very inefficient, or seems very inefficient, to have to drag these blocks around, and your if then else, and you cannot copy paste in the same way you can with other things, and-

EW (00:35:24):

There is no version control.

CS (00:35:25):

There is no version control.

EW (00:35:29):

How old do you think he will be, when you introduce him to version control?

CS (00:35:32):

<laugh> He already knows enough to save projects as he is working sometimes. If he is going to go and like try the next tutorial, he will save off version one, version two, sometimes. So at the very least there is that.

EW (00:35:45):

You are teaching him to be an electrical engineer?

CS (00:35:47):

That is true. Well, it is Scratch-

CW (00:35:49):

No, he is teaching him to be any sort of creative worker.

EW (00:35:51):

Yeah.

CW (00:35:51):

Put the Photoshop final, final, final...

CS (00:35:55):

<laugh> Final, final four, final, really final.

CW (00:35:57):

Yep.

CS (00:35:57):

One of the other cool things about Scratch though, is that Scratch as 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. People can see the running program and interact with it. Then they can click "See Inside," and then they can remix it, meaning make their own copy of it. 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 is done.

(00:36:29):

It reminds me very much of the web, and HTML circa 97, 98, where you could do, "View Source," and there was not much magic beyond that. So you could go and learn whatever you wanted, if you were patient enough, by seeing how someone else did it. So Scratch has very intentionally made that their default. That is, if you share stuff, other people can see it. That is by design. That is just wonderful for remixing and sharing and passing along creativity.

EW (00:37:00):

Cool. Well, do you have anything else on this topic you would like to share?

CS (00:37:06):

I think that is probably it. I see people, Hacker News, Scratch will come up, or programming languages will come up, specifically block-based typically for kids. Very, I am assuming well-meaning people, but geeks will say, "Oh, it is bad to teach kids these bad habits that they learn with block-based languages, because then they do not have XYZ features. Or then they learn sloppy habits. Or warps them somehow." These are people who-

CW (00:37:34):

Warps them. <laugh>

CS (00:37:35):

Yeah, you know. These are people who have an idea of what being a professional programmer means, and what skills they are needed. They think that doing something with Scratch, with this not "professional" programming environment, will damage or will hinder the later learning of people. Maybe there is data on that. Maybe that is objectively true, but I find that extremely hard to believe. Just seeing the amazing creativity that comes out of kids.

(00:38:05):

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. It is amazing to see what six to 12 year olds do, or five to 13 year olds do. They are expressing themselves. They are getting this little dopamine hit, as they are making stuff and showing other people stuff. Some kids go deep into the art, and some people make stories, and some people make games. I see nothing but upside there. There is 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 I will learn a little bit. I will get tricked into learning a little bit of Boolean logic on the side." I see it as just a positive.

CW (00:38:50):

There is no way to do that. There is 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, you did it that way, but that was the simple way, and here is a little more complex way." We all have to do that.

EW (00:39:06):

I know that quantum mechanics is true, but I would never use it in my daily life. I am just saying the simplifications are important.

CW (00:39:17):

You are typing on a quantum mechanics machine right now.

EW (00:39:20):

It is physical.

CW (00:39:23):

But-

CS (00:39:24):

Did you-

CW (00:39:26):

Sorry.

CS (00:39:28):

<laugh> Do you have one of those new quantum computers at home there?

CW (00:39:32):

No, it is how semiconductors work.

CS (00:39:33):

I know.

CW (00:39:35):

Does not matter. I understand.

EW (00:39:38):

But you do not start kindergarten with wave theory.

CW (00:39:43):

Good. For good reason. Do you want first graders making nuclear weapons?

EW (00:39:48):

I am not going to answer that.

CS (00:39:49):

It is all for our own good. Yeah, it is some element of gatekeeping. I am sure it is some element of, "Back in my day we had to learn with the Commodore 64 manual, and that was good enough for me." I am sure there are plenty of motivations for it. But, yeah, I am pretty sure it is just all upside if people can learn whatever they want.

(00:40:09):

The other nice thing about Scratch too, I think, is that I am sure some kids are going to come at Scratch and things like it, and bounce right off because it just has no appeal for them. And that is fine. That is great. There is no harm in having tried it and being like, "This is not for me!" Right?

(00:40:23):

There are plenty of- 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 do potty train your child. There is only one- There is normal development and then there is abnormal development, and it acts as if we have far more control and agency than we actually do. I think that spills over into a lot of non-parenting stuff too.

(00:40:53):

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 will get to figure out what they like or what they do not like. Hopefully at an earlier age than you or I was exposed to programming or pretty pictures on the screen.

EW (00:41:10):

You mentioned that he is part of a club that is five to 13. That is an age range that I do not think of kids mixing in.

CS (00:41:19):

Yeah. This is a group that we found. We found like-minded folks on Facebook, actually. So these people are all over the country, and it was an open invite, like, "Hey, show up if you want to do this." And so the kids do that every once a week on Zoom. Yeah, it is a pretty good age range. It is all random. A couple of parents in the group organize it and run it. 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 <laugh>. Oh yeah.

EW (00:42:05):

All right. Well that is about all the time we have. I have this other topic here about the Joel Test. So let us see if we can do the "12 Steps to Better Code" in less than six minutes. Go.

CS (00:42:21):

All right. The Joel Test was written by Joel Spolsky, who was a pretty influential, you know, early internet, geek company founder. He made Fog Creek Software, and he also was one of the founders of Stack Overflow, which you have probably heard of. He wrote this test, called The Joel Test, which was a intentionally simple test to decide should you work at a company. It is 12 questions that you can ask a company when you are interviewing to say, "Should I bother working here?" If you just Google "The Joel Test," you will come up with it. It is, "Do you use source control? Can you make a build in one step?"

EW (00:42:56):

Wait, I am sorry. I should not make you go this fast. We should actually talk about these.

CS (00:43:01):

Oh, I was going to go.

EW (00:43:02):

No, I know, and I totally set you up for that, but now I am saying slow down.

CS (00:43:06):

Oh, okay.

EW (00:43:08):

Unless you really do have to leave in five minutes.

CS (00:43:10):

No, I have got time. It is the internet. Time is a construct.

EW (00:43:15):

Okay. So, Joel. Good introduction. 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 do not want to say, "On the level." Is a grown up place to work?

CS (00:43:35):

Yeah. And I think, as I read you these questions again right now, a lot of it too is, especially 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 are 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 are just going to burn through me as I burn out.

EW (00:44:04):

Okay. So the first one is, "Do you use source control?"

CS (00:44:07):

That is right. That is the first one.

EW (00:44:09):

Which, I mean, can you imagine?

CW (00:44:11):

Follow up. Is it RCS?

EW (00:44:11):

<laugh>

CS (00:44:15):

He actually mentions CVS, because this is from 2000. 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, this is CVS.

EW (00:44:31):

SVN forever.

CS (00:44:33):

SVN is great. Look, I still manage all of my .cshrc, .bashrc files in a RCS directory that I leave in my Dropbox, alright?

CW (00:44:44):

RCS <laugh>, for those who do not know, RCS was the-

EW (00:44:50):

OG.

CW (00:44:51):

<laugh> Predated CVS.

CS (00:44:53):

OG.

CW (00:44:54):

And it was very simple. Yeah. That was first source control I used too.

EW (00:44:59):

Have you ever gone to a company that did not use source control?

CS (00:45:03):

I have not.

EW (00:45:04):

I have.

CS (00:45:06):

I know of many companies that did not. You have? What happened? Are they still in business?

EW (00:45:12):

Day one, install source control <laugh>.

CW (00:45:14):

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 did not have source control.

CS (00:45:22):

Mm.

EW (00:45:24):

Mine had software but not source control, and they had many directories. Many, many directories.

CW (00:45:29):

I do not think I have done that either.

EW (00:45:31):

Okay. So the second one is, "Can you make a build in a single step?" Push button, builds.

CS (00:45:39):

Push button, builds. This is basically, how easy is it to do that? Because if it is not easy, it will break every single time. And if it is a series of 37 different steps that you have written down on a couple sticky notes in your desk, you are going to screw it up. Then if you are out sick, well then ain't no one can do it right. So basically it is a forcing function to say, "Look, you have got to have a single thing you push, and then the to build must get out the door." It means that all of- I am reading through his stuff now. Like, all the #ifdefs 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.

EW (00:46:22):

I definitely have some where you cannot do the final manufacturing build without some special hand waving, but that is because there is security involved, and not everybody has access to the keys.

CS (00:46:34):

Mm-hmm. <affirmative>

EW (00:46:37):

And I guess I have been places where you had to at least do two or three steps.

CS (00:46:42):

Yep. With the manufacturing build stuff, then 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 do not need the secret keys for that one. Or maybe you just have a single developer key, that all your developer stuff works on.

(00:47:02):

And then you have everything that- All the artifacts are created via another build step, that are then 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 is in a script that is checked into revision control, and not written on a wiki page, or written on a sticky note.

EW (00:47:29):

I will admit to the wiki page having happened as recently as 2003.

CW (00:47:36):

As recently as 2003!

EW (00:47:38):

Oh, wait a minute. I am sorry. 2013.

CW (00:47:41):

Okay. I was going to say 20 years ago has past the statute of limitations. You are fine.

CS (00:47:45):

Time travel.

CW (00:47:47):

2013 is coming up on.

EW (00:47:49):

Yeah, it was coming up on. This should be done with the script, but I hate writing scripts and I am sure if I do this, somebody else will come and fix it. Which is rude.

CS (00:48:00):

Any documentation is better than none. Any documentation that is computerized, is better than the sticky note on your desk, as long as it is revision controlled.

CW (00:48:09):

Okay.

EW (00:48:09):

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.

CS (00:48:26):

Yep. Absolutely. Again, this is two thousands, this is 20, almost 23 years old at this point. So there definitely is a little bit of aging here. However, whatever time period you are in 50 years from now, you still want to make sure the company actually- The software gets built on a regular basis, gets tested on a regular basis, and gets as close as you can- Like I realize in the web world, you can actually just click "Deploy." In the physical hardware world, it is harder to just click "Deploy." But if you can get it to deploy to your dev robots, or your dev boards around the building, then go as far as you can go to make it really CI/CD.

CW (00:49:05):

Okay. Number four.

EW (00:49:06):

Number four, "Do you have a bug database?"

CS (00:49:11):

I do not know, is this common? Do people not have bug databases? Do people just use Excel spreadsheets? Do people just use stuff in their heads?

EW (00:49:18):

The company that did not have version control, didn't have it.

CW (00:49:20):

This is more common than not having version control. Yeah.

EW (00:49:25):

I have only been to really small companies that do not have bug databases.

CW (00:49:30):

Yeah.

EW (00:49:31):

It is because it is only one or two engineers, and they are at the beginning of the project, and-

CW (00:49:35):

And everybody knows what is wrong.

EW (00:49:37):

I mean, do we not have to write some code, before we have bugs?

CW (00:49:39):

<laugh> No. Turns out you have a giant bug.

EW (00:49:42):

Right.

CW (00:49:42):

Your code does not do anything. <laugh>

EW (00:49:47):

Jira ticket number one.

CS (00:49:48):

Exactly.

EW (00:49:48):

Make product.

CS (00:49:51):

Make product. Done when product ships.

CW (00:49:55):

All right. So far these are all applicable still.

EW (00:49:57):

Yeah.

CS (00:49:58):

Yeah. 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.

EW (00:50:09):

This whole bug database, if you are using GitHub, the answer is "Yes." You have a bug database, or a Bitbucket, or many of these have bug databases that are just part of version control.

CW (00:50:22):

Bugzilla still around? Used to use that.

CS (00:50:25):

Yeah.

EW (00:50:26):

Is Bugzilla still around?

CS (00:50:27):

I do not know. I used it as recently as 2013, actually.

EW (00:50:31):

<laugh>

CW (00:50:32):

2013. Is this some sort of cutoff point?

CS (00:50:34):

Maybe we were at the same company, Elecia. 2013, 2014 I think we had Bugzilla.

CW (00:50:40):

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. Yes, these are still applicable things, but it has gotten a lot easier to just, "Okay, I am going to be in the Git universe." 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 altogether.

CS (00:51:09):

Yep.

CW (00:51:11):

Six.

EW (00:51:12):

Well, actually we are still on four.

CW (00:51:14):

Four? What? < laugh>

EW (00:51:14):

But, in the quiz, the 12 steps.

CW (00:51:23):

12 steps? <laugh>

EW (00:51:23):

Sorry.

CS (00:51:24):

It is 12 steps.

EW (00:51:27):

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 is assigned to, and whether or not it has been fixed.

CW (00:51:41):

That is not the bug database, that is the bug reporter.

EW (00:51:46):

The following data for every bug, needs to have- Every bug needs to have these pieces of information.

CW (00:51:53):

Yeah. Mm-hmm. <affirmative>

EW (00:51:53):

And that-

CW (00:51:55):

That has never happened <laugh>, in the history of computing.

EW (00:52:02):

I try to write bugs that have the repro method, and the expected behavior, and the observed behavior. I am shocked at the number of developers who do not put in that information.

CS (00:52:16):

Yep. I feel like you should get points just for including the word "repro" in any bug report. That is half of it right there.

CW (00:52:23):

Repro. Cannot.

CS (00:52:24):

You cannot.

EW (00:52:27):

Repro. Occasionally. <laugh>

CS (00:52:29):

Close. Will not fix.

CW (00:52:31):

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 does not look right."

CS (00:52:44):

So you get to imagine what could have caused the screen to look like that. And then-

CW (00:52:48):

So now I have other people at the company saying, "Hey, I have been asked to qualify this. How do you reproduce it?" And say, "I do not know. Go talk to this person who sent the screenshot." <laugh>

CS (00:52:59):

Yep. And then, yeah. Repro instructions are gold. It is like feedback. It is gold <laugh>. Sometimes, if you can get them there, they are great. If you cannot, yeah.

CW (00:53:13):

This is not one I would eject a company over. Besides, you are not going to be able to see this.

CS (00:53:18):

Well, you can ask. You can ask, "Tell me about the last ten bugs you have." Sometimes companies, like I know I have been to companies where there is a constant pressure to, "Listen people, we waste everyone's time if we do not have repro instructions." It is one thing if you cannot repro it, because it is a weird heisenbug. It is another thing if, "Yeah, but it is annoying to write down the seven steps." Well guess what? We are all adults here. Please write this down, so we can have a hope of fixing it.

CW (00:53:45):

You know what else is annoying? <laugh>

CS (00:53:48):

The bug.

CW (00:53:49):

Yeah.

EW (00:53:50):

Okay. So number 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?"

CS (00:54:01):

Yeah. This one is the toughest one to talk about, I think. Because, I have never worked somewhere that fixes all bugs before writing new code.

CW (00:54:11):

Not realistic.

EW (00:54:13):

Oh, it is totally unrealistic.

CW (00:54:15):

I do not think this one belongs, or I do not think this one is a good test of anything. I mean, if the company never fixes bugs, then yes, that is a problem. But there is something called, "priorities."

CS (00:54:27):

Yeah. Now, one of the things that I absolutely loved about Joel and his writing, is his writing was, I am pretty sure, intentionally provocative, right? And so he has written 12 questions, which are, I am going to say a little tongue in cheek. I think he means each one, but I do not think he would actually say, "A company will burn to the ground if they do not fix all bugs before writing new code."

(00:54:54):

His prose is excellent. The books, "Joel on Software" and "More Joel on Software," collect a bunch of his blog posts from probably the early two thousands. They are both well worth reading. There are actually a great book club book for work, because they are not super technical, but 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?"

(00:55:19):

Well, his point is, the earlier you fix a bug, the faster and less expensive it will be to fix that bug. Because if you write a bug and you fix it two seconds later, 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 fixed the bug. Bing bang boom, you are done.

(00:55:35):

For some bugs, you wait a week, and your memory is a bit fuzzier. You wait a month, and you shipped the code, then suddenly you have to somehow page swap in a month old version of your memory. Or maybe you are not at the company anymore, and now other people have to figure out what you were thinking a month ago or six months ago. So basically, earlier is cheaper in terms of bug fixing.

(00:55:59):

I think there is a good discussion around this, that does not have to be like, literally you do not write any code until you fix a bug. But what is the intent? What is the intent with how we prioritize bugs, versus new development? I think is a great conversation to come out of this question.

EW (00:56:16):

I think sometimes it is hard to figure out what is a bug, and what is a feature. It is like some of the bugs I get, are basically features I am not done with yet.

CS (00:56:25):

Mm-hmm. <affirmative>

EW (00:56:28):

So those do not really count. I cannot write those before- I mean, I have to implement the feature. The reason this thing does not show on the screen, is because we have not written the driver to talk to the device that gets that data. That is not a bug. <laugh>

CS (00:56:46):

Yeah, that is like a development stage expectation problem.

EW (00:56:50):

So yeah, that one. Although for these, there are 12 questions, and nobody expects 12 "Yeses." Lower than ten and it is a little worrisome. Lower than five, you should be questioning what you are doing.

CS (00:57:06):

Yes.

EW (00:57:07):

Okay. So number six is another one a lot of people are going to laugh at. So is seven. Wow. We are getting into this section of nobody. Okay. Number six is, "Do you have an up-to-date schedule?"

CS (00:57:19):

Yeah. And, "Do you have a spec?" is the next one. I think maybe we can do two for one here, because both of them I feel like most programmers will laugh at. But, at the-

EW (00:57:27):

And in the days of Agile, these are both definite "Noes" on purpose.

CS (00:57:35):

That is true. Although I am sure Agile people are probably screaming at us right now, because that means we are not doing Agile right.

EW (00:57:40):

<laugh>

(00:57:42):

Which I feel is what most Agile practitioners love doing most, is telling, "You are doing it wrong." Not that I am biased or anything. Yeah so, "Do you have an up to date schedule?" The thing that I like about this, is that- What is his quote? His quote is, "Programmers are notoriously crabby about making schedules. 'It will be done when it is done!' they scream at the business people." Now, this schedule is a engineering driven schedule. This schedule is, engineers are saying, "Okay, here is the work that you want me to do. I will have it done in six weeks." I think that is where he is coming from, on this one.

(00:58:23):

I think his stance was basically, it is irresponsible 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 have always worked on projects that have schedules, and they need to hit deadlines because you run inside a business. I have never worked in the web world, so maybe Agile is easier there, I do not know. I think that is where he is coming from with the schedule.

(00:58:48):

With the spec, spec is a nebulous term, but do you know what you are building, or will you just know it when you see it?

CW (00:58:59):

Does this- I have not read this in a long time, and I do not have it in front of me. Is spec the description of the software you are building? Or is it the requirements? Or is it both? Because there are different things.

EW (00:59:12):

It is the design stage document, of what you intend to be building.

CW (00:59:18):

Because, I think it is a bigger red flag when there are not some requirements.

EW (00:59:23):

Yes. Spec indicates, I know how you are going to solve- How I plan to solve this. Requirements are...

CW (00:59:31):

What am I solving? Or why?

EW (00:59:32):

What are the business input of what am I trying to solve?

CW (00:59:35):

Yeah.

CS (00:59:35):

Yeah. I think this one is more, I think he calls it "functional specifications." He has a whole series on this, and it is what should be doing? How will it work?

CW (00:59:48):

It is the code in prose.

CS (00:59:50):

I do not think it is even that level. I think it is more like, "Alright, what is it supposed to do? How is it supposed to be backwards compatible?" I am looking at the article now. "What are the file formats it is supposed to support?" It is basically what it is supposed to do. I do not think it is supposed to be, "Here is the code in prose." I think it says a level above that.

CW (01:00:14):

All right.

CS (01:00:17):

There are two different things there. There is the, we call it a PRD or an MRD product requirements document. Is that a spec? I do not know. We can get a little fuzzy there.

CW (01:00:30):

I have been places that have been pretty loose on this, but usually there is some stuff. I do not know, Wiki or Confluence.

EW (01:00:38):

But sometimes it is just one person.

CW (01:00:40):

And it is hard to keep up to date because things change. So it depends on what kind of company you are. If you are a medical device company, you better have a spec, because the government would very much like to see it.

EW (01:00:49):

No, no. It is all just a prototype, until we are done. And then we will write spec post facto.

CS (01:00:54):

<laugh>

CW (01:00:55):

Any who.

EW (01:00:58):

Number eight, "Do programmers have a quiet working conditions?"

CW (01:01:03):

 <laugh>

EW (01:01:03):

This has always been my favorite.

CW (01:01:04):

<laugh>

CS (01:01:05):

This, yes. This is basically realizing that noise and interruptions causes people to get out of the zone. 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. By interrupting them every 15 minutes with sounds around the office, you are literally just costing yourself money.

CW (01:01:34):

Yeah. Well, <laugh> this has been discussed ad infinitum. I think Dennis brought this list up at one company we were both at together, and tried to show management. I think it got us an office for three of us, that we could close the door for.

EW (01:01:49):

Yeah, you had to share. Yeah.

CW (01:01:51):

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 us put some of the engineers interleaved with the sales and marketing people."

EW (01:02:01):

The people who were on the phone all day.

CW (01:02:03):

The people who were on the phone all day, with their conference phones turned up to a thousand, and shouting in their phones. So yeah, it was not great. People need to be able to think.

CS (01:02:16):

The ship has sailed definitely with the open office plans of, I was going to say now, but really it is more like yesteryear. I am not sure with remote work, work from home, being more common.

CW (01:02:25):

Yeah, where we are at now.

CS (01:02:29):

Some of us can hope to have this happen some.

EW (01:02:33):

Okay. Number nine, "Do you use the best tools money can buy?" This one shows its age.

CW (01:02:41):

If you are talking about hardware, then that is applicable. There are a lot of good tools that are free now <laugh>.

CS (01:02:48):

Yeah.

EW (01:02:49):

The point here is, if your company is providing you with old computers and slow compilers, you are going to go surf the web. Every time you do that, you are going to lose focus. So you should have the debugger, you should have all of the tools you need, and they should work. If you are using OCD with an off-the-shelf, random, slightly buggy JTAG module on top of-

CW (01:03:25):

Old Smokey.

EW (01:03:26):

On top of Old Smokey, and a GCC version that is five years out of date. Because that is the only one you know how to use.

CW (01:03:33):

Everyone uses GCC that is five years out of date.

CS (01:03:36):

That is true. You cannot get away from that one.

CW (01:03:40):

It is the old penny wise, pound foolish, right? Because, "Oh, we are going to save a bunch of money on these computers, so we will get the thousand dollars laptops that are really slow." Amortize that over ten engineers, wasting a month a year of their time or more, and you lose that savings pretty fast.

CS (01:03:57):

Yeah. Whenever I read list like this, or any of these pseudo authoritative posts, by internet gurus, I always ask myself, "Why did they write this?" One of the reasons I think Joel wrote this, and he would probably agree, is kind of an advertising tool. What he is also saying is, "Hey, I run, he ran, this company called Fog Creek." Their whole thing, or one of the things, was everyone gets a private office with a door that shuts.

(01:04:20):

He actually went to great length to show how in Manhattan skyscraper real estate, they could make this financially a good idea, and financially viable. They got some architects to design some cool spaces, so everyone got windows, and a private office, and it did not break the bank. By saying, "Do programmers have quiet working conditions? Do you use the best tool?" That is 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 is the advertising aspect here too.

EW (01:05:10):

He does have a highlighted sentence here about "topnotch development teams do not torture their programmers." I have definitely been in some development teams that seem to think that torturing their programmers is part of the fun of running a business.

CS (01:05:27):

Yeah. Not places you should stay. You can help them, right?

EW (01:05:30):

No.

CW (01:05:31):

High profile places doing that right now. Ah, next one.

EW (01:05:37):

<laugh> Number ten, "Do you have testers?"

CS (01:05:42):

This one is interesting. This one perhaps, I am not sure if this one has aged well or not. You have software test organizations, or software quality organizations, or maybe you call them DevOps or whatever.

EW (01:05:52):

One tester for every two to three programmers.

CS (01:05:55):

Right. That is his ratio.

EW (01:05:56):

Wow!

CW (01:05:57):

I have been in that situation and it is wonderful.

EW (01:06:01):

That is true. LeapFrog had the best testers.

CW (01:06:04):

But-

EW (01:06:04):

But I have not had a tester in a long time.

CW (01:06:08):

Do we have- I am not going to say because I cannot remember well, but I am trying to think. The last time I interacted with a test organization was, no, those small companies where we had- At a couple places, we had the tester sitting with us, same group of cubes with the same office. We talked back and forth during the day, and it was great to have that function integrated into the team. Rather than be something across the building, that is like, "Okay, I finished my weeks of stuff, and here go test it."

CS (01:06:41):

Yeah, throw it over the wall kind of a thing. No. Having the people who are going to test your code, sitting with you as you design the code. Frankly, if you can, ask, "Okay, here is a new feature I need to design. Or, here is a new thing I need to add. How will I know it is working? How will we test it?" You add that up front, and it will make it easier to test, for one thing. And, you will probably uncover a bunch of requirements or assumptions that you had, that maybe are not valid, or 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 do not understand it well. Having a tester there helps to force, it is 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 are wrong.

CW (01:07:28):

Let us face it, engineers are very bad at testing their own work.

CS (01:07:32):

Yes.

EW (01:07:33):

Oh, and he is also saying that testers cost one third the price of engineers.

CW (01:07:38):

That is...

EW (01:07:40):

I have to wonder about that.

CW (01:07:41):

I do not think that is...

EW (01:07:43):

Depends on the tester.

CW (01:07:44):

It is not what I would pay them. <laugh>

CS (01:07:46):

Yeah. When I saw that, that is the part I think, "Was that true in 2000?" I do not-

EW (01:07:52):

That is an relatively unskilled tester.

CS (01:07:57):

Yeah. That sounds pretty manual.

EW (01:07:58):

That is not somebody who is going to review your code.

CW (01:08:00):

Yeah. I do not know what he is talking about with that. That is very strange.

EW (01:08:06):

The testers I had at LeapFrog did not review my code, but they sure- Every time we finished a toy, I took them out to lunch, because they did so much good stuff.

CW (01:08:18):

A third is, yeah, that is...

EW (01:08:23):

Okay. Number 11, "Do new candidates write code during their interview?"

CS (01:08:28):

"Would you hire a magician without asking to show you some magic tricks? Of course not." I love that example.

CW (01:08:34):

Yeah. But I am not hiring a magician

CS (01:08:37):

<laugh> So that is why you want to ask new candidates to show you a magic trick during the interview.

CW (01:08:41):

Exactly.

EW (01:08:42):

Yeah.

CW (01:08:44):

I have extremely mixed feelings about how to interview people.

EW (01:08:49):

Now that more people have GitHub portfolios. This is a little harder. 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.

CS (01:09:11):

Yeah. I am not a fan of that. I will say that I am still surprised, how many people cannot do Fizz Buzz when given an hour, and Fizz Buzz similar questions.

CW (01:09:24):

That is where I sit with the thing, is ask something simple and if they get it, then great. And then maybe you can ask something more intermediate. But I have just sat through so many interviews where it is like, "Okay, here is this thing with complicated, it has got dependencies."

(01:09:41):

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 the kinds of questions they were asking were like, "Okay, I have got to understand huge things about maybe frameworks that I have not encountered yet, because they just happen to use them here." I do not know. They get so lost in, "Can you do what we are doing right now, this instant, on our code base."

EW (01:10:13):

But that is not what you are looking for.

CW (01:10:16):

No. Because you weed out a whole bunch of people who could pick it up in three weeks.

EW (01:10:21):

Yeah.

CS (01:10:24):

Interviewing is hard. There is no magic formula to it. You want to have some basic level of software engineering competence. They are not going to be, they might be productive day one. But you are going to have a bunch of assumptions, and your code base is probably five years old or ten years old. It is not fair to expect someone to come in off the street, and understand the random framework you have.

(01:10:49):

If they do understand that, then that is telling you that they happen to use that framework. That does not tell you that they are a better software engineer, than someone who has not used that framework.

CW (01:10:58):

There is that. And then there is 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 ten minutes. It is a completely different milieu. It is not how you do things.

EW (01:11:14):

But this test, these are the questions you are asking a company, that you might want to work for. 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.

CW (01:11:42):

I have been asked coding questions at probably 50% of the companies I have worked for full time.

EW (01:11:48):

Not since I have been a consultant. That does not count.

CW (01:11:51):

No, I know.

EW (01:11:53):

So you have worked at companies where-

CW (01:11:56):

But I knew people. See, I was brought in.

EW (01:11:59):

You were brought in, because people had already seen your code.

CW (01:12:01):

Yeah. It gets harder the more senior you get to, because there has been a lot of times I have interviewed people who have resumes longer than a football field, who have obviously done many things, and they get miffed!

EW (01:12:14):

Yeah. I do not get that. I have seen people get miffed, and I have a nice little speech about how this is just what we do, and I am sorry if you cannot answer it, that is fine.

CW (01:12:24):

What about the questions that ShotSpotter asked me? I got miffed at those!

EW (01:12:29):

Because they were stupid questions.

CW (01:12:31):

Okay. All right. Just checking.

EW (01:12:32):

I do not care how many pluses you put after the i. After you have put two, and you have not stopped, the answer is, "This code sucks! I do not care what it does."

CS (01:12:41):

Did they ask you a post-increment with 18 pluses? Is it legal? What would it do?

CW (01:12:46):

Yeah. And I said, "I would fire you." That was my answer. I actually said that in the interview, and I think that was when I lost the position. Which is fine.

EW (01:12:55):

Yeah. For the best. <laugh> Okay. The last one is, "Do you do hallway usability testing?"

CW (01:13:03):

Oh, it depends on the product.

CS (01:13:05):

He is coming from the web world here, so I am assuming-

EW (01:13:08):

Yeah.

CW (01:13:10):

Hope it is not a firearms company.

EW (01:13:12):

Some of this is the dogfooding. Do you ever actually try your product? And, do you ask other people if it makes sense?

CS (01:13:24):

Yeah.

CW (01:13:25):

I am trying to think. Yeah, let us see. I think it is good. If it is feasible, it is good. Consumer products, that is certainly something you want to do, because A, it is fun to use your own product, and B, it is a great way to find problems. Medical devices gets a little tricky <laugh>.

CS (01:13:47):

<laugh>

CW (01:13:48):

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. Then there was the networking companies and we- I always thought dogfooding was invented by those companies. Because they were always like, "Okay, we have got a router that is basically working, put it in the corporate network <laugh>."

EW (01:14:09):

<laugh>

CS (01:14:13):

"See what happens."

CW (01:14:14):

Yeah. I think it is important. It is just hard to adapt sometimes, depending on the product.

EW (01:14:21):

Usability I think is the big one. I do not think some of the companies I have worked with lately have done good usability. Sometimes it is 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?" I remember again, at LeapFrog, 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! <laugh>

CW (01:14:59):

That is funny.

CS (01:14:59):

That just sounds fun.

EW (01:15:00):

Yes.

CW (01:15:01):

I did go to Microsoft once, and they paid me to do some usability testing. I think it was for a phone. Maybe it was the sequel to the Sidekick or something. I do not remember what it was. It was some consumer device like that. And they just had this pamphlet, with a three ring binder. And so I would be pressing-

EW (01:15:21):

Choose your own adventure.

CW (01:15:22):

<laugh> I would be pressing this piece of paper, and they would go, "Okay." Flip, flip, flip, flip. "Okay, now you are here." <laugh>

CS (01:15:27):

Choose your own adventure usability guide.

CW (01:15:31):

Now of course, you could mock something up a lot easier, I think.

EW (01:15:34):

Not nearly as much fun, though.

CW (01:15:36):

<laugh>

CS (01:15:37):

Yeah, I want to test stuff with a voice artist in the room, and then tell them to improv it. That would be fun.

CW (01:15:43):

Did they dress up as the frog?

EW (01:15:44):

No, they did not dress up. And yes, there was some improv because people always do things you do not expect.

CW (01:15:53):

Do not dress up at the frog. I am not interested.

CS (01:15:59):

You must test your product with house cats riding around on top of it. Regardless, everyone knows that. That is just a tenet of the industry.

CW (01:16:07):

<laugh>

EW (01:16:09):

All right. Those are the 12.

CW (01:16:10):

What have we learned?

EW (01:16:10):

I think it has held up mostly. And you have to decide which of these things are important for you.

CW (01:16:17):

I think there are some missing ones these days.

EW (01:16:19):

What do you have that is missing?

CW (01:16:20):

I would have to think about it. But I am just thinking of recent events, and companies and things. And other stuff you probably want to watch out for.

EW (01:16:27):

Things like how long do you spend with your butt in the chair each week?

CW (01:16:32):

Yeah.

CS (01:16:36):

I think-

CW (01:16:36):

Is the CEO a lunatic?

CS (01:16:40):

<laugh> It just may be a lunatic you are looking for.

EW (01:16:45):

Nice.

CS (01:16:45):

I love that phrase, whenever that word comes up. I am all about random. I am actually not random. I am all about stupid associations. I think the Joel Test, and I will say again, his couple of books and his writing, is fantastic office place fodder to talk about. And get people's opinions, and discuss, "Hey, do you have a spec?" Then everyone will complain for a little bit, but then it is, "Okay, why do we want a spec? What is the important part of a spec?" And you have conversations like that.

(01:17:13):

And no, we are not going to have a full completely nicely typewritten spec, that fully defines everything we are 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." Maybe out of that conversation, you come up with some new sub-spec, or some part of a spec that, "You know, we should start doing that. Or, 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 us take a week and let us go after those." Whatever, I am making this stuff up, obviously.

(01:17:48):

But I think there is value in answering these questions, and talking about them with your colleagues. Even if some of these questions are not a hundred percent relevant as written. I think the thought exercise is good.

EW (01:18:04):

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 do not care if it is noisy when they program. I do not know how they work, but if that is fine with them, that is fine with me, that it is fine with them, just as long as I do not- I love that for you.

CS (01:18:28):

Modems.

EW (01:18:28):

<laugh>

CS (01:18:33):

I was hoping we might hear some of that acoustic modem on this interview, but I guess not, huh?

EW (01:18:39):

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 are planning. Specs do not have to come from other people.

CS (01:18:59):

Yep. You absolutely can do it. If you write it, and if you put it on a wiki, then if you have and someone who is 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, to thank you for that. Right?

EW (01:19:15):

<laugh> All right, well it is been really good to talk to you. I hope The Kid enjoys learning how to identify which companies he is going to work for in the future.

CS (01:19:25):

<laugh> Yes, of course. It is Nintendo by the way. He is going to work for Nintendo. That is the goal.

EW (01:19:34):

Do you have any thoughts you would like to leave us with?

CS (01:19:39):

I learned this quote earlier this year, and I have been using it basically every week. And the quote is, "the biggest problem in communication, is the illusion that it has taken place." I am 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." It is wrongly attributed to George Bernard Shaw, according to Quote Investigator. But whatever.

(01:20:03):

Basically when you talk or think you have communicated, frequently you have not. And the message that you intended the person to receive, was not actually received at all. So it is 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 lets you know you are on the same page.

EW (01:20:26):

Good advice. Our guest has been Christopher Svec, director of software at some unnamed company.

CW (01:20:35):

Thank you Christopher Svec.

CS (01:20:37):

Thanks for having me. It was fun to talk to you both.

EW (01:20:41):

Thank you for listening. And thank Christopher for co-hosting and producing, and thank-

CS (01:20:47):

Christopher White.

CW (01:20:48):

Yeah.

CS (01:20:48):

Christopher White for co-hosting and producing.

EW (01:20:51):

Yes. And thank Christopher Svec for filling in at the last minute, when I had a scheduling mishap. And thank the Patreon supporters for their support. I guess that is it. I do not have a quote, so I am just going to go-

CW (01:21:05):

We had a quote.

(01:21:06):

Yeah, I think that is fine. Have a good week.

(01:21:10):

Goodbye.