Beginners: What now?

Recently, Pearson/InformIT reached out to its authors and asked us what advice we give to beginning developers. Here's my contribution!

Several times a year, I teach groups of people how to program in Python. These are absolute beginners. Many times, the first time they opened up their terminal or command prompt was that morning.

By the end of the class, they’ve learned enough to make a fairly robust program. They can save data, use files, make calculations, loop, and test for conditions. They know how to read error messages, and they’ve played with imports and libraries. I get one question, every time:

“Now what?”

At first, I told them to think of a cool project. Surely, they must know of one! No, everything neat they could think of had been done already. Or, they had an idea, but it was too big. They’d have to learn 3D animation, or advanced calculus, or a tricky API. Finally, I remembered the first project I had really undertaken on my own. It was a loot tracker for a game. My friends and I wasted a ton of time keeping track of who got what spoils when we played together in an online game. I ended up making a simple app to keep track of possible loot, who could use it, and who had gotten the last cool item.

It didn’t make me millions. No one ever used it outside of our little group. But it taught me more than most classes could. I learned how to use databases and secure them. I learned about linking up forms and organizing my code. I learned how to maintain my server, and I learned how to upgrade my system without breaking my app.

The annoyances in our lives, as much as they make us grit our teeth, are also the best places to start. The fact that they exist means there is a void in the existing technology. Perhaps the bit of code hasn’t been written, or it’s prohibitively expensive. Perhaps it’s too clunky, or terribly behind the times. Whatever the case, it represents a place the student can start their journey, and create something that makes their life, and perhaps the lives of others, better.

Here are the rest of the responses, from all over the various tech communities! They should be adding to the list all month.

Teaching: The OS Divide

I spend much of my time in the OS community teaching. I teach kids, I teach beginners, I introduce experts to new concepts. At nearly every conference, I will at least attempt to teach a class. I love teaching, and I also try to talk others into teaching as well.

There’s one problem I’ve noticed with those that are interested in teaching, and it’s something that’s not really discussed openly. Normally, people make a single snarky comment, then walk away. The topic?


Why is this a problem?

When I’ve taught classes, I’ve almost always taught to a mixed crowd of Macs, Windows laptops, and the odd Linux machine. The more novice the class, the more likely it is that I’m going to be dealing with Windows people.

People in beginner classes expect you, the teacher, to know how to deal with their hardware. Yet, when I bring up the Windows problem, people scoff. The most common answer?

“They should get a better laptop.”

I’ve endured tirades about how they should just install Ubuntu, or how a Mac is really just as cheap as a Windows machine. I get to hear about how many years it’s been since they touched a Windows machine. I’ve heard so many stories about how people moved their loved ones onto Ubuntu or Mint or a Mac and that they loved it and everyone else should just do the same.

It’s a problem because it’s snobbery, and it doesn’t belong in education. Why do people buy Windows? There are many reasons why people might own a Windows machine. Maybe they like gaming. I know that’s why my husband and I keep Windows laptops around. They may not have a choice, since that’s what their work gave them (not all of us can demand MacBook Pros). Maybe the suite they work with only works on Windows. They might be like my parents, and scared to learn a new OS.

Or, maybe the decision is economic.

The cheapest Mac starts at a grand. I can easily find laptops for less than that. Sure, they may not have the screen or build or battery life, but that’s not the deciding factor for a large part of the population.

When money is unstable, it can be hard to save money. Savings are pecked away at by daily life and a host of things that cannot be cut. When you’re in this situation, you tend to get chunks of cash in on an irregular basis. You get a Christmas bonus, someone dies and leaves you a bit of cash, or your tax return clears.

Everyone I know who lives at the lower end of the middle-class spectrum or lower has a death or taxes laptop.

If you only get these bits of income in every now and then, you try to make them count. You get things replaced. You pay off a large debt. You buy big ticket items. A laptop is a common choice, but you want the most for your money. You won’t be upgrading in two years. You may be using this laptop for the next eight. So you go for the most memory, space, and video that you can get for that little pile of cash you have.

And if you want that, you’re going to get a Windows machine.

We can shout all we want about stability, or how you still have a MacBook from 2002 that works fine, or how you know of an indie seller that has cheap Linux laptops. At the end of the day, the Windows line is going to win. They are not the enemy At this point, the people I talk to often get mad at the users. They’re blind! Sheep! Technophobes!

The users are not the enemy.

Sure, we’ve all had our infuriating experiences with Windows. Some of us have watched the political wars, both from afar and in the trenches, and we have bad tastes in our mouths. We’ve been held hostage at parties to an infected install of XP that we’ve been asked to clean up, while everyone else takes in holiday cheer. We’ve realized that our children’s school system has been locked into a contract that only exposes the kids to Windows. I get it. But you’re getting mad at the wrong people.

These people did not buy the OS they did in order to make you mad. Really. They did it because it was the cheapest option, or the one they were the most familiar with, or they had specific needs with regards to their OS, and they weren’t confident enough to research alternatives on MacOS or Linux. So stop being mean to them by being snarky or ignoring them.

But if they would just try…

There’s probably something in your life that you use, but you’re not 100% knowledgeable about. How would you feel if someone ran in and, without explaining themselves or gaining your trust, told you to get something wildly different and foreign? For me, I felt this way the first time I walked into a bike shop. I was interested in getting a bike to tool around town. I had grown up with this sort of bike:

A simple Huffy bike. No fills!

It’s basic. One gear, break by pedaling backwards. The bars were at a certain angle, one you could grab while leaning over or sitting up straight. Sitting up was common, because who doesn’t want to pretend to be Julie Andrews now and then? You got one kind of tire. The one choice you got was color.

Julie Andrews on a bike

Then, I went into a bike shop. None of the bikes looked like that. They pointed me towards something like this thing:

A complex looking bike. Wires, tiny seat, weird angles.

Wait, there’s wires everywhere! And the handlebars are so tiny… And what’s with the seat and handle angle? My arms would need to be four feet long to sit up! Wait, the brakes are where? Why can’t I just pedal backwards? And that seat! That’s not comfortable looking at all. Wait, why are you asking me about tire choices WHY IS THIS EVEN A THING?

Whenever I feel the desire to rush a Windows person to a new OS, I remember the feeling of being slightly panicked and wondering if this salesperson was just trying to con me into a bike that wouldn’t work for me, and I back off. I earn their trust by showing that I do know how to deal with Windows, and that I can get Python working on their system. Then, once I have their trust, I start to explore whether they might be interested in checking out another OS.

And note that I say might. They might never move over. That’s okay, because that’s their choice.

What do you need to know how to do?

If you haven’t run away at this point, good! Let’s talk about what you need to know in order to work on a Windows machine.

You’ll need to know how to get the command prompt up. In general, all you need to do is hit the Windows key and type ‘CMD’ + Enter.

You need to know how to figure out what version of Windows you’re on. Don’t just ask the student. This is a chance for you to prove that you’re not going to break their machine. Pull up the command prompt and type in ‘ver’ or ‘systeminfo’. At least one of those should work.

You need to know how to install Python on Windows, both two and three. This is not the time to be Ultimate Nerd. Use the installer. You might even want to trust the defaults, though I know you’ll probably look, anyway. If you stick with defaults, the student will have an easier time debugging down the road.

There’s a good chance you’ll need to update the system path. If you pull up the command prompt after installing Python and get an error when you type ‘python’, your path needs help. This is slightly different for each system, so some googling might be in order.

If you’re teaching something other than just Python, you need to make sure that you know how to install THAT package as well. Oh, and while you’re at it? It’s a good idea to get pip and easy_install working as well.

Finally, you should get familiar with some sort of editing program for Windows. I generally show off IDLE first (since it’s great for beginners), but it can fall short when you’re trying to work in a project that has items other than Python files. I like Notepad++. It’s free. It’s updated pretty often. It looks fine. It’s not crazypants like Eclipse.

And that’s it. That’s not a huge list, all told. But just knowing how to do those things can open you up to a much wider community of learners, and give you a chance, after you get friendly, to maybe move them over to your OS of choice.

Flask + git: Easiest workshop ever

A few weeks back, I got a chance to teach a Flask class to my local PyLadies chapter. Normally, when I run a class, I spend a lot of time typing into the shell and into an IDE, then waiting for the students to do the same. My co-teachers and I then run around trying to correct typos, indentation errors, and syntax. The end result is aching backs and feet, and quite a bit of lost time.

I began to wonder if there was a way to get that time back. Could I take typing out of the equation while still giving the student the power to play around with the material? I realized the solution was in something I touched every day: Git.

Rather than have students type examples in, why not have them check out a specific commit from the class materials and run that? They could mess around with the code, reverting once they were ready to move on. `git diff` would tell them what had changed between commits, so they could see how the new functionality had been added.

After a few weeks of outlines and careful commits, I finally had something I could use to teach a class. I decided to test it on DC PyLadies.

The Set-Up

Teaching a class this way does require a bit more set-up than usual. We couldn’t just install Python and go. We had to install:

Because we only had four hours, I skipped over virtual environments, promising that we would teach that next month.

I did cheat a bit by bringing in the Flask chapter from Python in 24 Hours, since that goes through installation of almost everything above. Still, that didn’t save us from having to put fingers on keyboards. On Windows machines, we had to fix paths. Some of the Macs were finicky. I would say, all told, we spent an hour getting everyone rolling.

Starting the class

I had thought about making slides, but ran out of time. This ended up not being too much of a problem. I simply spend most of the time live coding in front of the students.

The process was simple.

The first few commits were the hardest. There was a ton to explain, such as what a decorator was, what “starting a server” meant, what was doing, where the heck the HTML was coming from (we hadn’t created any templates yet), etc. Even with almost minimal code, we probably spent the first hour just going over the first three commits.

Once we were over that hump, however, commits moved quickly. I’d check one out, go over the diff, and almost immediately, everyone got it. In fact, in later commits, I almost felt like I was moving too slowly.

Even with the speed-up, I still wasn’t able to cover all of the material. I had expected this, though, since the class was really meant for a longer workshop. Still, everyone left with working knowledge of Flask and a nice introduction to git.

What will I change for next time?

First off, I will most certainly factor in more time for setting up. I tried to get students to set up their own environment beforehand, but there’s no way to make sure that everyone does that. Some get stuck on an install. Others install the wrong thing.

What I’ll probably do is have a dedicated set-up time before the class starts. So, if the class starts at 1, then the set-up party starts at 12.

I’d also have someone dedicated to setting up stragglers, and make sure they do it outside of the classroom. This, of course, means I have to get a volunteer who knows Windows as well as Mac OS and Linux.

I’m also investigating doing all of the installs off of a thumb drive. We were lucky that the library’s wifi held up, but there have been some meetings where no one could get more than a trickle of bandwidth. Being able to install Flask (and all of its dependencies) without needing wifi could save a bunch of time in a pinch.

One of the things I skipped was hacking on the code together between commits. The original plan was to propose a small change, then let the students do it. Then, I’d check out the next commit to show how I did it. The room we had and the time we had were both too small, though, for this much interaction.

Future plans

The code I have isn’t finished, yet. I’d like to get Flask talking to a database. I’ll probably add another project so that I can more naturally add in things like text search, pagination, and reusing data in several views (maybe a blog app? Everyone needs to write a crap blog app, so we might as well get that out of the way).

I’d also like to cover using Python Anywhere to get your site out in the wild, and perhaps even deploying to your own server (something I think everyone should know how to do).

Finally, I should add a section on tests, since this would be a good place to teach when you should write a test, and when you shouldn’t.

Want to help?

My repo is here! I’m more than happy to accept suggestions through issues and code through pull requests. All I ask is that you comment clearly in your commits so that it’s easy for anyone to know what exactly they’re going to be demoing next.

Also, try moving in baby steps. If someone wants to run the class at a faster pace, they can always skip commits. And if you want to run the class? Please do! If you can, let me know how it goes, and what would make the materials work better for you!

Teaching Python in your PJ's

I love teaching Python. Really, I do. I love developing materials and teaching concepts and answering questions and opening doors for people who may have thought that they’d never be able to write five lines of code in their life.

So, why don’t I teach more? In general, I only teach a class for our PyLadies chapters a few times a year, in spite of the fact that they help so many people and I love to do them.

A pillbox with the image of a smiling woman holding a box that says 'Medicated.' Text: Better living through chemistry.

So, I decided that it was finally time to do a virtual class.

The class set-up

After deciding to do this, I started looking at various technology. Google Hangouts (the regular one) was out due to the limit on how many can attend. The cap, even if I paid for corporate access, was still way too low.

I checked out next. Yes, it’s used for gaming, but the fidelity was really high, and there was a built-in chat. The only problem was that the lag is pretty large (several minutes in some cases).

I went back to Google Hangouts and decided to look into the On Air option. Though I lost chat, the fidelity did stay high, the lag was shorter, and there was a Q+A option that I really liked. Basically, viewers could submit questions and I could answer them. The thing that makes this killer is, in the video later on, later viewers can fast-forward to certain questions by clicking on them. Neat!

We ended up creating a separate chat room. Jackie found a few, and we went with It was a one-click solution that was attractive to boot.

A screenshot of the class, featuring footage from a webcam in one corner.

After doing some poking around, I found that having your face on the screen (rather than just your voice) helps keep engagement high. I’m on Linux, so I installed GTK UVC video viewer (God, don’t we have the slickest names?). That allowed me to show my face and my desktop at the same time.

I did not fart around when it came to sound. On-board mics are for suckers. I used my Logitech Wireless Headset H800 . It works great with Linux and has a long charge time, and the sound was clear and loud.

For those that are curious, my editor was IDLE. I always use IDLE in beginner classes, because I like for everyone to have a screen that looks the same.

A webpage with bold text centered on it. The text reads 'Back at 10:10.'

Finally, I had a silly little Flask app (that I’ll post about later) that I used to post signs to my screen when we were on break.

The class

Sixty-six people signed up for the class, and we ended up having 28 viewers. This may seem like a huge drop, but trust me, that’s some good retention. Many, MANY people sign up for classes and then never show up.

The 28 that did show up stayed engaged (only one loss was reported). They chatted in the chatroom, submitted questions, and even posted their code on dpaste!

Also, Hangouts On Air was a champ. I didn’t have any lag or loss. That was more than likely due to the fact that I wasn’t on wifi. If you’re going to do a class like this, for the love of all that is good and just, get a hard line.

We managed to get all the way to modules in three-hours, which is beyond impressive. The fact that we can get so far so fast is one of the reasons I adore Python.

Thoughts for next time

I think my set-up worked fine, but next time, I do want to spend more time talking about the editor and making sure everyone is comfortable before I move on.

I want to add a video explaining how the Hangout will work, especially since I can’t show them on my screen (my screen looks different). I also plan on adding videos just for installing the things we need to have running before class.

Are we doing it again?

We sure are!

One of my not-so-secret goals is to move many of the classes online so that we can do more workshoppy things in person. I’ve already scheduled the next class (Flask!) and am planning the next few (Django! Databases! PyGame!).

Can I see the class?

The great thing about using Hangouts On Air is that the class is archived on YouTube. So yes! You can see the class!

It’s not a polished presentation because, well, it was a class. I had to stop to answer questions and I didn’t pause recording while we were on break. Consider it an immersive Real Katie class experience.

Addendum: Yes, that is my pillbox. You can get your own here.