To address the challenges of running exams in large enrollment CS courses, we set up and operated an in-person testing center at a minority serving institution. We have run the testing center for two quarters, proctoring over 6,000 exams for eight CS courses with approximately 1,800 students. In this experience report, we discuss the motivation for the testing center, its set-up and operation, and the lessons that we have learned from our first two quarters of operation. In addition, we present student and instructor feedback regarding use of the testing center, future steps, and improvements.

CS educators have increasing interest in equitable grading, to support differing student backgrounds, perspectives, and current life situations. Our course is heavily scaffolded (one aspect of equitable grading), with points for readings, homeworks, and lab assignments, every week. All those items are auto graded with instant feedback, partial credit, and resubmissions. Previously, we did not accept late work, except for rare exceptions. In Spring 2022, following equitable-grading advice to reduce emphasis on deadlines, we allowed work to be submitted (and resubmitted) up to 14 days after target dates, with a small 1% deduction/day, with students receiving whatever max score occurred across those 14 days. This paper analyzes how students made use of this "late policy." The main finding was students did not shift all work by 1-2 weeks, as we originally feared; instead, students did most work by target dates. We found many of our 265 students only used the policy lightly (51%) or used it moderately (35%) to earn a few more points 1-2 days after target dates. Only 14% were heavy users of the policy, and they had reasonable course outcomes. Student feedback was positive, and instructors stated they saved time and energy due to reduced late requests.

Computer science instructors have long advised students that success in CS1 requires many hours, such as 8-10 hours/week outside class time, but students often don't believe it. Recently, the most-widely used CS1 learning system (zyBooks), which is web-native and records student activity data, began providing instructors with data on student time spent reading and answering reading questions, solving small homework problems, and coding the programming assignments, all online and auto-graded, representing nearly all a student's time outside class. In our 300+ student CS1 course at a large state university in Spring 2022, we required all work to be done in the zyBook and analyzed student time, including analysis relative to self-reported prior programming experience. Students who completed the class averaged 6.1 hours/week, with a large standard deviation of 2.3, and averaged a B+. Students averaged 6.9 hours in weeks 1-5 leading up to the midterm, peaking at 9 hours in Week 5. We found that over 90% of students who averaged 9-12 hours/week earned As or Bs, even those reporting no prior programming experience. Spending under 4 hours/week nearly guaranteed failing the midterm, and almost no students who spent fewer than 6 hours/week got an A on the midterm (unless they had prior experience). We also found that measuring actual time is important because students overreport time in surveys. With this concrete time data available to share with CS1 students, the hope is that future students may be more likely to allocate the time needed for success in CS1.

Coral was introduced several years ago to ease the learning in college-level introductory programming courses. Coral consists of a simple textual code language and corresponding flowchart language and a free web-based educational simulator. Previous researchers described the benefits of Coral in CS0 courses and the first weeks of CS1 courses. We previously used Coral in CS1 and enjoyed the teaching experience, due to: the simple intuitive syntax, the simulator's auto-creation of a flowchart from code, and the simulator's visualization of code and flowchart program execution. However, we wanted to ensure we weren't hurting students with the transition from Coral to C++. This paper describes our experiences of teaching Coral in a ~100-student CS1 section for weeks 1-3 versus two other sections that taught C++ only. We performed analyses to answer three research questions: (1) Do students learn Coral more easily than C++? (2) Do students easily transition from Coral to C++? and (3) Do Coral-treated students do equally well on later C++ programs? We analyzed performance on auto-graded code-writing problems in zyBooks. We did not find support for (1), but did find support for (2) and (3), with Coral-treated students easily switching to C++ and performing equally well on later C++ programs. We conclude that CS1 instructors who enjoy the early-weeks teaching benefits of Coral can do so confidently knowing that students will perform equally well later in the course.

Cheating in introductory programming classes (CS1) is a well-known problem. Various methods have been suggested to reduce cheating, but many are time-consuming, resource intensive, or don't scale to large classes. We introduced a class intervention having 6 low-effort commonly-suggested methods to reduce cheating: (1) Discussing academic integrity for 20-30 minutes, several weeks into the term, (2) Requiring an integrity quiz with explicit do's and don'ts, (3) Allowing students to retract program submissions, (4) Reminding students mid-term about integrity and consequences of getting caught, (5) Showing instructor tools in class (including a similarity checker, statistics on time spent, and access to a student's full coding history), (6) Normalizing help and pointing students to help resources. Via manual evaluation of similarity checker results on 7 held-constant labs with one instructor teaching 100-student sections, for two pre-intervention and two intervention sections, suspected-cheating reduced 62% (30.5% down to 11.5%). Because manual evaluation could be biased and is time consuming, we developed two automated coding-behavior metrics per lab -- time spent programming, and % of students with highly-similar code -- that may suggest how much cheating is happening. Time spent increased by 56% (7 min to 10.9 min), and % of students with highly-similar code dropped 48% (38.5% to 20%). We later repeated the intervention with a second instructor and different labs and achieved similar (in fact, even stronger) results, with time rising 84% (13 min to 24 minutes) and % dropping 66% (55.5% to 19%). All findings were statistically significant with p < 0.0001.

Just about everyone in the U.S., from the National Science Foundation down to local districts, has been pushing to introduce computer science concepts into K-12. Nevertheless, many students complete high school never having the chance to learn CS. We have created a summer coding camp for high-school students (including 8th graders entering 9th grade) and designed a multi-year study to assess its effectiveness as an informal learning environment, based on theories of human motivation such as Self-Determination Theory. The camp is a 1-week immersion experience, 9am to 5pm with food and activities, that introduces basic programming via MIT APP Inventor. Lecture material and in-class exercises draw upon meaningful applications, ones appealing to "social good." One unique aspect is the inclusion of professional and career development activities that engage students and broaden perspectives on CS and its applications. For example, the camp includes a college information session, alumni Skype and in-person talks, off-site visits to nearby companies, and research talks and demos by faculty. Using a pre-and-post survey design, the current study examines the effects of the camp on student self-efficacy and interest in computing, as well as general school engagement and motivation. Results confirm that participation in the summer camp increased students' self-efficacy and interest in computing, enhanced engagement in school on topics in general, and strengthened intrinsic motivation for completing schoolwork. The effects were similar for boys and girls.

Modern program auto-graders enable new CS1 approaches. Instructors can easily create new assignments, with students receiving immediate score feedback and resubmitting assignments. With such auto-graders, one approach assigns many small programs (MSPs) each week instead of one large program (OLP). Earlier research showed MSPs in CS1 yielded happier students and better grades. Our university and other schools have switched to MSPs in CS1. This paper addresses common questions about MSPs. We analyzed submissions for a 76-student section of our MSP CS1 course. Given 7 MSPs per week each worth 10 points, students needed 50 points for full credit. Students averaged 17 minutes per MSP and 120 minutes per week. Given 7 days, students on average started 2.2 days ahead of the due date, with 37% starting at least 3 days ahead. 40% of students exceeded the required 50 points per week (no extra credit was given). 50% of students "pivoted" -- switching to another program before completing the previous one. 54% used MSPs to study for exams. Students used MSPs in ways beneficial to their learning and stress reduction: spending sufficient time, completing more than necessary, preparing for exams, and pivoting to avoid getting stuck. A common concern is that MSP CS1 students will do poorly in a CS2 using OLPs. We analyzed 5 quarters of CS2 and found MSP students do fine (in fact slightly better). These results encourage use and refinement of MSPs in CS1 and other courses.

Building a sensor-based system typically requires some programming and electronics expertise. However, some applications require only basic logic transformations and/or state maintenance of sensor information. This paper describes a set of electronic blocks, called eBlocks, that enable non-experts to build basic small-scale sensor-based systems. Each block performs a particular sensing, logic/state, or output function. A user builds a system by connecting blocks together. Each block contains a hidden microprocessor executing a pre-determined low-power compute and communication protocol. A difference between eBlocks and widely known sensor-network nodes is that each eBlock has a specific easy-to-understand function, and thus does not require programming. Further, eBlocks are designed to be connected in particular configurations to create an end application, while traditional nodes form a wireless network that must be programmed to form an application. Our physical prototypes can last for several years or more on a 9-volt battery, or can receive power from wall outlets. We describe the domain of applications for which eBlocks are suitable, including being used to build complete systems or to interface with existing sensor-network compute nodes, and we summarize the eBlock compute/communication protocol. We describe experiments, involving hundreds of users of varying levels of expertise, that demonstrate how systems that otherwise would have taken weeks or more to build can be built by non-experts in just a few minutes using eBlocks.