Shriram Krishnamurthi on Designing Computing Curricula for Real Classrooms

When someone asks engineers how to teach computing, they often immediately recommend a language: Scratch, Logo, Haskell, JavaScript, OCaml or something else. But when someone asks how to build software, engineers usually first ask what the software is for. Curriculum design deserves the same discipline.

In an engineering problem we ask about goals and constraints before choosing methods. Education often reverses that order and starts with a preferred method. I want to approach curriculum design as I would approach building, administering or running a system.

Obvious constraints include students' ages and prior experience, whether a course is required, how often it meets, and the number of students. A method that works for two learners may not work for a classroom of thirty, and a third year of the same tool may not address what students need next.

Other constraints may be less obvious to technologists. Does the classroom have reliable internet? Is the teacher new to programming? Can the students type? Can students with visual or motor disabilities use an interface that depends on dragging blocks into precise positions?

Access to computers matters both at home and at school. A student who has no computer at home cannot be expected to do computer-based homework; a curriculum that assumes constant machine access will not fit a school with an hour a week in a lab.

The audience suggests goals including connecting computing to real life, developing reasoning, asking better technical questions, gaining confidence, preparing for jobs and transferring knowledge to other domains. These are all possible goals, but they do not lead automatically to the same curriculum.

In Bootstrap, three goals drive our work: equity, rigor and scale. We want substantive learning, not a watered-down curriculum. We also need methods that can reach many schools, even when that requires choices different from what I can do with selected students at Brown.

Equity matters because computer science has a representation problem. I want to assess how our decisions affect equitable learning. Let us use the three goals to examine three common delivery avenues: required courses, electives and after-school programs.

A required computer science course sounds straightforward, but scaling it raises real issues. Teachers may need certification, qualified teachers are difficult to recruit, and industry competes for people with computing skills. Schools also need time in an already crowded curriculum.

At national scale, staffing schools and paying salaries and benefits would cost billions of dollars a year, by my rough calculation. Some schools can implement a requirement well; others cannot find or afford the necessary staff. If everyone must pass to graduate, I also worry that rigor can come under pressure.

An elective avoids a universal requirement but raises equity concerns. Existing participation in optional CS courses is heavily skewed, in his account, toward white and Asian boys. The composition of an existing class can itself influence who feels that the course is for them.

Schools must prioritize graduation requirements such as mathematics and literacy. If a student fails algebra, retaking it can displace an elective; another failed requirement can remove still more room. A student who might have connected with computing may never have the opportunity to choose it.

Differences in pass rates connected to race and class can compound the problem. Elective quality also varies: some schools do an exceptional job, others much less so. I see that disparity later among students entering introductory courses.

After-school programs have their own barriers. Students may need to earn money or care for siblings, and volunteers can be difficult to retain. Bootstrap began after school and had a relatively strong volunteer return rate, about 70% in our experience, but that did not solve the attendance problem.

Across our after-school offerings, students attended roughly half the sessions on average. STEM learning builds incrementally, so missing different classes left students at different points. By the end of a ten-week program, instructors were effectively providing a customized sequence for each student.

Even reliable attendance would not remove every obstacle: students are tired after school, and rural areas may lack nearby pools of volunteers. I do not claim to have solved all these issues; equity, rigor and scale remain hard in that setting.

Consider a fourth option: integrated computing. If our premise is that everyone should learn computer science, that is not the same as saying everyone must take a separate computer science class. If computing is useful across disciplines, we can bring it to students in the subjects they already study.

Algebra is a particularly important starting point. It is a gateway for many later fields, a graduation requirement and a high-stakes subject. Krishnamurthi argues that it is also a point where students can shift from saying mathematics is hard to believing they cannot do mathematics.

An audience member stresses that difficulties with arithmetic and fractions may begin earlier. Krishnamurthi agrees the situation is complex but emphasizes the transition to abstract objects and their properties: a function such as f(x) = x² is not simply another equation with a number to solve for.

Integrating computing into algebra can reach students already required to take the subject. It can also work through existing teachers, courses and professional organizations instead of requiring an entirely new network. Algebra already provides a setting where rigor is expected.

That is not a free lunch. The central difficulty is transfer: a learner must apply a skill learned in one context to another. Krishnamurthi identifies explicit instruction, deep structural similarities and a process for performing tasks as important ingredients.

Transfer can be surprisingly fragile. He describes research in which students understood a physical situation involving a ball dropped through a short pipe but struggled to apply the idea to a drop from a tower. A curriculum cannot simply assume that a connection obvious to an expert will be obvious to a student.

Programming and mathematics can use the same words for different concepts. A programming function may have side effects or no returned value, while an algebra teacher expects a mathematical function to satisfy the vertical-line test. A mutable programming variable also behaves differently from an algebraic variable.

Numbers can create another mismatch. Integer division, overflow and underflow can make a computer's result differ from the mathematical result a student expects. For a learner already struggling with fractions or algebra, those details can obstruct transfer rather than illuminate it.

Technology choices therefore matter partly because they prevent bad mismatches. Bootstrap uses functional programming and number systems chosen to align with the mathematics being taught. But language alone is not enough: students also need a process for approaching a problem.

A blank programming screen can be intimidating. Students must turn a problem statement into unfamiliar code, and when they get stuck they often add more code rather than reorganize what is already there. By the time they ask for help, the only diagnosis may be: “My program doesn't work.”

Other design disciplines use multiple stages, views and representations before producing a final artifact. Mathematics teachers similarly try to help students see a table, graph and symbolic expression as different representations of the same function.

Bootstrap uses worksheets to give students a structured design process. They write a contract and purpose, work through concrete examples, then abstract from the examples into code. The sequence gives students a way to move from a blank page toward a solution.

Computer scientists might call the pieces type specifications, test cases and code. Math teachers recognize domain and range, input-output tables and symbolic form. Connecting these representations explicitly reinforces the relationship between the subjects.

This staged support is scaffolding: each step helps the learner reach the next and can reduce frustration. The connections need to be made visible and checked, not left implicit in the hope that students will discover them on their own.

In Bootstrap Algebra, middle- and high-school students with no prior programming experience design a video game. Krishnamurthi says that after roughly 20 hours they have a working game and have learned computing and algebra. He says the team measures learning and has conducted controlled studies rather than treating instruction alone as proof of learning.

Language, curriculum and pedagogy depend on one another. For example, students write examples in the source; requiring them to learn a separate testing framework just to express two examples would weaken the link between mathematics and programming.

At a launch party, students present their games and conduct code reviews. They answer questions about their code in front of an audience; students also explain mathematical formulas. Krishnamurthi sees both as ways to build confidence and make a connection between mathematical and software reasoning.

He attributes much of the program's reach across demographic groups to teaching within algebra classes that students already take. He then turns to a data-science curriculum developed using the same broad approach, with teachers from mathematics, statistics, technology, social studies and other fields.

In the data-science course, students ask a question and produce a report; a program is part of the investigation rather than the entire product. Programming over a dataset adds another tool alongside existing methods such as literature reviews and surveys, rather than replacing those methods.

The subject also creates an opportunity to discuss harmful social effects of computing, including the issues raised in Weapons of Math Destruction. The curriculum uses Pyret, a language designed to support tables and queries, so students can ask meaningful questions without first mastering loops or recursion.

Bootstrap also works on physics in partnership with physics teaching organizations, while its algebra work involves mathematics educators. Krishnamurthi emphasizes collaboration with the professional communities already responsible for teaching those subjects.

The program's approach is teacher-centric. Teachers need professional development, workbooks and support for the problems they actually encounter in classrooms. A clever programming environment alone is not enough; technologists must understand the constraints under which teachers work.

He says students can develop ownership of a project with a short opportunity to personalize it, rather than needing unlimited freedom at every stage. A structured curriculum and creativity are not necessarily opposites.

The worksheets are a key part of the transfer strategy. He recounts cases where computer science teachers removed them because paper seemed out of place, then found the intended transfer did not occur. Math teachers were often more comfortable with the structured process.

Solving real problems includes administrative and practical details. If a school has only one hour of internet access a week, telling it to buy more internet does not solve its problem. The curriculum has to work with the conditions teachers face.

Krishnamurthi summarizes Bootstrap as three connected sets of choices: the goals of equity, rigor and scale; the means of pedagogy, language and curriculum; and the avenues of algebra, data science and physics. He believes this combination can produce stronger computing education.

Asked about younger students, he says Bootstrap Algebra and Data Science are already used in some middle schools. The team was also designing Bootstrap Junior specifically for middle school and building a block-based environment to reduce typing barriers.

He says the block environment was being co-designed with a blind programmer, with screen-reader accessibility and ARIA compliance as explicit goals. At the time of the talk, the team had worked on it for about a year and a half and expected more development before completion.

An audience member asks about involving parents at home. Krishnamurthi says Bootstrap has been cautious for equity reasons: some parents lack time or resources, and making home participation central could disadvantage their children. He welcomes ideas for navigating that tradeoff.

A participant reports seeing strong interest in computing among parents in economically disadvantaged Brooklyn communities. The discussion distinguishes interest from the resources and time available to support a program at home.

Another audience member asks about preparing future mathematics teachers to use technology. Krishnamurthi says the team was beginning to work with pre-service teachers and teacher-training programs, including existing efforts in Utah, with hopes of expanding to other states.

Asked what worries him most, he says integrating computing into mathematics is risky because schools are judged on math outcomes and may fear that an intervention will lower scores. The team must persuade skeptical educators while respecting the stakes for schools and students.

An audience member asks what comes after an introductory program. He describes Bootstrap Reactive and other extensions that go deeper into computer science and data structures, while noting the small team's limited resources. He does not claim to have solved the broader national continuity problem.

He sees both costs and benefits in the lack of a unified US curriculum. Local variation makes adoption difficult, even when a program works, but it also allows different places to experiment. Evidence alone does not ensure that schools will adopt a successful approach.

Asked about long-term tracking, he says Bootstrap began as an after-school program around 2007 and later focused on in-school use. Longitudinal data is difficult to collect: schools protect student privacy, and the researchers do not want to track students without making that clear.

He acknowledges that the short answer on longitudinal evidence is largely no, despite some limited studies. Schools may possess data the researchers cannot access, or the data may not exist. The distinction matters when evaluating the program's longer-term effects.

An audience member asks about teaching proof. Krishnamurthi says he is interested and is researching the question at college level first, before attempting to transfer a well-developed approach to high school.

A teacher educator describes the challenge of connecting pre-service and in-service preparation and raises concerns about mathematics training. Krishnamurthi resists reducing the problem to one cause: teacher preparation, motivation, retention and students' changing circumstances all matter.

Yaron Minsky asks whether, with a freer hand, computing should be taught as an independent discipline rather than integrated into other subjects. Krishnamurthi offers a more modest practical goal: train teachers from several disciplines together so students encounter related ideas from multiple perspectives.

Sending two teachers from one school can make a large difference, he argues. A lone teacher has no nearby colleague with whom to discuss a technical problem or classroom issue; a second teacher creates a source of mutual support. Cross-disciplinary participation can reinforce that support further.

Another question asks whether integration is merely a temporary solution as computing grows in importance. He says it need not be either integration or standalone CS. Separate courses can coexist with computing in other subjects, but students also need to learn how to apply computational ideas beyond the CS classroom.

He is interested in extending the approach toward calculus and physics. School physics often emphasizes problems with closed-form solutions, whereas many physical systems are described through differential equations and changes of state. Programs can provide another way to explore those models.

He notes that students making games in Bootstrap are already working with discrete changes over time, a connection he hopes can support later mathematical ideas. He presents this as a direction for curriculum design, not a claim that a game alone teaches calculus.

Asked what Bootstrap has taught him about university education, he returns to transfer. Students may learn programming, algorithms and big-O analysis separately but struggle to apply complexity knowledge to improve a program. The same issue arises within computer science, not only between school subjects.

An audience member points to simulations as a way to vary parameters in physics. Krishnamurthi agrees they can be useful but cautions that a computer model can diverge from the physical world. That mismatch makes the design of an effective lesson more complicated.

For example, a robot instructed to turn 90 degrees and then back may not face exactly the original direction. Explaining the discrepancy can require probability and measurement. That is useful if those are the learning goals, but it can introduce unwanted complexity when they are not.

Asked how Bootstrap could grow, he says a major need is administrative help. The small team spends significant time on calls, paperwork and coordination with education departments. More resources for that work would free educators and researchers to focus on the curriculum itself.