In this episode, we talk with Mark Guzdial, Professor of Electrical Engineering and Computer Science, with a courtesy appointment in the School of Information at the University of Michigan.

You can find this episode’s transcription down below!

Listen to us on Apple Podcasts, Stitcher, Spotify, or wherever you get your podcasts.

You can also download the episode directly here.

Be sure to follow us on social media! You can find us on Twitter and FaceBook!

Summary

Our conversation focused on live coding, which is programming in front of the class as the students would program. Mark emphasized that the most essential part of live coding is modeling process. The second part is modeling how to manage mistakes. And the third is to create opportunities for students to make predictions.

For his “something awesome in computer science,” Mark talked about how he loved that computer science can be anything else. That computer science can look like and behave like any other discipline.

Mark’s Too Long; Didn’t Listen (TL; DL) broadened our original conversation by pointing out that, while live coding is useful, it’s one method among many and not necessarily the most important one. Other teaching methods he thought were also important included peer instruction, contextualized computing education, and generally, to start with a problem.

Continue reading →

In this episode, we talk with Amy Ko, an Associate Professor at the University of Washington Information School. She directs the Code & Cognition Lab and studies human aspects of programming.

You can find this episode’s transcription down below!

Listen to us on Apple Podcasts, Stitcher, Spotify, or wherever you get your podcasts.

You can also download the episode directly here.

Be sure to follow us on social media! You can find us on Twitter and FaceBook!

Summary

Our conversation focused on how to teach students to debug, a skill many of us undoubtedly struggle to get our students to do effectively. Amy suggests: step 1 is to have students articulate what is happening versus what should happen (current output versus correct output). Step 2 is brainstorm different ways (hypotheses) that might be causing the discrepancy and exploring each idea to see if it is the cause. If a student runs out of ideas before they find the bug, go back to step 1 and confirm they understand what should and should not be happening.

When asked to share something awesome in computer science, Amy talked about her interest in computer science history and Donald Knuth. Knuth is one of the originators of many core algorithms in computer science. He also spent 10 years cataloging every mistake he made while working on the typesetting programming language LaTeX. So his interests were broad and he also wrote bugs!

In Amy’s Too Long; Didn’t Listen (TL;DL) she emphasized that debugging is a primary skill and is something we should teach. And we are starting to find ways to teach this skill.

*This interview has been edited to reflect Amy’s blog post announcement titled “I’m trans! Call me Amy.”

Continue reading →

In this episode, we talk with Dan Garcia, a teaching professor at UC Berkeley in the EECS Department. He was selected as an ACM Distinguished Educator in 2012 and ACM Distinguished Speaker in 2019. He has won all four of his department’s computer science teaching awards.

You can find this episode’s transcription down below!

Listen to us on Apple Podcasts, Stitcher, Spotify, or wherever you get your podcasts.

You can also download the episode directly here.

Be sure to follow us on social media! You can find us on Twitter and FaceBook!

Summary

Our conversation focused on designing exams, which he boiled down to his five-finger rule: (1) material coverage, (2) reasonable time, (3) range of difficulty, (4) variety of question types, and (5) ease of grading.

His “something awesome in computer science” highlighted his mentors Mike Clancy and Brian Harvey, who are both emeritus teaching professors at UC Berkeley. Mike taught him about having a variety of question types on his exams. While Brian taught Dan his philosophy about grades and grading in general.

Dan’s Too Long; Didn’t Listen (TL; DL) summarized this five-finger rule into an excellent short sound bite.

Continue reading →

In this episode, we talk with David Malan from Harvard University, Professor of the Practice of Computer Science in the School of Engineering and Applied Sciences. He teaches Computer Science 50, Harvard University’s largest course, with our conversation focusing on CS50 tools.

You can find this episode’s transcription here!

Listen to us on Apple Podcasts, Stitcher, Spotify, or wherever you get your podcasts.

You can also download the episode directly here.

Be sure to follow us on social media! You can find us on Twitter and FaceBook!

Summary

In this episode, we talk with David Malan from Harvard University, Professor of the Practice of Computer Science in the School of Engineering and Applied Sciences. He teaches Computer Science 50, Harvard University’s largest course.

Our conversation focused on CS50 tools. An overview of the tools is in a YouTube video David provided. We spent most of our time talking about help50 and style50. Help50 is a tool that, when fed error output, returns a suggestion or question a student should focus on to help interpret the error output. Style50 is a tool to help students fix the style of their code by highlighting what to change. However, David emphasized that he wanted the tool to require the student to change the code themselves.

When asked about something awesome in CS he’d like to share, David talked about containerization, especially tools like Docker. In CS50, they use containers on both the server and client-side. He finds they are a great way to package up everything for students.

His Too Long, Didn’t Listen (TL;DL) focused on encouraging fellow teachers to see if someone else has already created an educational tool that would fit their needs rather than reinventing the wheel. Continue reading →