Vintage Computer Festival — five events this year!

If you’re looking for novel ways of inspiring students, then consider giving them some hands-on exposure to the past at a Vintage Computer Festival event.

Vintage Computer Festivals are a series of family-friendly events celebrating computer history. The event formed in the 1990s and gradually spread to other parts of the country and into Europe. Each event has an exhibit hall where anyone can see and try out historic computers from the 1960s-1980s. There are also keynote speeches by celebrities and VIPs, technical classes, tours of nearby museums, consignment sales, and more.

Upcoming editions include VCF East (April 15-17, New Jersey) and VCF West (August 6-7, Silicon Valley). Children enter free for most of the event.

These events are the only place where your students can see things such as a 1960s DEC minicomputer, 1970s systems such as an Altair 8800 or Apple-1, and all manner of 1980s eight-bitters — all up-and-running. Take a learn-to-solder class, play a round of Zork, see a UNIVAC mainframe, and learn how to load BASIC from paper tape.There’s no better way to make students appreciate modern smartphones than to see an 800-pound Cray supercomputer or boot a Commodore 64 into a flashing cursor prompt.

The series producer is Vintage Computer Federation which is a 501(c)3 educational non-profit. In addition to the shows, the Federation also owns the Vintage Computer Forum online discussion site, incubates regional chapters, and operates its own hands-on computer museum.

– Evan Koblentz, president, Vintage Computer Federation 

Introducing CSPdWeek

We shine a spotlight on CS education for students each December during CSEdWeek. Why not do the same with a perennial offering for CS professional development for teachers?

After all, professional development has long been recognized as one of the key ingredients in CS education. Bringing even one PD provider to train a handful of teachers and counselors in a small district is prohibitively expensive, and even the smallest school district will need multiple solutions to implement the dream of CS4All. One way to solve this problem is with grants and sponsorships, subsidizing local workshops for a handful of teachers at a time. However, this only solves part of the issue–even with limitless dollars, scheduling constraints make it extremely difficult to bring multiple providers in at the same time. This makes it nearly impossible for most districts to adopt the broad mix of offerings that are necessary to increase diverse participation in computing. In other words, coordination can be just as large a bottleneck as funding.

CSEdWeek is a model for coordinated advocacy. Schools in a district, in a state, and across the country effectively leverage funding and volunteer efforts at the same time every year. It’s time to do the same for professional development, and this is the impetus and foundation for CSPdWeek.

The first annual CSPdWeek is this July 18th-22nd, 2016 – find out more at!

CSPdWeek Events

An inaugural event, offering PD from Bootstrap, NCWIT Counselors for Computing, AP CS Principles, and Exploring Computing Science will be held during the week of July 18-22nd at Colorado School of the Mines. The event is sponsored by the Infosys Foundation USA, with additional support from the National Science Foundation, The National Center for Women & Information Technology, and the Computer Science Teachers Association. We invite teachers and counselors from across the US to apply for full funding (covering travel, food, lodging and PD), with an emphasis on those working in high-needs schools. Join nearly 300 educators from across the country, and spend the first CSPdWeek with us in Golden, Colorado!

Can’t make it to Golden? That’s okay! CSPdWeek is for everyone, and we encourage other PD providers to offer their own professional development events during the week. Professional development matters, and will be a crucial component of CS4All. By staking out one week during the summer, and coordinating our efforts, we can amplify the impact of everyone in our community.

It’s going to be an incredible summer, and we hope you’ll join us in celebrating CSPdWeek 16!
Owen Astrachan (CS Principles)
Gail Chapman (Exploring Computer Science)
Joanna Goode (Exploring Computer Science)
Jane Krauss (NCWIT Counselors for Computing)
Emmanuel Schanzer (Bootstrap)

DRAFT 2016 CSTA K-12 CS Standards: We Need Your Feedback—Again!

Much excitement and activity continues to take place in the K-12 Computer Science Education space. The K-12 Computer Science Framework and the Computer Science for All initiative started by the White House both continue to evolve. Many states and school systems are working to implement computer science into their curriculum. And, the CSTA K-12 CS Standards Revision Task force continues to refine the draft 2016 CSTA K-12 CS Standards.

Thanks to all of you who took time to provide us feedback on the draft 2016 CSTA K-12 Computer Science Standards during the first review period. We received many great recommendations and comments about the standards. The CSTA K-12 CS Standards Revision Task Force members met in person on March 5 and 6 to read and analyze the feedback that we received. They have been diligently working to revise the first draft of the 2016 CSTA K-12 CS Standards to reflect the feedback. The second DRAFT of the 2016 CSTA K-12 CS Standards is now ready for public review and feedback. We need your assistance once again!

Please take some time to review the revised 2016 draft standards and complete the 2016 CSTA K-12 CS Standards Feedback Form. This will provide the CSTA Standards Revision Task Force members with additional constructive feedback that will assist us as we seek to refine the standards and make them most useful for K-12 educators. You will have the opportunity to give us detailed feedback on individual standards in each of the grade levels (Level 1, Grades K-5; Level 2, Grades 6-8; Level 3A, Grades 9-10 (for all students); Level 3B Grades 11-12 (enhanced standards for students who wish to further study CS). You will also be able to provide feedback on all the standards for a grade level within a concept area.

Feedback for this second review period will be accepted from April 6 through April 20, 2016. The task force members will analyze this feedback and further refine the standards as needed. CSTA is committed to an iterative process that allows multiple drafts and revisions before publication. Our goal is to release the interim 2016 standards at the 2016 CSTA Annual Conference.

We want your feedback. We need your assistance. Please thoughtfully complete the CSTA K-12 CS Standards Revision Feedback Form. This second round of feedback on the standards will be accepted until April 20, 2016.

Thank you for your time, expertise, and enthusiasm in supporting K-12 CS education.

Deborah Seehorn, CSTA Board of Directors Past Chair & CSTA K-12 CS Standards Revision Task Force Co-Chair

Tammy Pirmann, CSTA Board of Directors District Representative & CSTA K-12 CS Standards Revision Task Force Co-Chair

Website Links

Computer Science for All

K-12 CS Framework

2016 CSTA K-12 CS Standards Revision Task Force

CSTA K-12 CS Standards Revision Process

2016 CSTA K-12 CS Standards Feedback Form

2016 CSTA Annual Conference




Computer Science/Coding Education Graphic from SMU

Guest author: Shane Ryan; Community Manager, DataScience@SMU

DataScience@SMU, the online data science program offered by Southern Methodist University recently published a graphic detailing coding and computer science education in the United States and around the world. Despite the booming field and increasing job prospects for computer science professions, only 1 in 10 K-12 schools in the US have implemented coding education to their curriculum. In the graphic, DataScience@SMU highlights some of the obstacles to educating students in the US while showcasing other countries who have mandated computer science education as part of elementary or secondary curricula. Additionally, the piece details some of the challenges to teaching computer science while also touching upon the gender gap in the field.

Infographic can be viewed here.

A review of Google’s Exploring Computational Thinking resources

By Joe Kmoch

In Spring 2015, Google began work on revamping their CT website. Their materials are available at a website called Exploring Computational Thinking:

A team at Google developed a template for lessons which would be made available on their site. They took the large number of lessons that were already on their site and rewrote them into this new lesson plan format. They hired a group of educators to review all of those lessons and now have about 130 lessons and other materials available.

These lessons have specific plans, are interactive and inquiry-based, and include additional resources. There are lessons in 17 subject areas mostly in math and the sciences. These lessons are also cross-referenced to various sets of international standards (Common Core, NGSS, CSTA K-12, and standards from UK, Australia, New Zealand and Israel).

At about the same time, another Google team developed a group of six videos called CT@Google which focus on the Seven Big Ideas from the CS Principles course, and how Google uses them in their work.

Finally, Google developed an interactive, online course, CT for Educators, where teachers learn what CT is and how it can be integrated into a variety of subject areas. It is quite good and can help a teacher work CT concepts into their regular lessons:

All of these are quality resources.


Disclosure: the author was compensated by Google for assistance in editing the collection of lesson plans mentioned in this article.

Advocating for CS Education – Strategies from Connecticut

By: Chinma Uche

The November Voice is full of great advocacy ideas that you can use in your chapter. Be sure to check it out! (

Connecticut CSTA (CTCSTA) members work hard year-round to shine a bright light on CS across the state and to provide opportunities for students. Real progress and change requires many strategies and persistence. We hope that this list of our focus areas will inspire you to create a plan to advocate for CS education in your school, district, and state.

  • CSEdWeek Activities: CTCSTA starts planning CSEdweek activities during the first meeting of the school year. Ideas are shared and every CTCSTA member commits to plan and execute at least one activity. At the very least, all members participate in the Hour of Code.
  • Member resources: We have used the opportunities provided to two of our members as K5 Affliates to introduce CS into elementary schools.
  • Government:
    • We apply to the Governor’s Office in late October for an official statement in support of CSEdWeek. Last year, our members met with members of the Connecticut General Assembly (CGA) and were fortunate to get a bill written to support CS in Connecticut. Our members made presentations to the Education Committee of the CGA and the bill passed and was signed into law on June 23, 2015. Because of the passage of Public Act 15-94 (, Connecticut schools are required to introduce CS by the next school year.
    • We also garnered support from the Connecticut State Department of Education, where five of our members serve in the newly created Computer Science Advisory Committee. This committee is exploring ways to bring CS to all Connecticut schools (
  • Curriculum: The Mobile CSP project, funded by NSF and led by Professor Ralph Morelli of Trinity College, has expanded access to CS in many high schools. The curriculum has been very widely received in Connecticut and Mobile CSP teachers are strong advocates for CS in other schools and districts.
  • Partnerships: CTCSTA has a strong relationship with the Connecticut Education Association (CEA) since many of our members belong to the CEA. CEA supports bringing CS to all Connecticut schools and blogged about Mobile CSP training (org/2014/08/25/students-teachers-and-school-districts-benefit-from-computer-science-professional-development/) to their 43,000 members. In the past, many CTCSTA members have planned activities with community organizations such as the Girl Scouts. During CSEdWeek 2014, we jointly hosted a “Women in STEM-C” event that brought together about 100 young girls to enjoy STEM activities and create apps. The Lieutenant Governor attended the event in support of increased access and diversity in computer science ( We continue to reach out to schools of education such as the NEAG School of Education at the University of Connecticut and hope to form a relationship that will help them include CS in their teacher education program. Other partnerships include:
  • CTCSTA supported the Connecticut Science Center in organizing #BeautyByMe Girls-Only Hackathon (
  • CTCSTA supported the YouMedia Group at Hartford Library in the development of their CS program (
  • CTCSTA worked with AAUW ( to host a CS program for girls.
  • CTCSTA is working to bring the Technovation Challenge to more Connecticut girls. (
  • The number of girls receiving the NCWIT Aspirations Award continues to increase in Connecticut because of the work of CTCSTA members.
  • CTCSTA members support the work of Random Hacks of Kindness Jr. (

Our experience shows that CS advocacy benefits teachers as well as students. CTCSTA members who engage in advocacy in their districts are recognized as leaders. Jackie Corricelli (Conard High School), who led her entire school (1500 students) in the Hour of Code, received $10,000 from for her class. She also received the Presidential Award for Excellence in Math and Science Teaching. Melissa Fearrington (Simsbury High School) trained elementary school teachers in her district to introduce the curriculum (Courses 1-3) to their students and was recognized as the Teacher of the Year.


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:

Less than a week to go before I can start looking at the submissions for CSTA 2016

Less than a week to go before I can start looking at the submissions for CSTA 2016.  The submission deadline is October 1!

If you are reading this you probably teach computing. You probably also have (at least) one special practice or bit of curriculum, or general teaching approach that you think works really well for you. That it works well for you means it is worth sharing with other computing teachers at CSTA 2016. We’ll be meeting next July 10-12 in sunny San Diego!

Submitting a proposal is easy. Just go to the conference portal (, click the “HERE” link in the “For authors:” section, read the legal stuff about expectations, and start entering your proposal. You can check the system out without having to sign up or anything. (I always look at the information they want and write it up in a text editor, then copy and paste it into the web page.) I can’t guarantee your proposal will be accepted but it certainly will get serious consideration.

You might also consider volunteering to review submissions. That goes double for folks who have attended CSTA some time in the past. To volunteer to become a reviewer, please complete the following form: by September 27. If you have questions, please contact:

I’ve had the privilege of being involved in the planning of all the CSTA conferences. Back in the old days a bunch of knowledgeable people and I would get together and identify topics and speakers, which is impossible with the size of the conference today. It would also make for a less diverse, energetic, and useful to participants conference than we get with proposal submissions and peer review.

So, please consider submitting a proposal or volunteering to review. You can propose a 20-minute session, a 60-minute session, a 3-hour workshop, or a birds-of-a-feather.

I look forward to seeing your proposal!

Thank you,
Philip East
CSTA 2016 Program Chair

Computer Science: Dictating Careers in Digital Technology

The Computer Science Teacher Association’s Executive Director, Mark Nelson was recently featured in MediaplanetUSA’s “Careers in Digital Tech” campaign to inspire students to pursue careers in digital tech. The campaign highlights companies that are evolving and hiring the next great tech professionals. Providing tips and advice on the best path to take in order to be successful in digital careers from industry professionals themselves. The campaign was distributed in a centerfold of USA Today on September 4, 2015, and can also be viewed here: