Bard College is not a technical research university. In fact, when students arrive on campus, most say they’ve had no experience with computer science.
Professors Keith O’Hara and Sven Anderson aim to change this during students’ first week on campus. Every student starts their liberal arts experience with the Language and Thinking program in which O’Hara asks them to think, express ideas, and create an artifact with code.
Anderson and O’Hara’s novel pedagogy makes programming accessible and appealing to philosophy majors and poets. Here are three of their methods to try with your nontechnical students.
“The mathematician, like the poet, works only slightly removed from pure thought-stuff. He builds his museums in the atmosphere, from atmosphere, creating by toil of the imagination.”—Fred Brooks, mathematician
Keith introduces his class to the world of code by using JS Bin to remix HTML pages. Then students build confidence by seeing the direct output of their changes as they work. First they change a link, then the stylesheet, then work up to adding their own graphics. In the first workshops, they also learn how to use GitHub to host media files from fellow students.
We can use code to speak to machines, to each other, and to the world around us. To prime students to think about these complex relationships, O’Hara points to the first chatterbot ELIZA, a parody of a psychotherapist as a human-machine communication system. Humans input their thoughts and feelings, the machine responds to their input, and the relationship blooms out of the design of the software.
In a second workshop, students write algorithms to generate poetry, make a robot sing and dance, or create virtual fish for a group fish tank.
In these workshops, Keith provides clear and functional code for students to customize and enhance.
In these coding studios, students were exposed to how computing can be the ultimate medium—the meta-medium—allowing us to express ourselves in new ways with motion, sound, graphics, and text.
In the first assignment, Keith asks students to collect and share URLs from a free-write. To help them understand how link structures work, he gives students balls of yarn. Then they toss yarn around the room to show connections between their sites.
Later, they exchange wooden nickels to explore the algorithm that powers Google Search, sharing their “money” with those the sites they link to and an instructor who further divvies up the pot.
The wooden nickels act as currency for power or authority; the exchange of these nickels simulated how power is distributed ad accumulated in the network.
What is the impact of these creative assignments? And why would Bard implement a computing element in their orientation?
Keith’s answer: to change attitudes towards computer science. To make significant strides in the diversity of computing, we need to connect computing to other disciplines, like art and biology.
First impressions are critical, and we expect that this brief exposure to computer science will have its most signicant impact on students when they make decisions about whether to engage computing in courses and employment opportunities. An increased familiarity with computing may allow them to entertain it as part of a viable pathway for their future.
GitHub presents Field Day—a one-day unconference for leaders of technical student communities. Students will share how they build communities, learn from each other’s successes and mistakes, and explore how they can collaborate in the future. We’ll spend the day focusing on how our summer internships in the San Francisco Bay Area can benefit our respective communities at home.
Field Day is a flexibly structured, student-run event. Attendees drive most of the content, and you’ll find students giving lightning talks and leading discussions on their experiences.
If you run a student tech club or if you’re actively involved in your school’s tech scene, and also happen to be in the Bay Area this summer, we’d love to welcome you at GitHub HQ on July 29th.
Professor Chris Lupo has taught at California Polytechnic State University for eight years and recently revamped his upper-level Architecture course using GitHub Classroom. In this post, he shares his workflow for deeper insight into student work, efficient debugging, and community support. </strong>_________________
At California Polytechnic State University, the motto is “learn by doing”, so it follows that students learn with real-world tools, rather than with board work and problem sets.
In group work, we do a lot with Raspberry Pi and students get into the habit of making sure they push to get it on their other systems, or so their partners can download changes. The flow encourages strong development habits. Push early, push often—that kind of thing.
Chris uses Classroom to distribute starter code and create individual and group assignments.
Chris uses Classroom, GitHub’s collaboration features, and Raspberry Pi to work with students when they get stuck. Here’s a quick overview of his workflow:
Quickly access a student repository. Assignments set up through Classroom automatically add Chris as a collaborator, and the dashboard clearly presents a list of student work.
As soon as students click an “invitation link” from Chris, Classroom creates a new repository for them. Here’s the output from GitHub Classroom in Chris’s course.
Clone and comment in-context. Students can see where changes need to be made and leaves comments directly in their code.
Test the fix on his own Raspberry Pi.
Push the code back to the student’s repository, with fixes and comments.
This workflow solves the cumbersome task of transferring files. Both instructor and student can work from their own environments, instead of switching between computers.
I can clone their work, connect to the Raspberry Pi that I have access to, and run their code. From there I can work with them directly on their code base to show them what steps to take and how to move beyond their current problem. After we work together, I can push the code back to them when we’re done.
I have access to everybody’s code all the time. I’ve not had that capability prior to using GitHub Classroom.
When Chris has questions about Git or best practices, he reaches out to the GitHub Education Community for advice from other teachers.
I’ve also found the community really helpful for support. For example, I learned about a script named orgclone that was really useful for me in repository management.
Even though Git and GitHub take some time to get students up to speed, Chris says students are happy with the experience now that he’s implemented GitHub.
Feedback has been very good. There is a little bit of a learning curve for people who have never used Git before, but they all said it was worth it.
Adapt Professor Lupo’s assignments:
Use Raspberry Pi assignments for a university setting:
School may be (almost) out for summer, but we’re still adding to the Student Developer Pack. Sentry is now offering error reporting to new and existing pack members—send up to 500,000 errors per month and enjoy unlimited projects and members.
Sentry provides real-time error tracking and crash reports for your web apps, mobile apps, games, and more. With Sentry, you get all the information you need to identify, reproduce, fix, and prevent bugs—from the full stack trace and the contextual details of the exception to a trail of events that led to the issue and release and commit data—so you can set priorities, triage proactively, and make sure errors don’t affect your user’s experience.
Our Student Developer Pack gives students free access to the best developer tools from different technology companies like DigitalOcean, Datadog, Stripe, Travis CI, Sentry, and more. Oh yeah, and all students get free unlimited private repositories—perfect for summer projects.
Feedback is essential to the learning process. Input from an expert at the right time can make all the difference in a software project.
In past programming classes, Professor John David N. Dionisio’s printed out student assignments and commented on their code by hand, directly on the paper. Students said it was easier to understand feedback when it was in context.
When he started using GitHub’s interface to communicate with his students, he found he could introduce version control even earlier in his courses. As a result, Dionisio’s students have the opportunity to use industry tools from day one of their studies.
The web app has made development more accessible sooner, letting freshmen get in on it without having to learn everything about version control. The comment threads and the ability to comment line by line tightens the feedback loop. Now printing is not really necessary because you can just look at the diffs and make comments about it.
Working with a live repository, he knows students will see it exactly as he does. And GitHub Classroom’s dashboard lets him share a link to the full assignment and view who has accepted it.
For students it’s easy to get started. With Classroom, I can now basically deliver a complete package, including the instructions. Instead of things being sort of scattered, and having the student accumulate it together. Documentation is there, sample code is there, and configuration files for continuous integration are there.
Every student picks it up, and if they’re off and running. They can commit, and you can look at their histories. Students have their own private repo that they would build their files on.
Until he started using Jenkins to flag formatting issues, Dionisio had to provide his students with a flood of stylistic comments.
Now, instead of focusing on bad indentations and incorrect spacing, Dionisio can give more qualitative feedback on redundancies and best practices. His comments have evolved into more of a conversation.
I frequently give feedback in terms of design and structure, like “I would’ve instead written this line this way.” And since GitHub comments are in Markdown, they’re easy to read and very clear.
You can really format the code and convey your ideas. The display thread helps the student respond. It allows very context-sensitive, context-aware discussions for finer points of code.
A before and after of Dionisio’s feedback—from manual markup to precise and contextual feedback using GitHub’s review process.
A few additional examples of John’s feedback to students.
In industry, developers almost never start from scratch. To be successful, they need to be able to ask questions about code, to understand what’s going on, and recognize the strategies of other developers. In the classroom, pull requests work to build those skills:
Pull requests with Markdown support are a great place to have a consistent thread of feedback. And this clear signal of, “I now accept your work”—like building a relationship of submitting your work for someone to look at, and after we workshop it for a little bit, I now accept your work.
Anything that helps me simulate tools and practices they will encounter later is always of help.
This is a post in our “Teacher Spotlight” series, where we share the different ways teachers use GitHub in their classrooms.