Teaching Philosophy

Students learn best when theory is grounded in practice, and effective teaching is designed for the full range of learners in the room. My years as a researcher in industry inform how I apply the first idea. They determine which topics I prioritize and the tools I ask students to use. My goal is for students to leave my courses with the confidence to apply what they know as effective practitioners. The practices I describe here emerged from both pedagogy and personal experience, shaped by my time as a student who didn't always fit the conventional classroom and as an instructor in several settings.

I'm neurodivergent, and the conventional classroom presented particular challenges for me. Timed exams could induce a cognitive freeze. Manual computation was another problem: I have dyscalculia, and I found clerical errors accumulating in ways that obscured what I actually understood. I learned to reach for a calculator or write short scripts to demonstrate what I knew. I recall one undergraduate physics course that prohibited calculators entirely; I ultimately had to drop it, unable to overcome these cognitive challenges. Passive instruction was its own difficulty, leading to drifting attention. Manual note-taking compounded the problem, since dividing attention between hearing and transcribing often left me with pages of words I had captured but not absorbed. Effort and preparation were never the problem. It's how my mind works, and knowing that makes me slow to assume a struggling student is lazy or underprepared.

These experiences made me more empathetic to struggling students, and they changed the design of my teaching. Active learning over passive lectures, tools that reduce mechanical friction, flexible resources, and assessments that test understanding rather than performance conditions benefit every student. This is how I apply Universal Design for Learning (UDL). Having experienced the discouragement of a classroom that wasn't designed for me, I reassure students from the first day that making mistakes is part of the learning process and that struggling with material isn't a sign of inadequacy.

My classes combine lecture with readings done outside class. In a course on Object-Oriented Languages and Systems, for example, I spend little time describing the commands available in a version control tool (students can look these up) and instead focus on the best practices and the reasons such tools exist. Similarly, in a course on Software Engineering as a Human Activity, class time is spent analyzing and reflecting on material through active learning activities such as think-pair-share and informal discussions, rather than summarizing what students were asked to read beforehand. I present concepts through multiple modalities: verbal explanation, worked examples, visual representations, and video lectures and screencasts, so that students encounter the material in more than one form.

I use several formative strategies throughout class to monitor understanding in real time. In-class polls give a quick read of how the group is tracking. A backchannel chat lets students submit questions privately, lowering the barrier for those who are uncomfortable asking in front of the class. And when students work on problems, I circulate the room to observe their work directly and identify misconceptions before they compound.

For theoretical knowledge, I use exams and homework assignments. Exams are open book and open to printed notes, and calculators are permitted; computers, internet access, and AI tools are not. Because these restrictions limit the tools available, I design exams to be direct tests of understanding rather than exercises in cleverness. This exam philosophy comes from the late MIT professor Patrick Winston, who wrote of resisting "the temptation to be so clever that our quizzes test the students on how well they can penetrate our cleverness." Students should never be surprised by the material that appears on an exam; I explicitly mark potential exam topics at key points in my lectures, though the actual question may vary to some degree.

To assess practical knowledge, I use projects that require students to apply theoretical concepts to actual systems. Unlike exams, projects are more complex and open-ended, and students may use any resources, including AI tools. My approach to AI follows the same logic as the calculator: students first work through problems manually in homework, understanding why the steps exist, before using AI to accelerate their work and tackle harder problems. A student who understands the principles can direct AI effectively and evaluate its output critically.

Prompting is itself an engineering skill that students will increasingly need, and projects are a place to practice it. Where possible, students use the tools they will meet in industry; in a machine learning course, for example, I'd use Python and frameworks like PyTorch and Pydantic AI. These projects often integrate multiple course concepts, since real problems do not arrive neatly partitioned by topic.

Outside of exams, students may use computers, draw from their own choice of texts and references, consult multiple sources, and work in whatever operating system or programming language suits them. Collaboration on homework and projects is permitted, provided the work submitted is each student's own.

Working engineers have limited time, uneven prerequisites, and a need to see how a topic applies to their jobs. For them, I rely on the practices described above: examples drawn from practice, resources they can use on their own schedule, and assessments that test understanding. I completed the later part of my Ph.D. part-time while working at ABB, and I have taught engineers and technical leaders at Apple and Microsoft.

Since developing this philosophy as a Graduate Teaching Assistant at North Carolina State University, I have tested and extended it in other settings. At Wayne Community College, I taught six courses in database concepts, secure communications, game design, and artificial intelligence to students whose backgrounds and goals differed from the graduate classroom. At Microsoft and Apple, I have mentored twenty-one PhD students through research internships scoped around producing a publication. Across these settings, the same principles have held: meet students where they are and focus on understanding. Community college students pushed me to think more carefully about prerequisite variation and the role of relevance in motivation. Mentoring PhD students toward publication introduced challenges around scaffolding open-ended, high-stakes work under deadline pressure. Peer observations and student comments from my courses are in the Teaching Artifacts section. This philosophy has been stable in its commitments and revised in its practice, and I expect that to continue.