"Excellent! How you guys doing? Oh my word, give me a break people! This is my fourth talk today, so let's try this again - how you doing?"

"All right, all right. Sometimes I teach distance Ed courses. In fact, tomorrow morning I'm teaching one in Nicaragua, but I just checked - this is not a distance Ed course. We're in the same room, so we're going to do like interactive stuff, sound good?"

"And normally we don't allow beer in my classroom, so I think this might go better. You never know, maybe we should change that policy. I'm... I'm not sure. I agree the class would be more popular. Yeah, in class, mom! Seriously..."

"So what I want to talk about tonight - what Calvin asked me to talk about (so if it's a bad idea, it's his fault) - was a little bit about how Python fits in the space for beginners. Now, I know a lot of you are not beginners, especially if you're looking for work. Maybe it's better not to be a beginner at that point. But even if you're not a beginner, is there anybody who is who's brave enough to say so you're just learning Python?"

"Yes? You and me, dude! Okay, excellent, great! This is for you - the rest of these people can hang out. But actually, this will be useful for all of us too, because I don't know about you, but as I've not gotten smarter but I've gotten grayer, and so people expect me to be able to help them learn how to do things. And as you become a senior Dev, you're always ending up having to teach people, am I right? Most of us are not good at that, I'm just saying. And you know, I love to go on the learning program forums and Reddit and so on, and oh, it's comedy gold!"

"So what are we going to talk about? We'll see how you can think like a programmer even if you're not sure you can, and how to teach beginners with Python. You like that? Look at that! Woo, it's fun!"

"All right, so you don't need to know much more about me except here's my favorite thing that Calvin didn't know - I used to be a special ed teacher. Yeah, I know! It was actually severe disabilities at North Central High School. That was the best, best preparation for being a computer science teacher I could have ever had. It really was, and I'm not being facetious here. I mean, some of my students are here, they're like 'Yeah, true.' Because I learned how to teach, I really learned a lot about teaching. And 20-some years in, I'm still learning about teaching."

"I actually think programming is hard. Do you agree? See, this was the interactive part - yes? Okay, programming is every bit as hard as most people think it is. I think teaching is harder. I honestly do. I think that's the more valuable, more difficult, more rare skill. Which is funny because there's a lot of people with the title who don't have the skill."

[Computer vs. Shoe Demonstration]

"Okay, who's got a good gaming rig? Yeah, what you got? Tell us your specs!"

"Oh, it's been a couple years I guess, but it doesn't matter - 12 gigs of RAM, Core i7..."

"Excellent, excellent! Good machine, good machine. Okay, normally I have a rock, but I'll just use a shoe. How smart are they? You thought I was talking about the students, didn't you? No, I was talking about how smart are the computers. There's that gaming computer and there's my shoe - which one's smarter? It's a tie! It's a tie, and if you don't get that, we're done. That's the most important thing about learning how to be a programmer, don't you agree? Now I'm going to have to take the other one off or I'll walk in circles!"

"How smart are they? Not the people - that's never the problem. The people who I teach usually are super, super... they're really, really clever and bright and wonderful. That's never the problem. I've not encountered anybody yet who couldn't learn to program if they wanted to. I've met several who don't want to. But how smart are they? I'm not talking about the people, I'm talking about the computer. See, the hard part about writing a computer program isn't trying to be as smart as the computer - it's trying to learn how to be as mind-numbingly stupid as a computer. That's the hard part, and until you can understand that, you'll never really be able to write programs. Do I get an amen?"

"Amen! Yeah, yeah!"

"Learning to program is hard if you're just doing it now, do you agree with me? It's hard, and in fact, I'm still learning to program. I've been at this for 30 years, I'm still learning. I'll let you know when I figure it out. I still feel like an idiot all the time. Am I the only one? No! All the time! I like walk out of my office like, 'What? Do people pay to read my books? People are actually paying to see my class and I can't even get this stupid thing to work!' And my wife is like, 'Get back in there and get it working!' She is loving, she is awesome."

[Continues with discussion about why programming is hard...]

"Learning to program - it's hard. Why? Well, programming feels different than other skills, doesn't it? Especially to a beginner. 'Yeah, I'm good at cars, but I don't know this stuff.' Languages are scary, right? They see 'code' - that sounds like it's a mystery you're not supposed to know how it works. So the language is scary, there's codes... The environments are scary. We have these IDEs, and you know, I look at modern development and they tell you 25 different steps you have to do before you start opening your first program. That's insane! That is absolutely insane!"

[Discusses various pieces of bad advice commonly given to beginners...]

"The best way to start is to pick a problem you want to solve - I like this one, I like this advice, except it's terrible! Because, see, you know, I'd like to solve world peace - is that the first problem I should try? You know, having goals is good, but if the goals lead to inevitable failure and defeat, maybe we should pick a subset of saving the world first."

"You'll stay motivated if you work on a real-world problem - until you feel like an idiot and leave! Because here's the problem with real world: the real world is messy, isn't it? And so I'm not so sure that we always want to be focusing on real-world problems to start."

"Here's things I wish I'd been taught when I was a beginner, and I've only learned this after, boy, 20-30 years of teaching this, and I'm still learning it: Programming is not about languages. This is the question I hate the most on these forums, right? Reddit 'learn programming' - I'm there every day. 'What language should I start with?' And I have to stop because if I had quadruple size caps lock, I would use it - WRONG QUESTION! That's a stupid question, and here's the great thing: you're going to get reams of advice about it, all of it stupid!"

"Programming isn't about languages. Sure, you're going to pick one - I like Python - but the language ultimately doesn't matter that much. Some will make you feel better earlier, some will make you feel stupider earlier ('public static void main string args'). But the language doesn't really matter. Programming was never about languages."

"Here's my guys in the back right - in the first year of our program, I teach four programming languages, and you know the funny thing? That part's not the hard part. That's what they tell me - am I lying now?"
"No?"
"Okay, good. Okay good, I'll still pay you! Yeah, they think that's the hard part. No, the hard part is we keep changing paradigms. The hard part is, as soon as we know one language, I start talking about something deeper that we can learn with another one. Python's not a good language to teach direct memory management in, for example, because - thank you - it does it for us. But if you're a computer scientist, you better know what direct memory management is. That's when we're going to work in C and C++, make sense? Yeah, malloc and free... You guys don't know that, you're Python people? Okay, good!"
"Most people think that programming is about memorizing. 'I'll never learn all those codes!' And I'm like, 'Yeah, neither will I!' I don't know what you're talking about. I don't memorize syntax. I couldn't, because I use too many languages. You know, in a typical day I'm helping debug code in six, seven languages - there's no way I could memorize that!"
"Okay, this is a good one: 'Most programming isn't about math.' You know - 'I'll never be a good programmer, I always hated math.' First of all, you hated math class; I'm not sure you've met math. Secondly, until you get into data science, gaming, and a few other specific areas, you could do fine in programming without using a lot of calculus. Right? Who used calculus today?"

That's what I'm saying. Okay, you did - you're very smart. And there are places we need it, and certainly, you know, I use algebra several times today because I taught a game programming class. But if I wasn't doing that, I might not need it every day. You can get started without math, and here's the fun thing: when you start programming, you're going to realize the kind of thinking you're doing is the kind of thinking that math was trying to teach you in the first place.
So there you go - programming languages! I love this one: programming languages are simpler than human languages. I know this because 30 years ago, I tried to learn Japanese and I completely failed. Until very recently, when I tried to learn Spanish, and now all the Japanese is coming out. "B Tomi son" - I'm the only person in the world who's fluent in span-human languages!
How much vocabulary do they have? Lots! How many words? Like 100,000 thousands. Okay, how about the syntax rules? How complicated are they? Depends on the language. Oh dear lord! You know, my family's all learning Spanish because my daughter's going to school in Nicaragua, and you know, there's tenses I've never even heard of. You know, past future wonderful undescribed predatory tense - I don't know what it is, but I don't even understand it.
How about computer languages? How many words do they typically have in the vocabulary? Less than 100 - about 100. How consistent is the syntax? Painfully! Programming languages are actually designed to be much more sensible. They're not as flexible - poetry and programming languages not quite as successful, except Perl, of course. It has "bless," "kill," and "die" - those are functions in Perl.
I can tell you my Perl joke: A thousand monkeys on typewriters - eventually, one of them would type Shakespeare, the others would all write Perl code! There's not many places you can use Perl jokes, that's what I'm saying.
Programming really isn't about the things most people think it is. Here's another one: "I can't type fast enough to be a programmer" - I've heard that one. Actually, probably you should be typing slower. How much of programming is typing? Close to none of it. Close to none! Is really that the issue? Again, it's about explaining things to the idiot computer - that's what programming is. And when we think about it that way, it's actually not quite so frightening.
Code isn't about language. Here's what I'm beginning to learn after teaching this for many, many years. Because I've taught beginning programming - pick a language: Perl (yes, I taught beginning programming in Perl), and Basic, and Pascal, and Logo (remember Logo? No, some of you don't), and Scratch. Give me a language - C, C++, Java - I've taught them all as beginning languages, and they started to run together.
I realize there are some common themes. It turns out when I'm teaching a beginner how to go from not a programmer to a programmer, there's really about seven or eight concepts, depending on how you look at them. You get those and you're done, and those concepts are universal across languages. That's pretty beautiful, isn't it?
If you know multiple languages, you know this to be true, right? Your first language is hard, your second language is harder, isn't it? Because you thought you knew the truth. Your third language, it's like "Dude, I'm seeing similarities here." By four or five, you know what you're doing. You're doing a - oh yeah, you were saying they asked me to do a project in Python, I said "Give me a weekend." Yeah, it gets to that point, doesn't it? Because we see these consistencies.
Coding is only about eight main concepts. I'll show you my favorite few - how's that? They work in the same way in every language. When we're trying to teach people how to code, don't teach them code - teach them English, or teach them in English. The secret isn't code; the secret is algorithms and data. That's really what we're here to teach.

Of course, let's pick a language that makes that easy - I nominate Python. If it chooses to run, it's going to win. We write out the concepts first, and then we convert to code later. This is so key - when my students come into me and they're like "I'm so messed up," the first thing they do is sit down, they open up their computer, and what do I do? I shut it on their fingers. Why? If you're lost in coding, it's probably because you shouldn't be coding yet. It's almost always the case.

You write out the concepts first and convert to code. In fact, I will grade your paper if you write a beautiful algorithm and not a line of code - you'll still probably pass. Doesn't happen often because if they write the algorithm well, the code comes. If you turn in beautiful code that runs great without any comments in it, I give it back. That's how important this is after midterm.

Most beginners - this is so amazing - when you, if you are a beginner (and I still am), you get to this point where you think you don't understand how to write the code. I can't tell you how many times people say "I know what I'm doing, I just don't know which code to write." No! Almost every time somebody says "I just don't know how to write it" - no, that's not the problem. The real problem is they don't understand the problem they're trying to solve. They're jumping straight to coding without understanding algorithms.

I get that because coding's cool, right? You look like a hacker. I showed my son [hackertyper.com](http://hackertyper.com/) - you know that site? Oh, you need this! [Hackertyper.com](http://hackertyper.com/) - all you have to do is bang on the keyboard furiously and it looks like you're writing C code, and if you hit the right control sequence, it says like you're in or whatever. Yeah, it's awesome 'cause that's what all of the students think they're going to learn how to do anyway.

The real problem is that beginners don't always understand the problem they're trying to solve. They try to figure out how to do it before they try to figure out what to do. And really, experienced people like us - we do that too, don't we? Every day. Every day!

Here's one of my favorite ideas, and then we'll actually dig in and do some - sound good? Comments are code! All right, so we all know what comments are for - comments are there to explain code to other programmers, you agree? Sure, sure, which explains why we never write them, doesn't it? Because if the comments are there, first of all, it's their own dang fault if they can't understand my code. Secondly, I don't want to explain what it does until I'm sure I know, and that may never happen.

Little painful, painful little giggles there, yeah, 'cause this is true, right? We're all here. And you know, I got to get this thing delivered, man. It's deadline - I'll do my best to get the comments in at the last step, but I got to get it working before I can worry about that. Yeah, so comments are there to explain the code to other programmers, or better yet, yourself, because a week later you're like, "Crud, what did this do?"

No, no, no! I finally learned the truth: comments are not there to explain the code to programmers. Code is there to explain the comments to the computer! That's profound. That is - that's all I got, good night, I'll see you!

Code is there to explain comments to the computer - at least for beginners. But again, I still consider myself a beginner. You write your algorithm first, you got that algorithm first working, it's beautiful, and then how do you know it's done? It's like a turkey, right? The little thing pops out? No. How do you know that an algorithm is done? You look at every line, and at this point, maybe you've even decided what language you're going to use, and you say "I can do that, I can do that, I can do that - oh, better look that one up, break it up into smaller things. I can do it, I could do it, I could do it." At that point, now we can start thinking about code.

That sounds really mean, doesn't it? My students think so too until they do well, and they all earn more than me, so now they don't think it's so bad. So this is important idea. All right, so let's go into - I said there were only seven or eight main concepts. Let's do our favorite first four, how's that? No? Okay, it's been nice seeing you!

Here's the way I like to think about it, because really, algorithms - you can say that and people are like "Eh, I don't know, I don't know," but let me show you exactly how we like to think about these. I actually have one chart that I'll make, and it was uglier than the slideshow so, you know, if you want it, I'll give it to you. But I have one chart and I say, "You understand this - it's an HTML table, it's that ugly - you understand this, you've got programming!" Oh, you want to do it in Java? One second, change it all. Okay great, I changed one column. So I just rebuild that table for every language we teach in.

But here's the ideas now - the first idea is about variables, right? Variables, about data. So those of you who are really beginners, today's our moment. If you're not a beginner, you're like "I know this," right? But someday you're going to teach it to someone. And the real issue isn't just a variable - okay, it's a place in memory to hold data, great, we know that. But here's the interesting thing about this approach to learning: I say first thing you need to know is there is such a concept as "make a new variable," and when I'm running an algorithm, this is one of the things I can pick. What am I going to do? I'm going to make a variable. So that's on your drop-down list of things you can do. Make sense? There's only about eight or nine of these, really.

But when you say that, as soon as you say "I'm going to make a new variable," some questions should pop in your mind. Some questions should pop in your mind, right? Doesn't matter what language you're in - no, same questions. Anytime we make a variable, I guarantee you're going to need to know: What's its name? What's its type? What sort of data does it hold?

Those of us who've been programming for a while know that computers are getting a little fussy about that. You know, we have integers that don't have decimal point stuff, and we have floating point numbers that have that, and then we have strings (which is the much cooler way to say text), and then we got other stuff too. And it depends on which language how fussy you are about that sort of thing, right? If this was a Java group, they'd be like "Yeah, strict data types, baby!" We're Python - we're like "Meh, it's all the same, we'll decide later." But does it still matter what type something is, even if maybe our language isn't too fussy about it? We shall see.

Initial value - what's its starting value? So would you agree whenever you make a variable in any language, you think of these things? There might be some others like scope, but I'm going to save that for functions. Scope doesn't mean much if you don't have functions yet.

So whenever I make a variable, that's what I think. Do you agree? Here's where you say yes... no... yes please... go home? Okay, good, thank you! So how do you write an algorithm? This is the part I'm proud of! When it works, it's the part. See the scrolls?

How do you write an algorithm? Here's the beautiful thing: you must write in English! No coding allowed! Unless, of course, English isn't your favorite language - then Swahili, whatever, cool, awesome. Create whatever it is, I don't care, but your sentence has to answer those questions. It has to answer the question: What's its name? What's its starting value? And what's its type? That's your algorithm. Does that make sense?

So when we're teaching a beginner to make a variable, the first thing they need to know is "I need to make a variable," and then the second thing they need to know is "What questions should I always answer when I make a variable?" Does that make sense? And then when we do that - honestly, that's all they need. But see, if I could get away with it, I wouldn't even teach a language yet, but they don't believe it's real coding unless they're typing somewhere, so fine, we'll do it!

That's how we write this in Python: "name gets an initial value" - type? Huh, you're on your own! But that's how we do it in Python. So I can live with that. Can you live with that? Yeah, sure, 'cause we're Python programmers, so that's good.

So that's one of our concepts. Here's another concept - I mean, it seems trivial, doesn't it? But it isn't, it isn't - output! Right? What's another thing I can do? Well, I can tell the user stuff. I'm going to start here with the command line console because life is easier there, isn't it? We're in charge! I mean, in the GUI, the user's in charge, and who put them in charge? Not me!

But output is pretty easy - there's only one thing to worry about: what message do I want to send the user? And of course, output's usually text, isn't it? Yes, it's text. So that's pretty easy, and we could write an algorithm for an output line too, couldn't we? Don't worry, there's a quiz coming! "Output the text message" - okay, that's really easy. Yeah, you code - yay for Python 3! Not "System.out.println," no... not "Console.WriteLine"... it's as easy as "print" - except I always... yeah, "cout." Thank you! "Printer?" What's a "prin"? I don't know!

You know, I still mess up the parentheses sometimes because I did Python 2.7 for a long time, wrote a whole book in 2. So the parentheses sometimes throw me, but I can do this now. How much are we worried about the Python syntax? Have you seen how much we've stressed about that? Well, why not? Because you all know it, but why? Because that's the part we can look up! How do I do it in this language? That part Google will help us with, won't it? If you try to Google "how what problem am I trying to solve," you're going to get some very scary results. But if you know what you're trying to do - you know, "I'm trying to output text" - you can say "How do I output text in Python 3?" and the chances are you'll get something pretty close to this. Yes, so the coding part is the easy part - the algorithm part is the hard part!

Right, so we're getting to the point where we have enough of these tools we can start to put together a real program. There's, you know, input—now input I like talking about because this is the first one that really starts to talk about the real complexity of coding, isn't it? Because see, all of the other things were atomic; they could kind of stand on their own, but input is really—I mean, input has like dependencies, doesn't it?

I mean, think about it: when I input something here, um, "Tell me the answer." Tell me the answer! Come on, 42! 42—that's a good one, I like that. Um, yeah, I'm coveting that t-shirt.

It's not fair for me to ask you the answer if I didn't ask a question, is it? It's never stopped me as a teacher. But if I am asking for an answer, I should really give you a question. So an input implies that there was some question asked of the user—it may be in that statement as it is in Python, it may be another line, it doesn't matter much. But somehow, we're going to ask the user a question.

Well, okay, now um, "Throw me the ball!" Throw me the ball! Come on, you guys can help—throw me the ball, please! What ball? Yeah, you have a ball—throw it! You know what I should have done? I should have put up my mitt. I shouldn't ask for somebody to throw something if I'm not ready to catch it.

Input—you have to have a variable to answer to, to hold the answer. You have to have a question that you ask them. So the crazy thing about input is it should never be the first line of your algorithm. You see what I'm saying? It doesn't make sense because there's like prerequisites. So you need to either in the input statement itself or in another statement, you need to ask a question and you already need to have a variable in place that can catch the answer.

Well, that makes a lot of sense, doesn't it? And what does that have to do with Python syntax? Nothing—that's a different problem and an easier one, isn't it? That's an easier problem.

Okay, so how would we do an algorithm? Anyone—you want any line of algorithm as long as it answers those questions, makes me happy: ask the user a message and store the answer in variable. Beautiful! We good with that? You want to see code? You've seen the code, but it's easy—variable gets input, message.

Yeah, but you see the point I'm trying to make: when we understand the concepts, the code itself becomes actually at some point—and this is why we don't always write comments, right? At some point, this is more clear than that, but not for a beginner—not for a beginner.

When teaching beginners, it’s important to remember they need to take their time with the process before jumping straight to the code. We sometimes forget that. To beginners, our approach can look like arrogance, but it’s really just forgetfulness.

Now, let’s see if we can write a program. We could with just a basic plan. But in real life, I would stop right here. No more code yet. At this stage, we’ve learned plenty. You can’t make me teach another line of code. What I’d do instead is grab paper and pencil and start writing algorithms.

I’d prefer doing this in groups, not alone. If someone’s confused, they can find someone feeling confident and make them uncomfortable. That’s how learning works. But if anyone turns on a computer too early, I’ll slap it shut. I don’t want computers right now—I want brains. Those are better computers anyway, right?

This is the hard part for those of us who think in code. Sometimes, I even dream in code—it’s terrifying. Especially when my dreams involve memory leaks. That’s a bad place to be. But for now, let’s stay away from computers. Let’s write the algorithm.

Here’s an example of what that might look like:

1. Create an integer variable for `x`.
2. Create an integer variable for `y`.
3. Create an integer variable for `sum`.
4. Ask the user for `x` and store the answer in `x`.
5. Ask the user for `y` and store the answer in `y`.
6. Add `x` and `y` and store the result in `sum`.
7. Print, “The answer is `sum`.”

It’s simple and clean. Some might say, "Why not just write the code?" But beginners need to start this way. Writing out the logic first, before diving into syntax or tools, helps build the foundation.

Python makes this process even easier. We’re half a step away from Python code because Python is beautiful—well, except for some quirks like `if __name__ == "__main__"`. That’s a bit clunky. And don’t even get me started on `self`. Beginners struggle with those things, and for good reason.

At this stage, we take the written plan and convert it into comments. Once that’s done, we can start writing the actual code, one line at a time. Beginners can use Google to figure out syntax, but the logic is already there. That’s the critical part. The actual programming language doesn’t even matter until now.

The choice of editor? It doesn’t matter either. Beginners sometimes stress over finding the “perfect” editor, but it’s not about that. Personally, I’m a Vim guy. I love it. But I wouldn’t impose that on someone just starting out. The editor should stay out of the way. In fact, I’m not even a big fan of syntax highlighting or code completion. Those tools solve surface-level problems but don’t address the deeper issues—thinking clearly and solving problems well.

When teaching programming, the goal isn’t just to write code that works. It’s about writing algorithms that make sense and thinking through problems logically. That’s where the real learning happens.

Don’t start with a solution—unless you’re using Git. Then it’s okay. Make it a new branch and go ahead.

But don’t start with a solution because you’re going to mess yourself up, aren’t you? People come to me all the time swearing that Python is broken because it’s not working, and it should.

Alright, there’s something you’re not understanding—and that’s fine—but there’s *something* you’re not understanding. And often, your assumptions are the reason. You’re assuming things that aren’t true.

Do some detective work, Sherlock. Let’s figure out what’s going on. Let’s get in there and find out what’s happening. There are lots of tools for that, but you have to start by understanding the problem.

A lot of times, I’ll just say, “Turn off the computer.” Here’s a whiteboard marker.

When they moved my office, they were going to take away my whiteboard and my bookshelves. I told them, “You can take my computer.” True story. And they thought I was nuts. They said, “Alright, you can keep the whiteboard—you scare us a little.”

So, what happened here? It’s easy to assume the plus sign is broken. “Dang it, this thing doesn’t even know how to add!” That’s a normal assumption, isn’t it?

But that’s not really the problem. Those of us who are experienced might feel superior because we already know the answer. But why? Because we’ve already felt like idiots in the past when we made the same mistake.

We’ve all been there. We’ve all had that moment where we thought, “The plus sign must be broken.” But that’s not the problem. So, what’s really the problem?

Try this. Python has an interactive mode—I love that. If I type something like `Python + Meetup`, what’s it going to say?

Let’s see. “Python Meetup.” Wait a minute! You can’t add “Python” and “Meetup,” can you?

Here’s where you have to be careful. Someone might want to jump in and say, “Well, operator overloading is a form of polymorphism, and it’s actually concatenating rather than adding because it’s automatically detecting that these are strings and not integers.”

Yeah, no. Slap you with a wet fish for saying that around beginners.

When you’re working with beginners, that’s the *worst* thing you can do. They already feel confused. Now, they feel worse because it sounds like you just switched to speaking another language.

Yes, all that technical explanation is true. And yes, it’s wonderful to understand eventually. But do you have to understand that on the first day? Absolutely not.

It’s enough to say: “The plus sign is so smart that it does different things depending on what it sees. If it sees numbers, it adds. If it sees text, it joins them together.”

And then you might say, “Hmm, it seems like Python thinks 5 and 3 are text. I wonder if that’s the problem. Can I test that?”

Now, let’s Google. Is there a way to find out what type of data something is? Yes! Is it `type` or `typeof`? I always mix up JavaScript and Python here. I usually guess wrong the first time, but it’s `type` in Python.

Alright, so we know that text can be joined (concatenated). Let’s see if 2 and 3 are actually being treated as text. The `type` function will tell us what we want to know.

Okay, now we add a new tool to our toolbox. You see what I’m saying? Now we add a new tool, and we say, “Alright, cool. I need a new algorithm piece: convert to integer.” Go look it up, figure out what you have to do.

Looks like we have an old variable, an `INT` variable, and we need to convert the old variable to an integer and store it in the `INT` variable. Oh look, there’s code for it! That’s all fun, isn’t it?

Now we have a new tool. And that’s how we continue growing: as we encounter a problem, we develop a new algorithmic tool to solve it. Does that make sense?

This is pretty fun, isn’t it? It is—really—in a geeky way.

Now we can try again with a new tool. Notice what I did: I killed my code. And yeah, maybe it took me hours to write that code. But let’s be honest—it didn’t take hours to write it. It took hours to understand it. And I understood it *wrong*.

It’s really hard to get people to throw away code, isn’t it? But sometimes you have to. Fine—put it in a subdirectory if it makes you feel better. But start fresh. Use Git. I love Git.

But start fresh because if the code was worth keeping, it would have worked. And you’re not losing the thought process—you’re just clearing up the mess. Sometimes, you just got yourself into a bad place.

So now, I’m going to rewrite my algorithm. And I’ll be honest—I wrote this wrong the first time. I put it in the wrong order. But before I wrote any code, I thought about it and realized, “That’s in the wrong order. That’s not going to work.”

You see, I’m thinking about programming *before* I write code. It’s often easier to see the order of things that way. I converted too early the first time. But now, looking at it, I can see what makes sense.

I could work this out on a whiteboard. I could be the computer. And now, I can put the code in. Will this work? Yeah, we can prove it. I can run it. And yeah, it works.

Alright, we’ve got branching and for-loops. But I want to talk a little about while-loops before we wrap up.

For-loops are interesting. Sometimes, Python people get mad at me when they see the way I teach for-loops. I say that a for-loop has lots of parts: a sentry, a start, a finish, and a change.

And they’ll say, “That is such a C++ for-loop! What’s the matter with you?” And yeah—it *is*. But sometimes I want to teach Python, and sometimes I want to teach *programming*.

When I’m teaching beginners, I’ll do it this way. If Python is their third language, we’ll use iterators. But if they’re new, this traditional structure lines up better with other languages.

More importantly, it’s better for learning how to debug properly. When you have a loop, what are the three things you always think about? Well, four things, really.

First, there’s the sentry. What is the variable that controls the whole thing? And then, there are three things about the sentry you need to know:

- How does it start?
- How does it finish?
- How does it change?

It seems so simple, right? But how many loops have gone terribly wrong because one of those wasn’t handled correctly?

What’s the most likely basic code structure to go wrong? A loop. Especially if you see a Boolean operator in there. Death to Boolean operators!

So yeah, Boolean operators—truth or false—you get the idea. But we’ll come back to that thought.

Now, let’s talk about while-loops. What are the four things you need to know about a while-loop? What’s the sentry? How does it start? How does it end? How does it change?

Oh wait—that’s not true. The while-loop has only one parameter. That’s the problem with while-loops. The while-loop implies a lot that it doesn’t require, and that’s why while-loops go wrong so often.

If you’re going to make a while-loop, you have a holy obligation to think about what the sentry is—even though the while-loop doesn’t require it. You have to initialize the sentry before the loop, which means you have to plan ahead.

Why are you writing code? You should be designing algorithms first. And somewhere inside the loop—who knows where—you have to change the sentry.

You have to change it in a way that guarantees the condition will be triggered at some point. Oh yeah, the condition! You never forget that one. But sometimes, you’ll write a condition that’s impossible to satisfy—like a marriage seminar or something.

So yeah, those are the same things you need to think about in a while-loop. That’s why I teach them first in the context of for-loops.

**Speaker:**

Because how easy is it to mess that up? Oh, you don't? All right, here we go.

Here's an example: the basic password loop. We've all done this one, right? It exits with a positive result if the user chooses the right password. But if they get it wrong... it launches missiles.

So, if you get it wrong three times—sorry about your luck—*sending the missiles*. Right? We've all done this. How are you going to code it?

Really, how are you going to code it? All right, we'll use a compound condition, right? With a Boolean.

Now, I love Boolean variables—don't get me wrong. It's Boolean operators that bug me. Here's why.

What condition do we need on this thing? Let's see:

- `tries >= 3`
- `guess != correct`

Yeah, that's it. Or is it? Because now `guess` is a negative, and Morgan's Law—it's a Boolean variable.

Okay, take a picture because it's going away.

So, `correct` is initialized. `tries = 0`. `keep_going = True`.

Now, what I love about Boolean variables is that there’s not a lot that can go wrong. It’s about the cleanest variable type you’ve got. I love Boolean variables. I don’t love Boolean *operators* as much—unless I’m just working on Boolean variables with them.

But while `keep_going`, if this thing is `True`—and it better be—we’ll keep going. And through that, I can do whatever code I want.

Yes, I deliberately did not do the formatting thing because I don’t want to freak out beginners. It’s really cool, but not today.

Now, take a look:

- If `guess == correct`, then we’ll say, “That’s great! Here’s the treasure.”
- And then, look at this beautiful thing—*that’s where the break statement goes*, doesn’t it?

Now, we should never write `break`, should we? I know. Switch statements—thank you, Guido, for not including those.

Yeah, so `keep_going = False`. That means the next time I evaluate this loop, we’re out. How clean is that? And what do I really mean by this line? I don’t want to keep going.

I like that. Do you like that? It’s much easier to follow.

**Else,** if `tries >= 3`:

- Then we’re going to print: “Hey, too many wrong tries. Launching the missiles.”

Once again, we’re not directly exiting the loop, but we’re telling it: the next time you evaluate, I don’t want to keep going anymore.

You know what’s funny? I don’t know the last time I wrote a `while` loop that didn’t just say `while keep_going`. Because once you get used to this… man, it’s beautiful.

It is just beautiful. And I write a lot of games. You know, game code gets messy, doesn’t it? Let me tell you—no code gets messier than game code.

Partially because we don’t design for maintenance in gaming. You know it’s going to be out of date in a year. So, in gaming, you don’t design it to be maintained—you design it to be fast. And so, you write some *junk*.

Eventually, we’ll teach all these things in their time, but not today. You good with that?

---

**Why Python?**

I mean, I’ve taken a lot of time to tell you tonight that the language doesn’t matter.

Yet it’s a Python group, and I *do* love Python.

So, if the language doesn’t matter, why did we choose Python? Well, I’ll show you.

You recognize this, right? What language are we in? Old-school C, man. This is the way God intended. Pointers everywhere. No strings—strings are for wusses.

All right, here’s some C. And you know, “Hello, World” is too simple to really get the feel of a language, isn’t it?

So, I say we really need to do “Hello, User.” That is, it asks the user’s name, and then it does something with it. That’s the smallest program I think we can use to really get the sense of the flavor of a language. Would you agree?

Would it be possible for me to take that little chart we just did and show you how to do all those things in C? Absolutely.

---

**Moving On to Other Languages**

There’s C++, right? At this level, C++ looks like a dream, doesn’t it? No more `printf`. C++ *must* be easy—if you’ve done some.

Yeah. If… and… define… anyone? Yep.

C++ is pretty nice at this level, but it gets hard fast.

Here’s my favorite: `public static void main(String[] args)`.

Have you ever tried to teach Java to a beginner? Have you ever been to a beginner Java class?

Every Java teacher in the world who has to teach beginners—and this was me—they wanted me to teach this in Nicaragua. “Please teach this in Java.”

I’m like, “Oh, okay, great. Please wave a dead chicken over your shoulder, turn around three times—it’s a ritual—throw salt, and type this line.”

And they’re like, “We do not have a chicken.”

Never mind, I don’t really mean that. It’s just a ritual.

Because I don’t want to teach you what a static method is yet—that doesn’t make sense if we haven’t done objects. And we shouldn’t be doing objects yet. You’re just trying to make a variable!

So, this makes me crazy. Now, I love Java. I do.

But I love Java for more *advanced* programmers because it doesn’t let you do some stupid things we like to do anyway.

---

**Back to Python**

So, why Python?

That’s why.

If you want to teach a beginner to program, which of these languages is easiest to translate from the algorithm to code that actually works? That’s what I love about Python.

Since I don’t care about the language, how about we pick one that gets out of the way and gives them success?

I want them to succeed. I want them to feel proud. I *want* them to fail—because that’s going to happen—but I want them to overcome that failure.

And so, a language that helps us do that? That makes me happy.

You hear what I’m saying? That makes me happy.

And I like successful students.

---

They’re going to want to make games. Fine. We can do that.

Somebody’s going to want to write a database? SQLite’s built-in. Good enough.

They all want to do GUIs? Okay, fine. TK. Yeah, TK, but hey—it’s built in.

What do you want to do? Sure, we can do it. Get it out of your system.

You want to do web apps? I taught that tonight. I showed them. This is their first Python class. I showed them Bottle because there’s no installation.

See? I don’t want to deal with installing Flask on their computers.

---

How cool is this? Isn’t this fun?

So, that’s really where I am.

I love to teach beginners because I love the process of learning. And I always learn far more than them.

Thank you for your time. I’ll be around to answer any questions. You guys have been awesome.

*Applause*