Written by: Cait Pickens
Primary Source: Computing Education
Lately I have been looking at tools used to teach young people how to program. That includes environments and languages like Scratch, Turtle Graphics (in Python), Alice, Greenfoot, etc. It also includes full curriculum programs like Girls Who Code, Black Girls Code and online programs through the Khan Academy and Coursera.
I’m hitting a wall though, and I need to take a minute to discuss the problems I am seeing – otherwise I might implode.
 There are a lot of people working on the same problem. First and foremost, I keep uncovering more teachers (through CSTA, CS4HS, the Khan Academy, code.org, independent blogs, Twitter) who are encountering the same exact problems and are asking the same sorts of questions. These people are all doing really incredible work, but they are it independently (on their own little corner of the internet). We need to get on the same page.
 The tools are repetitive. I once worked on a research project developing algorithm visualizations for JHAVE. While I thought the system was super cool and it was an excellent foray into CS education research for me, I soon realized that a ton of visualization programs actually already exist. In fact, you can see them all at AlgoViz. At first, it seems great that there are so many tools and options out there.
But the problem I’m seeing is that computer scientists are too quick to just create a new tool, rather than add-on, mashup or adapt a tool in existence. When we find a problem with the existing teaching tools, we create from the ground up, scrapping all design decisions in other system. Instead, I think we should try using what is already out there, evaluate whether or not it actually works in a research sense, and make informed decisions about how to continue developing better CS teaching tools based on the research. Yes, that means we have to work together, collaborate. Open-source style, anyone?
 The tools are designed for independent learners. I am really starting to think that the “independent learner” design that I am seeing built into teaching tools for CS is part of our pipeline problem. No wonder minorities aren’t getting into computing; we are not giving them access points, an ecosystem of support. Instead, let’s build mentoring, tutoring, conversation, socialization, collaboration, and feedback into our teaching tools.
 The actual curriculum out there is limited. If you search “How to teach mean-median-mode to middle schoolers,” you get a series of examples of lesson plans, tools used for teaching, possible assessments for students, feedback about how certain types of lessons target different student demographics. This portfolio of resources allows a teacher to go out and teach immediately, without having to build a curriculum framework around a teaching tool. In CS, often our teaching tools are still stand-alone and are not accompanied by curriculum, lesson plans, assessments, use-case examples, etc. We need to package our tools with the curriculum, not just create the tools and expect teachers to know how to implement them.
 The tools do not follow best practices for teaching. Since the tools are often designed primarily by engineers (sometimes without even consultation from educators), they are often missing the perspective of the “science of teaching and learning.” There is a ton of research out in the world about cognitive psychology, philosophies of education, mental models, the notional machine, inquiry-based learning, and problem-based learning, just to name a few fields and concepts related to CS education. This sort of research should not just inform the development of CS teaching tools, it should fundamentally drive direction of their development.
 The tools do not talk about the “whys” of programming and computational thinking. The world is aflutter with the general need to learn to program and to do so quickly. But why? If you’ve ever attended a middle or high school math class, I’m sure you’ve heard students ask “When would I ever use this in the real world? Why do I have to learn this?” As an engineer, I can brainstorm a thousand reasons why programming is important and exciting and useful and relevant. We have to build this sort of learning direction into our tools and lessons in order to motivate student audiences. For example, “at the end of this lesson, you will know a bit about how search engines work and consequently you will how to trick web searches into ranking your personal website/blog/Tumblr highly.”
 While we are at the drawing board, let’s consider cultural relevance of teaching tools. Who are we to define what is “cool” and “hip” for young people? Let’s start asking some them! I cannot speak for middle-schoolers today, but I can tell you that when I was 13, I thought myself pretty “mature” and “adult-like.” So, let’s design teaching systems that play off of the world views held by middle-schoolers. In another example, when I teach on Pine Ridge Reservation, I use Lakota culture and folklore in my lessons about programming. Computer science is not just for rich, white males, so let’s teach it in diverse ways and build that diversity into our teaching tools.