This Birds of a Feather (BoF) session offers a space for SIGCSE TS attendees to explore the interactions between a Biblical worldview and their teaching, research, and general view of technology. Our session is dual-purpose: (1) create opportunities for Christians and those interested in Christianity to connect and build a supportive community, and (2) spark thoughtful discussions on how a Christian perspective can shape ethical considerations, teaching practices, and broader challenges in CS education.

This Birds of a Feather (BoF) session offers a space for Christians at SIGCSE TS to freely explore the interactions between a Biblical worldview and their teaching, research, and even general view of technology. Our session is designed with a dual-purpose: (1) create opportunities for Christian attendees at SIGCSE TS to connect and build a supportive community, and (2) spark thoughtful discussions on how a Christian perspective can shape ethical considerations, teaching practices, and the broader challenges in CS education. Participants will have the chance to engage with peers who share similar values, exchange ideas on integrating faith into their work, and reflect on the influence of a Christian worldview in navigating the complexities of technology and education. We will also facilitate ways for attendees to continue the conversation post-conference through a dedicated mailing list, helping to foster ongoing connections, collaboration, and encouragement.

Problem planning is a fundamental programming skill, and aids students in decomposing tasks into manageable subtasks. While feedback on plans is beneficial for beginners, providing this in a scalable and timely way is an enormous challenge in large courses.

In this Birds of a Feather (BoF) session, we aim to foster a safe and open environment that allows CS education (CSEd) graduate students to share about their graduate experiences and learn from each other about graduate school, conducting research, and navigating the inherently multi-disciplinary space of CSEd. We have two main goals: (1) create specific networking opportunities between CSEd graduate students attending SIGCSE TS (hereafter just "SIGCSE") in order to foster a community of support, and (2) elicit discussions on the triumphs and tribulations that come as part of being a CSEd-focused graduate student. We plan for all attendees to leave our session with connections to fellow CSEd graduate students from other institutions (through email and a dedicated Slack) and a greater awareness of the community available to them within CS education research.

Program planning is the process of splitting a problem description into subtasks that can be solved independently, then composed into a solution. While much has been written about planning since the 1980s, little research looks at modern contexts such as programs to process data tables. Tool support for this sort of planning is even rarer. As part of a project to develop such tools, we have run two studies to try to identify steps, representations, and interactions that would support novice university students in planning and programming multi-task programs that process data tables. This experience report describes our observations so far, while also raising questions about how to make planning useful for students.

Background and Context. Program planning has been a long-standing and important problem in computing education. Finding useful primitives for planning and assessing whether students are able to understand and use these primitives remain open problems. We make progress on this problem by using higher-order functions (hofs) as planning operations. Not only are hofs increasingly prevalent in computing broadly, some data science programming sources also recommend their use in planning solutions to data-processing pipelines, giving our task additional applicability.

In teaching students to program with compositions of higher-order functions, we have encountered a sharp distinction in the difficulty of problems as perceived by students. This distinction especially matters as growing numbers of programmers learn about functional programming for data processing. We have made initial progress on identifying this distinction, which appears counter-intuitive to some. We describe the phenomenon, provide some preliminary evidence of the difference in difficulty, and suggest consequences for functional programming pedagogy.

Rust is a programming language that simultaneously offers high performance and strong security guarantees. Safe Rust (i.e., Rust code that does not use the unsafe keyword) is memory and type safe. However, these guarantees are violated when safe Rust interacts with unsafe code, most notably code written in other programming languages, including in legacy C/C++ applications that are incrementally deploying Rust. This is a significant problem as major applications such as Firefox, Chrome, AWS, Windows, and Linux have either deployed Rust or are exploring doing so. It is important to emphasize that unsafe code is not only unsafe itself, but also it breaks the safety guarantees of ‘safe’ Rust; e.g., a dangling pointer in a linked C/C++ library can access and overwrite memory allocated to Rust even when the Rust code is fully safe.