Tag Archives: coding

CSTA: Learning, Programming, and Making

The closing keynote at CSTA was by Michael Kölling, creator of Greenfoot and BlueJ.  The gist of his talk was that learning to program is not the same as being a professional programmer and the tools one uses for each should be different. In fact, he said that the tools you need to learn are the opposite are what you need when you’re programming professionally.  Block-based programming languages are great for learning, but the tools for text-based programming tend to move quickly into the professional programming area and are too hard to use for learners.   There’s not much in between.

Kölling then demoed a new tool that is that in between space.  It eliminates the issues of missing curly braces and semicolons and automatically groups blocks of code together (boolean statements, for example).  It seems like a very promising direction. I enjoyed much of what he said, and have been arguing for years (sometimes with programming parents) that learning to CS is not learning software engineering.

Four years ago at my first CSTA conference, I had lunch with a woman who claimed that every CS teacher should work in industry for 2 years before they teach CS.  I found it very frustrating because I believed that teaching CS is very different thing and requires different skills than what one might get from working in industry.  The tools change and depend on what part of industry you’re in.  If you’re building apps, your tools are going to be different from someone in web development.  It doesn’t make sense to me to teach those tools to a freshman in high school.

In evening, I hosted a #makered chat where we discussed the intersection between CS and Making.  It was a lively discussion.  My sense of things is that Makers use coding a lot and in fact, we sometimes hear that those who don’t code much feel like they’re not doing “real” making.  I don’t think that’s true.  Many maker programs (like mine) have come out of CS programs or are incorporated into it.  However I’ve heard some CS people not want to deal with hardware or electronics (much less paper, glue, and glitter).   I was thinking about this intersection more, and here’s how I think it works:

Intersection of CS,coding, makered and computational thinking

Intersection of CS,coding, makered and computational thinking

Computer science and making both include coding, but Computational Thinking is the umbrella for both, I think. CT doesn’t need coding necessarily.  The Rube Goldberg machine we made involved a lot of computational thinking (the logic alone was quite challenging), but no real coding.  Thinking broadly makes the relationships make sense and eliminates some of the territorial-ness some people feel about both CS and Making.  Maybe there’s an even broader category we could use, but computational thinking makes the most sense to me.

Coding is a fad

Sigh.  Let me just first refer you to this.  Back? Okay.  So here’s the latest (original here; comments in both locations are worth reading) ”we shouldn’t teach coding” diatribe.

I think our issue isn’t should we, but how should we.  There are some important points raised in this post and in Mark Guzdial’s recent post along the same lines.  First, coding/programming/CS courses are primarily being introduced in high income, predominantly white schools.  More needs to be done to incorporate it in other kinds of schools, so that it doesn’t continue to be something “white guys” do (see the recent diversity stats from Google).  In the article linked above, Larry Cuban suggests as much, and Guzdial addresses this as well.  We all agree this is a problem.  Now we need to address it.

Second, we need scaffolding and transfer.  Mark points to some good research about whether the problem-solving skills that are at the heart of some of these initiatives will transfer to CS or to other disciplines.  Unlike Math and Reading, there isn’t much out there yet on best practices for teaching CS concepts to younger kids.  There’s research on undergrads and to some extent high school, but not much for the K-5 crowd.  Again, Cuban and Guzdial agree that there’s no research proving that transfer occurs.  So we need to work on this as well.

Third, I think we need to connect some dots here.  And separate some.  While I think there are ways we can teach CS in the younger grades in a way that is effective and that teaches some real skills, I’m almost more interested in the mere exposure.  Perhaps because I work with all girls, I want to give girls the opportunities to explore computing and engineering  that they might not take on their own.  Society still pushes girls toward non-stem extracurricular activities.  Boys still tend to pick up things like coding on their own for fun while girls won’t think of it unless they’ve seen it.   So I’m connecting the dots between the lack of diversity in CS and introducing it early through school.  Teaching the skills and giving opportunities are somewhat separate goals, and for me, the latter takes slightly more precedence, but they kind of go hand in hand.

Let me address Larry Cuban’s “true believers” and Logo example.  I never learned Logo in school, but I did learn BASIC and I think that was part of the same “reformation” that Cuban mentions.  I was a student during the Logo phase of things so I can’t speak personally to what was going on for educators at that time, but I know my education history and theories.  And I know that computers were expensive back then.  My suspicion is that Logo died out because the equipment was expensive and then testing came into fashion and that’s where the money got shifted.  By the time computers were affordable and on everyone’s desk, the idea of coding or computational thinking as a school subject had been all but forgotten.  In fact, my small college got its first computer lab the year I graduated.  It was a luxury to have a PC or Mac back then.

In 2014, to use computers, no one needs to know anything about how it works.  You press the button, click the mouse and things happen.  Up until graduate school and even for part of grad school, I had to at least know markup to write a paper.  To analyze data meant using a database and some scripting.  To post homework online meant knowing HTML, CSS, and JavaScript.  Now all that’s done for you.

But just as not understanding your history means you are doomed to repeat it, not knowing how your computer works and how to harness its power for your own purposes means you are doomed to be at its mercy and not the other way around.

Cuban admits that these skills are needed, but thinks schools won’t teach them “right” (to simplify his argument).  It’s true that school boards and districts, and administrators confuse CS with Photoshop and Microsoft Office and buy iPads on which coding is all but impossible (it’s at least limited).  But that’s why there are organizations like the CSTA and Code.org and NCWIT and many others that try to educate people about what Computer Science is and to set standards for schools to follow.  This can do a lot to make sure schools have some guidelines and understanding about what CS is and best practices for teaching it.

Cuban suggests that teachers aren’t invested in teaching CS. There are teachers, teachers with Computer Science degrees, who want to teach Computer Science in schools, but many schools won’t make room for it and the teachers are relegated to teaching Office applications or keyboarding at worst and at best, Photoshop or CAD drawing.  (Or they end up teaching another subject, like Math or Physics)  That’s why you can’t just randomly make someone a CS teacher.  You need to hire for it.  There needs to be certification for it.  Most states don’t have that yet.

So, I understand the worry, that this whole movement will be a flash in the pan, but I think there are some solid reasons to teach coding as early as elementary school.  And I do think we need to address the issues raised by Cuban, Guzdial, and others.  We need more research.  We need standards (not testing, mind you), we need committed and professional teachers, and we need infiltration into diverse school populations.  All of these can be addressed, and they shouldn’t be used as barriers to moving forward.

Remember Daily Coding?

So I fell off the daily coding wagon.  This is my usual mode of operation.  It takes a few tries before a habit will stick.  The beginning of the school year is a hard time to start and/or keep a habit.  The schedule isn’t normal; there are many evening obligations; and one is generally mentally and physically exhausted.  But this week, I vow to start again.  I’m going to begin by doing a few fun things until Thursday, when I plan to start taking an online course.  Even when I know the material from a course, I like taking them because they do keep me coding, and I often learn new ways of doing things.  They also make me think about how I structure my own courses, which is a win-win.  I will continue to keep myself honest by posting in the daily coding section.

Daily Coding

This morning, I ran into this blog post about a women who decided to learn to code by coding every. single. day.  She also decided to be publicly accountable and is pushing all of her code to GitHub.  It’s very impressive.  There are some great lessons in her post about learning to code that I think every person who wants to learn to code and feels intimidated should take to heart.  In fact, much of what she says are things that I wish I’d said to myself years ago.

It’s scary to have all of my mistakes and misunderstandings out in the open. The fact is, that if you want to learn to code you are going to make a lot of mistakes, but just because your code might look a little goofy doesn’t mean you should stop coding. And you don’t need to be a certain type of person, you don’t need to be a math whiz, and you don’t need any prerequisites, because the compiler doesn’t give a damn about that. You just need to start typing.

When I started learning HTML/CSS, I didn’t worry about mistakes or bad code or anything, mostly because I was doing this for myself.  My websites were public, but this was 1996 and the web was a small place back then.  Everyone’s websites looked awful, even most professional ones.  But as the web developed and as I moved into an IT related job years later, I forgot some of that original feeling of doing things for myself.  I was surrounded by expert coders, both at work and most especially at home (ahem, Mr. Geeky, I’m looking at you).  I did not want to be embarrassed.

Ironically, that feeling has gotten worse as I’ve gotten better.  Now that I’ve ventured past HTML/CSS/PHP/Javascript into other languages that are what most people would consider “actual programming,” I feel even more intimidated and sometimes frustrated.  I need to put those feelings aside.

I think the best way to learn is to solve problems that you actually have. This is the primary reason I decided not to follow a course or textbook. By following my own path, I can tackle new concepts and problems in the most logical order possible, which is precisely when I have them. When I have questions, I look them up on Stack Overflow.

This is what I used to do.  I’d want to build X, and back in the day, I’d actually head to IRC to find answers to my questions (pre-Google, remember).  I still do that and things work best for me when I have a specific, personal problem I want to solve.  During the school year, I often code up my students’ projects that they propose.  I find that very useful for both learning new things and for teaching.  I often find more than one way to solve a problem and then I can point the student in the right direction.  I don’t reveal the actual solution.  I find it harder to be inspired to code during the summer.  During the summer, I’m planning, thinking, reflecting, and not always doing.  Even though I want to be doing.  I have this open schedule, all the time in the world.  I have Mr. Geeky to help me (though I really don’t want his help for all kinds of complicated reasons which I’m sure you married folks out there understand).  But every summer, I do less coding than I intend to.

So, I’m hereby (inspired by Jennifer DeWalt) adding to my goals to code every day, to make something every day.  180 days from today would put me at the end of our first semester, a perfect stopping point for this project as my workload is heavier in the second semester.  If anyone wants to join me, jump on board.

Women and Coding

I’ve been meaning to write for a while now, but I’m on break, and I basically refuse to use my brain. :)  Actually, there’s more to it than that, which I’ll get to in a minute.

Over the break, I ran into a couple of articles about Digital Humanities and coding, both by women.  They both address issues with exhorting women in DH to code.  Miriam’s post (second one linked) discusses the issues of the unfriendliness of both in-person and online communities for learning, and the pressure of representing all women.  The other post is more about not blogging and tweeting more, but it shares an issue with the other, which is about time.

These posts come on the heels of an interview I had with Audrey Watters about coding, and an article in the New York Times about the need for everyone to learn to code and touting all the new online ventures that are supposedly helping people to learn to code.  There are, btw, several women quoted in the article, at least one of whom I actually know in real life.  It’s a small world of people who think about these things.  There should be more of us.

As someone who is simultaneously learning to code and teaching women to code, I think a lot about why more women aren’t interested enough in coding to take the time to do it.  And I can come up with a few key things I’ve been thinking about.

First, to address the issue of whether DH’ers or anyone else should learn to code.  Short answer, yes.  Yes, they should know a little code.  They should spend maybe just a few weeks learning enough to write a couple of simple programs–in Python or PHP or Javascript or whatever, doesn’t matter.  It will at least give them an appreciate of how machines work and interpret instructions, of the limitations of what we can tell computers to do, and the logic of the instructions we give.  It helps people see the gap between how humans process information vs. how computers do, which has to be a huge help to anyone, but especially for those in DH.  This is not to say everyone doing DH should become an expert coder.  Only if they want to.  There are plenty of ways to contribute without knowing how to code.

Second, why don’t more women pursue coding, especially with all these great resources that are available.  The answers differ, depending on where you are.  For my students, there’s the time factor–finding time for a class or an after-school program or just figuring it out on their own.  And when your schedule is already packed, that’s hard.  But there’s also a coolness factor (or lack of coolness factor, I should say), something the first post I linked mentions as an issue for teens.  That’s hard to overcome.

Older women also have the time issue.  And here’s where I get to my break.  I could be coding over break. I’m not. My husband did.  He codes in almost every spare moment of his time.  Sometimes I do, but a lot of times I don’t.  And frankly, I attribute some of that to being a woman.  Even if the actual physical labor of our household is evenly divided, and it’s not quite, the brainpower devoted to it is not.  As soon as my husband walks out the door, he’s not thinking about whether the kids will do their homework and clean their rooms or the fact that we’re out of butter or milk or that I have no underwear and therefore need to do laundry.  Those thoughts crowd my head, plus doctor’s appointments, etc.  That’s not to say I’m distracted when I’m working, but it often means that when I do have spare time, those things become my priority, not coding.  Learning anything is a challenge, and frankly, learning to code is not a cakewalk when you get past a certain level.  It’s higher order problem solving.  It puts my brain cells into probably their highest gear.  Which is great and exhilarating at times, but requires energy.  And if I’ve just put in a long 10 hour day teaching, I have a hard time mustering the energy to code.  And laundry takes less energy and it’s already in my head to do anyway.

The other, more important issue, I think, is about the culture.  Learning to code is about entering another culture.  Miriam mentioned the inside jokes that go along with this culture.  Those jokes, along with many other things, are meant to keep people out.  And that’s the nice way of doing it.  If you’ve been to Slashdot lately, you’ll see the not so nice way.  Programming culture, especially online, is not far off from Mad Men.  Women are made to feel that they don’t belong and we shouldn’t worry our pretty little heads about it.

The culture also creates particular structures for learning about programming which are not friendly to women.  Here’s how most men I know learned to code.  They or their parents bought them a (Tandy, IBM, Apple IIe), and they used the manual to learn to program, often in BASIC.  They did this on their own, in their bedrooms or rec-rooms.  By the time, they got to high school, they joined the computer club, which brought together all the other boys who’d learned to program the same way.  By the time they got to college, they’d written programs to do all kinds of things–from games to graphics to organizing their cassette tapes.  Girls, in contrast, often weren’t given a computer.  I got my first as a sophomore in college. Nowadays that’s less true, but nowadays computers don’t immediately look like they need to be programmed.  Why would anyone learn to program on their MacBook?  It’s got tons of programs.

The mostly solo, figure-it-out-for-yourself mode of learning has now been transferred online.  Every venture out there, from Stanford’s CS courses to Codeacademy, takes this as its model.  They think, well, I learned on my own, so if we just give people the resources, they can do it, too.  No, really, they can’t.  They might be able to get started.  But there’s no sequence of courses.  One doesn’t progress from easy projects to harder ones.  One doesn’t learn the next level of things, because often one doesn’t know the next level.  There aren’t group projects or socialization or a context that’s interesting and fun.  I’ve taken a couple of these courses.  In one from MIT, the first lesson had us calculating the first 1000 prime numbers. Woo hoo.  That’s going to be something I use again.  My first lesson in the class I teach? Draw a square with your robot.  Same principles apply, but it’s a lot more fun, imho.

My point is, these courses attract the same kinds of people to CS that CS has always attracted.  They’re not doing things differently enough to reach folks who’ve looked at coding and thought, nope, not interested.  As Miriam says at the end of her post: “If you want women and people of color in your community, if it is important to you to have a diverse discipline, you need to do something besides exhort us to code.”  Yes, you need to do things differently–way differently.  You have to attract the artist and the musician and the future scientist.  You have to contextualize coding within things that they’re interested in, not within things that you think are important.  It’s why I changed my 8th grade curriculum.  Okay, I said, you don’t like this, then let’s do this.  Similar information is being taught, but hopefully it’s in a way that doesn’t turn people off.  And I think it means you have to accept that most women haven’t been sitting in their basements hacking on their computers (though some certainly have), and that might mean explaining the inside jokes (or not telling them) and not assuming that they have a certain baseline knowledge.  And you can’t berate them for that.  I mean Apple once said, “Think different.” But when it comes to teaching coding, few people are.