Choosing a computing major

Teachers are an important resource for students when it comes to their college decisions. Indeed, undergraduates students often state that a high school teacher influenced their decision to become a computer science major. This blogpost includes a number of  for CS teachers to help their students learn about computing related majors. It might also help teachers recruit students in their computer science courses and highlight the breadth of majors available for students. Along with my colleague Susanne Hambrusch, we have developed the following list of resources for computer science teachers as a part of our NSF-funded PD4CS project.

There exists a range of four-year computing and computing-related degrees a student can pursue. It can be daunting to determine differences and commonalities.

Four-year Liberal Arts Colleges will typically offer one degree, most likely in Computer Science. The simplicity may have a drawback: the number of courses offered may be small and few opportunities for specialization may exist. On the other hand, many liberal arts colleges provide a strong computer science education that is often combined with flexibility, allowing students to take diverse courses in other areas.

Large, research-oriented schools tend to offer multiple computing degrees. The types of degrees and specializations offered are often influenced by whether Computer Science is in a College of Science, a College of Engineering, or in its own College (e.g., College of Computing, School of Information).

Most schools provide information and guidance for incoming students. For example,

Many rankings of computer science programs exist. No ranking is perfect and many schools not ranked or not ranked highly can provide an excellent undergraduate education. The US News and World Report rankings have a good reputation and are respected by universities and colleges. They rank different types of institutions, different research areas, different geographical regions, and more.

Students majoring in a STEM field often consider getting a minor in Computer Science. Having a CS minor will give them additional and often attractive job opportunities after graduation. A minor typically consists of 5-6 CS courses (the student is expected to have the appropriate math courses).  Students majoring in math or physics can often double count courses and may be able to complete a minor with less effort.  Guidelines and expectations differ and a student needs to find out the details for the particular program.

Aman Yadav is an associate professor in the College of Education at Michigan State University. He serves as the teacher education representative on the CSTA board of directors. Follow Aman on Twitter @yadavaman

Creating Games in ScratchJr without Variables

Written by Aung Nay & Aye Thuzar

ScratchJr is a popular graphical programming language that allows children from age five to seven to create “interactive and animated scenes and stories” [1]. It addresses the lack of programming tools that focus on “content creating or higher level thinking” [1] for kindergarten to second grade students. ScratchJr software deployment comes with the curriculum and online community, and the design goal of the ScratchJr software is to “provide young children with a powerful new educational tool as well as guidance for teachers and parents to implement it to the benefit of diverse areas of early learning, from math and literacy to interdisciplinary knowledge structures” [1].

Even though ScratchJr is great at making interactive and animated stories, creating games was a challenge since ScratchJr does not have variables. Because of this, we developed the idea of a sprite moving towards a goal as an ongoing visual tracker/indicator of the player’s progress [2], which allowed us to create a variety of games. The game creation allowed us to move beyond the interactive storytelling phase and pump excitement beyond. For the purposes of this blog, we would like to introduce one of the sample projects, Safari Animals. For this game, the players will have to tap on only the safari animals to win the game. There will be various animals that will be shown but not all will be safari animals. When a non-safari animal is tapped, the game will be over. Please view the game video at


Fig 1. Safari Animal game with visual progress tracker

Fig 1 shows a sample project of a game that has the progress dot which starts at row 15 and column 16 and has a red bars at row 15 and column 20. As the game progresses, the red dot moves towards the red bar. When the red dot reaches the red bar, the player is greeted by a “You Win” scene. Along with the achievement tracking, this game also tells a story about animals, particularly the taxonomy of the animal kingdom. The storytelling aspect of the games always draws students in, motivates, and inspires them to create their own games with storyline. And this creativity has to be integrated into the lesson plan. Please see and download the Safari Animal lesson plan at

ScrachJr is a great platform for younger kids because you can create exciting games with the progress tracker using fewer code blocks than Scratch or other block programming environments. We hope that ScratchJr team maintains and updates it regularly and more K-2 teachers as well as Pre-K environments will adopt ScratchJr.

Our paper, “Teaching and Learning through Creating Games in ScratchJr: Who needs variables anyway!” will be published in this month as part of the proceedings of the Blocks and Beyond Lessons and Directions for First Programming Environments A VL/HCC 2015.


[1] Flannery, Louise P., Elizabeth R. Kazakoff, Paula Bontá, Brian Silverman, Marina Umaschi Bers, and Mitchel Resnick. “Designing ScratchJr: Support for Early Childhood Learning through Computer Programming.” DevTech Research Group. Proc. of 12th International Conference on Interaction Design and Children, ACM, New York, NY. Tufts University, n.d. Web. 29 Aug. 2015

[2] Thuzar, Aye, and Aung Nay. “Teaching and Learning through Creating Games in ScratchJr.” Proc. of Blocks and Beyond Lessons and Directions for First Programming Environments A VL/HCC 2015 Workshop, Atlanta, GA (To be published in Oct. 2015)

AccessCS10k: An Introduction to the Quorum Programming Language and Evidence-Oriented Programming

Andreas Stefik, Ph.D.
Assistant Professor, Department of Computer Science
University of Nevada, Las Vegas

Computer programming in K-12 education has become increasingly mainstream in the U.S., especially with the excellent work being conducted by groups like, Project Lead the Way, CSTA, and many others. These trends have been happening for many reasons, not the least of which being a growing awareness of competition from abroad and the well known shortage of professionals in the field (a problem we are acutely aware of in Las Vegas). In this blog post, I will discuss work on the Quorum programming language, the first, so-called, evidence-oriented programming language. By our current count, Quorum is taught in approximately 34 K-12 schools in the U.S. From surveys, we estimate over 1,800 students will be taught Quorum next year.

In this blog, I’ll outline the origins of the Quorum project and evidence-oriented programming in general. More information can be found about Quorum at our website
( Quorum has, to our knowledge, the first Hour of Code that is accessible through a screen reading device and a talk on the language was recently presented at Strange Loop and is available here:

Research on blindness and the origin of Evidence-Oriented Programming

The Quorum project began in approximately 2006 with an exploration I was conducting into the experiences of computer programmers who are blind or visually impaired. Initial interviews and discussions with professional blind programmers made it relatively obvious how many challenges the community faced. In many cases, mainstream tools (e.g., Visual Studio, NetBeans) were not particularly well suited, or in some cases did not work, for this community. More crucially, after discussing the issue with blind professionals, I suspected the challenges for K-12 students were likely worse, as learning Braille or a screen reader can be challenging for blind children. Consider for a moment why learning a programming language like C, on top of learning screen reading skills, might be difficult. While most individuals might see syntax like: for(int i = 0; i < 10; i++) {}

and be fine with it, this is typically translated into speech for the blind. While there is no perfect way to write this, readers are encouraged to say out loud “for left paren int i equals zero semicolon i less than ten semicolon i plus plus right paren left brace right brace.” Similarly, compiler errors when translated to audio can be difficult to understand. A trivial error (e.g., missing a variable definition in C++), might take a minute or two to “listen” to. Mainstream students have difficulty with these things too, but they are exacerbated in students with disabilities.

After making these observations, I concluded that one obvious way to approach making programming easier was to improve the tools (e.g., talking debuggers, accessible editor hints, accessible completion, accessible code folding). I invented all of those things (most are in Sodbeans, a tool for the blind used throughout the U.S. today), and they do seem to help, but C itself is still hard to “listen to.” Ultimately I couldn’t get this nagging question out of my head, “What was the evidence for the design of C to begin with?” So I began to investigate, but weirdly … I could find little human factors evidence in the academic literature.

Historical Context on Evidence Standards:

A slight detour is necessary to help readers who are not familiar with historical evidence gathering techniques. Giving credit where due, I highly recommend reading a paper by Ted Kaptchuk on the history of blind assessment, which influenced my thinking:

Let’s briefly discuss this history. First, it was not always the case that medical practitioners, psychologists, and others used experiments in science. In medicine, the techniques started largely in the late 18th century after Louis XVI created a commission to study the bogus theory of animal magnetism (mesmerism). Benjamin Franklin, the head of the commission, used the idea of “sham treatments” to uncover problems with this (bogus) theory.

As science progressed, techniques became increasingly rigorous. Scientists used primitive placebo tests as early as 1834, although they still had no concept of experimental design. By the late 19th century, psychology was developing and we start to see the use of randomization, at first to explore sensory perception and to evaluate (bogus) supernatural claims like those made by psychics (e.g., talking to the dead).

Experimentation moved forward again in pharmacology, in part because of Charles Edouard Brown-Sequard’s claims that testicular extract from guinea pigs would “rejuvenate mental and physical health.” The scientific community, now increasingly skeptical of claims made without evidence, started still rather primitive assessments within a few months. Finally, by the mid-1930s, we obtained what many scientists think of today as the randomized controlled trial, made possible largely by Ronald Fisher in his famous, “The Design of Experiments.” While not mentioned by Kaptchuk, experimental design today has made other important leaps forward, most of which are unfortunately not internalized in computer science like they are in other disciplines (e.g., studies on replication, registered randomized controlled trials). Walter Tichy has probably discussed this more than most.

Evidence-Oriented Programming

Back to blindness and programming, consider observations that children who are blind had extraordinary difficulties with programming languages, and also that the academic literature was sparse with human factors data on programming languages. Certainly, there exists some papers on the topic (e.g., ESP, PPIG, Plateau, a small number of trials in the 70s and 80s), but the number of randomized controlled trials is small. Programming languages make up the entire foundation of modern software — effectively every computing device that everyone owns is built with one. Yet, the top conferences in programming languages used rigorous proofs to determine if features worked, and had significant empirical data to evaluate performance, but used anecdotes for human factors. I didn’t understand why this would be (yet), but by 2009, we started investigating ourselves, largely in this paper:

Stefik and E. Gellenbeck. Empirical studies on programming language stimuli. Software Quality Journal, 19(1):65-99, 2011. 10.1007/s11219-010-9106-7.

Some problems became obvious. Surveys showed words like “for, while, or foreach” were, in a bizarre and unexpected twist of irony, the three least intuitive choices for people in our sample (which we later replicated). This is ironic because these choices are common across a large number of programming languages.

Surveys only tell us so much though, so we went further, which is to take from the medical playbook, using sham (or dummy) treatments. In the first test, we used what I called a “Placebo Language,” basically a randomly designed programming language where symbols are chosen from the ASCII table (one could imagine other placebo languages). We sent the first of these tests to a small workshop called Plateau in 2011:

Andreas Stefik, Susanna Siebert, Melissa Stefik, Kim Slattery. An Empirical Comparison of the Accuracy Rates of Novices using the Quorum, Perl, and Randomo Programming Languages. Workshop on the Evaluation and Usability of Programming Languages and Tools (PLATEAU 2011). Portland, OR, October 24th, 2011.

The result, at least to me, was an eye opener. Perl, despite the fact that it was a very popular programming language with significant community support, was apparently not detectably easier to use for novices than a language that my student at the time, Susanna Kiwala (formerly Siebert), created by essentially rolling dice and picking (ridiculous) symbols at random. That result was astonishing and I frankly wasn’t sure I believed it. So, we ran a replication with three additional languages. The result was the same, replicating with extreme accuracy on a new sample (Perl within less than a percent). That work was published here:

Andreas Stefik and Susanna Siebert. 2013. An Empirical Investigation into Programming Language Syntax. ACM Transactions on Computing Education 13, 4, Article 19 (November 2013), 40 pages.

Interestingly, in this new study, the same result we saw with Perl we also observed with Java, a programming language so popular it is used in the Computer Science A – AP test in high school. Ultimately, using a technique we call Token Accuracy Mapping, which is basically a way to figure out which tokens may have caused the problems, it appeared that C-style syntax was plausibly the culprit. At the same time, using this new technique, we found a variety of problems with Quorum and borrowed from languages where the evidence showed they had a better design (e.g., Ruby’s if statement design, with the exception of the equality syntax ==, was integrated into Quorum 1.7).

Again, this finding surprised us. At this point, while there is a lot more to learn, we knew there was a problem and our strong suspicion was that the language community had not been gathering rigorous evidence on human factors, basically in its entire history, which we have since confirmed is an unfortunate truth. We hypothesize that this lack of evidence may be one of the leading causes of the so-called “programming language wars,” which we discuss at length in the literature:

Andreas Stefik and Stefan Hanenberg. 2014. The Programming Language Wars: Questions and Responsibilities for the Programming Language Community. In Proceedings of the 2014 ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming & Software (Onward! 2014). ACM, New York, NY, USA, 283-299.

In other words, if language designers are not even gathering evidence on human factors, then it’s not surprising that they seem to disagree about their designs or that students might needlessly struggle. In essence, language designers prove that their features work, and show evidence that they are “fast,” but they never seem to ask, in a scientifically defensible way, “What is the impact on various kinds of people?”

Creating Quorum:

As these studies progressed over time, and as we worked more with various communities, my wife and I decided that if we wanted to program using a language that used human factors evidence as a guide, we would have to build it ourselves. So, we developed the first Evidence-Oriented Programming language, which we called Quorum. Here are the basic ideas of this paradigm as I see it today:

  1. Design features of a language must have corresponding evidence from appropriately constructed randomized controlled trials for as much as is possible
  2. The language authors must allow the external community to suggest changes according to the scientific method, inspired by lessons from history
  3. Evidence from other techniques (e.g., software repository mining, educational data) if gathered from humans and rigorous is allowed

Now to be clear, Evidence-Oriented Programming is a paradigm, not a language, and the scholar Stefan Hanenberg in Germany thought it up at basically the same time. He came to the same conclusions I did for different reasons, with different experiments, on a different part of the globe (his story on the topic is very different from mine and fascinating). Others are fleshing it out better than I have, especially the scholar Antti-Juhani Kaijanaho, who has created what is perhaps the most systematic review of the history of the programming language wars ever.  

More crucially, it is a paradigm because the evidence on various design decisions (which I won’t get into here, but have written about extensively) is tricky to understand and requires significant statistical expertise to grasp. It also appears that some design decisions have trade-offs, the most well known of which to-date is that whether functions in programming contain type information (e.g., an integer, a number) appears to improve productivity of those past the third year of experience in college, but has a small, but non-zero, negative impact on novices at around a freshman year of college (depending on where in a program it is).

In other words, I can imagine one language designer using evidence to optimize human factors for one group, while another optimizing for another, with both taking all known controlled trials into account and therefore having some similarities in their design. As a simple example, a block language designer hypothetically designing for a child’s toy or learning might use the word “repeat” for iteration, which the evidence supports, yet a text-based language designer might use the same word when designing for industrial scale robotics or a NASA rocket where blocks might be impractical and where efficiency of the language is crucial (or some other reason). This type of thinking could provide increased consistency amongst language designs in the years to come, with an increasingly stronger foundation of evidence.

In any case, evidence-oriented programming is not a panacea, nor does it imply we will eventually get to the unlikely idea of “one language to rule them all.” Plausibly, what we are observing today is a paradigm shift in language design, going from next to no evidence at all on human factors toward an unwillingness of young scholars like myself to accept anecdotes or prestige as fact, for a basically similar reason Benjamin Franklin didn’t in the 18th century. No one knows where the evidence-oriented movement will end up, perhaps with some complex hybrid of blocks or visualization, or maybe with different domains having various kinds of approaches, or maybe even partial standardization of some aspects of language design within a century (or two). Wherever it ends up, the goal is to follow the evidence wherever it leads in order to make the next generation of programming technologies just as practical at industry scale, while also being easier to understand and use.

While Quorum began as a toy exclusively to help blind children learn computer science, it has grown in unexpected ways. While it is still used across the U.S. at around half of schools for the blind and visually impaired, about half of teachers that came to the 6th annual Experience Programming in Quorum workshop in Vancouver, WA represented mainstream schools. Quorum is a Java Virtual Machine Language, so it will run on most machines, and has a variety of libraries, including those for creating computer games, LEGO robotics support, and more. Quorum is accessible for people with disabilities, including those with visual impairments, and supports a robust and accessible development environment based on Oracle’s NetBeans. Since the language is built on industrial strength technologies, it can be used not just in K-12, but potentially in college or industry as well, for effectively any general purpose application. Finally, Quorum is under the BSD license (free for any use), and all curriculum is free under the Creative Commons License. Our curriculum goes through continuous improvement by dedicated K-12 teachers and is being mapped to Computer Science Principles and, hopefully soon, the common core. More information can be found at:

CS Principles and Creativity

Students will likely need exposure to, and practice with the CS Principles big Idea “Creativity” many, many times before a “creative – innovative – mindset” is comfortable and natural. You may have to undo years of “non-creativity conditioning.”

It is not enough to tell students that creativity is important; you must show students that you value creativity by actively engaging in it yourself. I don’t have to tell you that a unit exclusively “on creativity” is bound to fall flat!

So how can we build creativity and innovation into the very core of CS Principles? A few suggestions from a variety of experts:

  1. Let students know that there are usually multiple paths that lead to understanding.
  2. Arrange student collaborations that provide meaningful (to them) real-world, problem-solving opportunities.
  3. Provide lots of project and performance choices that employ a variety of “intelligences” whenever feasible.
  4. Encourage them to look for and experiment with new things and ideas.
  5. Encourage questioning.
  6. Be sure your grading does not penalize “less than successful” creativity. Students will not feel free to experiment if their grade hinges on some abstract measure of success. The true reward for being creative is purely intrinsic.
  7. Encourage them to mistakes as opportunities for learning rather than failures.
  8. Enable students to exchange, value, and build upon the ideas of others. Share interesting examples of technological creativity that you run across in the media.
  9. Make time for informal interactions between students.
  10. Offer a safe environment that encourages risk-taking. Avoid a competitive and extrinsically rewarding classroom, by providing a friendly, secure, and comfortable environment.

What do you do in your classroom to build the creative capacity of your students? Share with us!



Did You Miss It?

Miss what you ask? Why the CSTA Webinar presented by Beth Ziesenis, Nerdy Best Friend, on May 12, of course!

A special invitation was emailed to you on May 1. I opened the email and registered for it immediately! I wanted to know about apps that would help organize my life.

I was prepared to view it at school on May 12 and would you believe it, the school network decided on that very day to slow down to a crawl and I was unable to view the webinar. Never fear. I received another email that announced that it has been recorded. You can access the webinar at

I viewed the recording and took notes about her suggestions. Some of the apps I plan to try out are listed below.

An app to control my email called 10 minute email. It is an email address that lasts 10 minutes so you can use it to sign-up for information that you only want one time. You can find it at:

Create graphics using Canva. You can use it to create posters. I hope to have my student groups next year create a posters containing graphics to help the other students understand computer science vocabulary. This might be a great way to do it.

Utility: Is the problem with my school network or it is a problem for everyone. I can check that with . I am sure I will be trying it out at school shortly.

Video post cards: I saw this demonstrated and I immediately thought Open House next school year – perfect. I will video a few of my students this year and have them introduce the class to the parents.   The app she suggested was PicPlayPost. You can get it from Google Playstore: or


Want to stay ahead of your students with tech? Then Product Hunt is for you.   It is a Reddit for new software and apps.  You can view it at

The last app I plan on trying out is Office Lens. You can take a picture of a document, business card or whiteboard and the app will straighten it out and upload it to Microsoft OneNote. You can do your own edits because the app runs it through OCR.

These are the apps that I selected from the webinar that I want to try out. You should view the webinar to determine if there are other apps you might like to try out.

Beth also set up a Google Form to crowdsource apps. If you know of apps that are your favorites you can add them to the Google Sheet using the Google Form at:

You can view the apps that CSTA members have suggested at:

I want to hear from you about your thoughts regarding the webinar or apps that I have selected.

Myra Deister
CSTA At-Large Representative


AccessCS10K: helping make high school computing courses more accessible and welcoming to students with disabilities


By: Richard E. Ladner
University of Washington

In 2010-2011, approximately 13 percent of K-12 students have a recognized disability according to the National Center for Education Statistics (NCES). This represents about 6.5 million students with disabilities in the K-12 education system. This only counts those students covered under the Individuals with Disabilities Education Act (IDEA) of 1990.   There are many more who have 504 plans (under the Rehabilitation Act of 1973). Students with 504 plans need some accommodation to attend school, but not an entire Individualized Education Plan (IEP) like those under IDEA. In any case, teachers of high school computing courses are likely to have students with disabilities in their classes.

One group of students, namely blind students, are already severely disadvantaged in high school computing classes that use programming tools such Scratch, Snap, Alice, Processing, Greenfoot, and other highly visual user interfaces that are generally inaccessible to blind users. Will teachers in these classes say, “Sorry you cannot take my computing course because you cannot use the tools we are using to teach programming?” Will a special education teacher or guidance counselor recommend to the student that she consider another career choice than the one the student wants to pursue? This should not happen. Computer science is a great profession for blind people and they should not be discouraged from pursuing it at an early age. (For profiles of blind individuals – and other individuals with disabilities – who have pursued computing visit the Choose Computing website.)

The goal of AccessCS10K is to help make it possible for all students with disabilities who are intellectually capable of learning computer science to have the opportunity to do so. The project is specifically focusing on the Exploring Computer Science (ECS) course and the Computer Science Principles (CSP) course, both of which are being supported by the National Science Foundation’s CS 10K initiative.

AccessCS10K has two objectives to reach its goal:

  • Build the capacity of ECS and CSP teachers to serve students with disabilities through professional development training and individualized real-time support.
  • Create accessible materials that ECS and CSP teachers can use in their classrooms, both tools and curricular units.

To build the capacity of teachers, AccessCS10K is partnering with as many of the CS 10K projects as possible to help them include information in their professional development about inclusive teaching strategies and accessible tools and curricula that can be used in the classroom. AccessCS10K holds capacity building institutes for the leaders of these projects as one way to help them integrate this information in their professional development. It maintains a community of practice whereby teachers can share resources among each other.   It maintains a searchable knowledgebase of articles that can help teachers find information they need to solve problems. Finally, it provides real-time support for teachers who have specific questions about how to integrate a student with a disability in their computing class. To get support call 509-328-9331 or e-mail

AccessCS10K is building accessible tools and curricula that can be used in ECS and CSP courses. One major tool is the Quorum language which is an easy to learn text-based programming language that can be used for both visual and non-visual projects. AccessCS10K’s development partners are working to make other accessible tools and curricula, not only for the programming components of these courses but for the other components as well.

In an upcoming blog post we will present an introduction to Quorum. If you are curious about Quorum we encourage you to visit the Quorum web site or to try the Quorum Hour of Code

AccessCS10K is funded by the National Science Foundation as part of the Computing Education for the 21st Century program of the Directorate for Computer & Information Science & Engineering (Grant #CNS1440843). AccessCS10k is a collaborative project between the University of Washington and the University of Nevada, Las Vegas.

Doing computing means embracing failure

We always tell ourselves and our students to take risks. But taking risks means that we will fail at things. And generally, none of us like to fail.

Think about what it’s like to write code. Most of the time, the code is broken, and you’re failing.

This semester, I’m watching my students struggle with assignments in our sophomore-level object-orientation in C++ programming class.

We’re working through a series of two-week projects. The projects are pretty fun:

(There are more—this material is from Princeton’s COS 126 course.)

From the students’ point of view, there are a lot of steps to get to a working system:

First, to understand the basic problem. What data structures will we use? How does the algorithm we’ll use work? How will it all be organized into objects?

Next, starting to write code. What goes in the header file? What goes in the source file? Why is there this separation anyway?

OK, I have some code. Let’s try compiling it. Oh great, tons of compile errors. Of course.

OK now it compiles. Does it work? Not a chance.

Well, time to debug… where do I start? Probably printing some stuff out… how about seeing that I can read the command line arguments properly?

And so on.

Probably the most challenging part is at the very beginning—making sense of the task itself, and how it’s to be accomplished.

I encourage my students to do their work in baby steps. Just write a few lines of code, compile it, and make sure it works.

Only add more code after you have a little bit of code working.

Compile and test before moving on. Make sure you are going from a working thing to the next working thing.

But even with this strategy, as soon as a bit of code is working, the next step is to add more code, which means breaking it again!

Most of the time, things are broken.

It takes a high tolerance for failure like this.

I do believe that we learn best when we encounter challenges.

And the beauty of our practice is that we’re so readily able to get feedback on the quality of our ideas. Since our ideas are expressed in machine-executable form, we can debug them.

But it is hard, emotionally demanding work, and it’s important that we recognize how much effort our students put in to accomplish their successes.

Terry Dash, a CS educator in Massachusetts, just described to me a teaching experience she had teaching Scratch to middle school students. Midway through the school year, her student Erica cried out during class, “Now I get it! The more it breaks, the more fun it is!”

That’s the spirit!

yours respectfully,
Fred Martin
CSTA University Representative

How Do You Help Struggling CS Students?

This question has plagued me for the last few years, but more so this school year. In order to offer computer science courses and to make the course open access, some students enroll in the courses that don’t fully understand what computer science is and may not have the prerequisite problem solving skills. They do know that they want an AP course.

There is no prerequisite computer science course for AP Computer Science at my campus. The students would not enroll in a prerequisite unless it was an honors or AP, and we don’t offer one that is. To ease the students into computer science, I use Alice3 at the beginning of the school year then move into programming turtles and then Media Comp Lessons that are in Exploring Wonderland by Dann, Cooper and Ericson. I have been successful with this approach the last few years until this year.

This year I have tried several new strategies. I began using paired programming so each student would have someone to turn to for help. I would be free to help the students that are really struggling. Additionally, I have assigned fewer labs to give the students more time to work out solutions together. I have also assigned scenarios similar to the labs for the students to construct pseudocode prior to writing the program. I select random student papers, project them and we discuss the student written pseudocode. I also have assigned videos to do some flipping of lessons and the students take Cornell Notes while viewing the videos. I am available at lunch and after school for additional help. The students are writing reflections at the end of each unit discussing a lab that they have completed.

Even with all of that, I have students that are so lost they are not completing labs and are scoring low on tests. This semester the counselling department has resurrected a course title, “Fundamental of Programming” and has transferred a few of the students into that class. I have altered the assignments and tests to better meet their needs.

As I work to make my computer science course more diverse, I know that I will need to include additional teaching strategies to help all students. On Wednesday, March 11, I will be participating in the CSTA K-8 Task Force Twitter Chat #CSK8 from 5-6 pm PDT about Pedagogy: How to teach CS to 5 – 14 year olds. I am looking forward to hearing what K – 8 teachers are doing and tweaking their ideas to use with the high school students. I am also attending the CSTA Conference in July. One session that interests me is “Teaching CS to Students with Learning Differences”.

I will be piloting a Computer Science Principles course next school year and offer it as an AP course the following school year. Adding CS Principles may encourage some students to enroll in that course rather than AP Computer Science to help build their confidence.

I am continuing to look for additional resources and strategies. If you have any suggestions, resources or strategies please post them.

Myra Deister
CSTA Board At-Large Representative

Teaching Writing is just like Teaching Computer Science

We all know that writing is an important skill to develop in every classroom—including the computer science (CS) classroom. If our students can’t communicate their ideas, they don’t have a chance succeeding in or out of our classrooms.

And while as CS teachers we know the importance of teaching writing, we sometimes freeze with that deer-in-the-headlights look when thinking about actually TEACHING communication skills. Well, I’m here to tell you that you’re a natural! If you can teach computer programming, you can kids to write.

Thank you, Terry Freedman, for the elaboration of these ideas in the Tech & Learning article “How learning to code might improve writing skills” (

Compare the strategies you use to teach CS to those required in writing.

  1. Making a plan for writing is similar to creating a flow chart or storyboard.
  2. Writing a clear precise sentence is like an explicit computer instruction.
  3. Good grammar is just syntax in another language.
  4. Well-ordered text is not much different than code that follows the algorithm.
  5. Too many words can confuse the reader just like too many statements create spaghetti code.
  6. Creative writing and programs require a mastery of vocabulary and commands.

See? I told you that you were a natural. Teach writing the way you teach programming and you’ll be fine.

Barriers to Pair Programming (and solutions!)

A hot topic at the New Mexico Computer Science for All (NM-CSforAll) wrap-up meeting held on January 3rd, 2015 at the Santa Fe Institute was barriers to pair programming. NM-CSforAll has been actively promoting and preparing teachers to use of pair programming and peer instruction with our diverse student population that includes a high percentage of Hispanic and Native American students. Over the past two years we have repeatedly heard from participating teachers that these methods are not easy to implement so we set aside time to discuss the barriers teachers encountered and solutions suggested by fellow CS teachers. Here is what we learned:

  • In general, new CS teachers experienced difficulty supporting the wide range of skill levels among students in their CS class(es). Some students had prior experience in computing while others were totally new to computing. When using the pair programming methodology, sometimes the more experienced student did not want to switch out of the “driver” role. Suggestions to deal with this situation included:
    1. Carefully constructing pairs taking into account the needs and dispositions of each student.
    2. Avoid tracking students based on ability.
    3. Monitoring to make sure students switch roles.
    4. Reiterating benefits of pair programming often.
    5. Practice occasional individual programming and reflect on the difficulties of working entirely alone.
  • Communication with fellow students can be difficult for students from different cultures. Suggested interventions included:
    1. Providing students with pair programming prompts such as “what do you think we should do next?”
    2. Showing videos that demonstrate how to “pair program” such as the one from (See
    3. Practicing and modeling pair programming frequently.
  • Students who come into the class already knowing other students are often unwilling to work with a student they do not know. Suggested solutions included:
    1. Frequently switching the pairings.
    2. Reiterating that pairs will be reassigned often, “it’s not forever.”
    3. Providing students with opportunities for feedback on the pairing and the work produced by the pair.
    4. Using a Gallery walk as an occasion for students to discuss their project with fellow students and find common interests and working styles. Sometimes this leads to new successful partnerships and pairings.

Thanks to the CS teachers who contributed to this discussion: Amanda Dunlap,

Alan Daugherty, Michael Steele, Julie Scott, Rowena Dolino, Melody Hagaman,

Joanna Stitt, Elvira Crockett, Barbara Teterycz, and AnnNet Delaney.

–Irene Lee

CSTA CT Task Force chair