Making with Code

Practices #

These are our classroom practices and our pedagogical approach Computer Science education.

Tools #

We believe learning to utilize computer science tools is an important way that students connected with and contribute to the world of practicing computer scientists. By learning to use tools that are commonplace in industry, academia, and open-source computer science practice, students are both more conneccted to the culture of computer science and more prepared to take one roles as computer scientists.

Technology Used Across Both Courses #

  • Python
  • Visual Studio Code
  • Terminal, including Xcode Command Line Tools
  • git and Github
  • Jupyter Notebooks/Google Colab

Whiteboards #

We reccomend having a whiteboard at each student’s desk, so you can develop pseudocode together that then stays with the student. It also allows you to quickly jot down tips or specific line numbers for students to focus on, while allowing you to spend more one-on-one time with lower level students.

In general, we’ve found writing to be a super useful tool when coding - and whiteboards can be helpful impermanent tool to foster creativity and logical thinking.

Assessment #

The course utilizes a comprehensive meta-cognitive self-assessment as a guide for learning priorities and for learning assessment.

Feedback #

We provdie asynchronous feedback to each student on their code. This is facilitated either through Git commit comments or through comments in their Google Doc Code Log.

This allows us to provide personalized feedback on each student’s work, without spending too much class-time with initial one-on-one checkins.

Assigning competence #

Create practices by which students are seen as experts.

  • One useful practice that embodies this: when helping people from the queue, follow up helping a student by saying, “It looks like you understand this issue pretty well now. When I see another student having the same problem, may I send them to you for help?” That way, the student solidifies the understanding by teaching someone else, and gets to be an expert at that issue. You can then keep directing students to that expert for days.

Authorship #

It is very important that each student develop as an author of her code.

  • Teachers will never touch a student’s keyboard. Instead, sit with the student and guide her in what to do. It can be helpful to bring another laptop, increase the font size, and type out code for the student to copy. This is also when the whiteboard at each desk is extremely usefl. (The only exception would be if there is some error at a deeper level than the student would be expected to know about, eg incompatible package versions installed.)
  • We encourage students to help each other, but never to code for each other. The aim is for student’s to share knowledge and depend on each other for help.
  • If studnets find useful resources online, we ask them to cite the source as a comment in their code.

Funds of knowledge #

The idea that we will look at students as having lots of resources they can deploy in their learning (rather than viewing them in terms of their deficits). This also means we need to let go of the idea that we’re solely in the position of determining what’s worthwhile in CS. Our students are going to create things that are worthwhile and successful on their terms, not ours. We are going to support them, while also being warmly demanding. This is not a radical proposition, especially in CS: It’s such a new field that nobody really knows what CS is or what its boundaries are. If we’re finding ways of working that are effective, thinking about ideas that feel powerful, and making things that feel like they matter, then we’re doing the right thing.

Group Work #

Small groups are an important context for high-quality disciplinary talk. When students get to choose their groups, they can take advantage of existing social relationships. However, this can create in equities (the strongest students cluster together) and can also bring social tensions into the classroom.

  • Our recommendation is to always assign seats and groups, change groups regularly (perhaps every lab), and allow students some private input (eg “I really don’t get along with X”).