Statement of Teaching Philosophy
As a student in Computer Science, I found the constructed layers of the field captivating, and was motivated to peel them back one by one. I remember the gratification when I had finally pieced together all the layers underlying my C program--- from the compiler to individual CPU instructions. As a TA, I found it deeply rewarding to help students along that same path, to their own moments of insight. Along the way I learned a few guiding principles: the importance of listening and asking questions, cultivating specific communication, and iterating based on feedback.
As a TA in office hours, I would spend more time listening than speaking. Students would come through the door, panicking about an upcoming deadline, and begin rattling off the errors they were running into. The joy of having experience programming is knowing that those errors are solvable; in fact I'd probably helped 3 students earlier that day solve the same parsing issue. This leaves space to let the student work through the problem themselves. Asking questions is more effective than offering a template of the exact code I would have written, and lets students develop their own intuition. Having seen their code, I could probe their logic --- what do they think the inputs and outputs of this problem are? What steps are there in the overall flow of the program? What functions did they choose to break it into? By asking these questions, I guide them to the intuitions I've learned over time for good program design. The discipline is in never stating outright what the student could otherwise grow to realize through their own trial and error. The courses in this department have enough space for a lot of that experimentation and failure, and difficulty only serves the ultimate goal of strengthening the programmer's intuition. I am there to guide them towards the questions that are important to ask, so they can learn the habits of the thinking process.
One of the first lessons I learned in Computer Science was the importance of specificity--- writing instructions to be executed by an unthinking machine will quickly bring that to the fore. But specificity is also critical for communicating about and solving difficult technical problems. I've hosted lab sessions, supplemental instruction, and exam reviews. Whether it is debugging a program or reviewing a test question they missed on an exam, the key is working to have the student clearly articulate their perspective. This process serves two purposes. First, helping me see where they are in their understanding, and what gaps need to be addressed--- the equivalent of testing a program from every angle to find a bug. With students of varied backgrounds and levels of experience, it's important to calibrate to those as well, building a picture of who the student is. Second, it gives them practice in the crucial communication skills that will drive their later success. If they are capable of clearly communicating the problem, I know they are on track to solve it. This cycle of explanation and correction is what guides them towards being specific in their language, so that along the way they learn the value of precision.
As a Course Coordinator, I got a broader view behind the scenes of what makes a course tick. I was responsible for a team of TAs, and managed communication between instructors, TAs, and students. I had the opportunity to work through the re-implementation of interactive labs for CSc 120, a feature that had been missing for some time. Creating instructional materials for the sessions and guiding the protocols that would be followed, we worked from student and TA feedback iteratively each week. Hearing from TAs that a particular question was a sticking point, we would make edits and re-format. We gathered whether students were engaged in a particular session, confused, or the content was dragging on too slowly. The outcome from a particular session would guide our process for the next week, and change the structure of that particular session for future semesters. Even in a large course with hundreds of students, it was important to work backward from the single interactions that were happening at each lab session to make sure we were progressing and teaching effectively.
Throughout the degree, we guide students through the layers of abstraction and decisions that are made in creating computer systems and software. Our field is defined by decisions made by generations of creators before us. There are the foundations of CPU design, programming languages, and operating systems, there are layers of creation on top of those: applications to graphics and machine learning, data science, and other tools for applied problem solving. There are engineering decisions, trade-offs, and cultural conventions nestled at every layer. As a teacher I see myself as a guide to this landscape, giving students the communication skills, technical knowledge foundation, and intuition that allows them to find their place.