My Philosophy of Teaching

My Philosophy of Teaching

Whether I’m in the classroom, advising a student, developing new course notes, preparing lab assignments, or writing exam questions, I have three basic principles which I follow: 

·       I must be precise and concise

·       I must engage students in problem solving and critical thinking about their solutions.

·       I must examine whether my approach works, and look for ways to further improve it.

Keeping these principles in the forefront keeps me on track and helps me enable my students to increase their level of attainment of the technical knowledge that computer scientists must have as well their understanding of the societal issues that knowledge impacts.

I must be precise and concise

Students need to learn how to conceptualize how the parts of a software and/or hardware system interact. This is important, because once they do that, they can extend those conceptual models in designing new systems. My task as a professor is help them ensure that these models are correct.  I do this by asking questions in the lecture or on homework assignments about the behavior of an algorithm, abstract data type, or hardware component in order to evaluate the depth of their understanding and to help them correct any shortcomings or misconceptions. In order to accomplish this, it is imperative that I speak and write precisely and concisely. Visual representations such as diagrams of the effect of an algorithm on a particular data structure and then executing that algorithm on a few small data sets are helpful to that end.  If I determine that students are not sufficiently grasping the concepts, I will revisit the topic using a different approach.

I must engage students in problem solving and critical thinking about their solutions.

All engineering disciplines are based on finding solutions to real-world problems. Real-world hardware and software systems are increasingly complex.  Hence, the problem-solving process is also complex.  Software engineers must design and implement algorithmic solutions with a level of rigor which does not come naturally to the typical novice programmer. Hence, it is imperative that I teach students how to solve problems with an appropriate level of precision. Oftentimes I will pose a problem and ask them what approach we should try first.  Together with them, we proceed to evaluate that approach.  Based on the feedback, we modify the design, try some test cases, and analyze the behavior. I find that this approach engages the students more than simply having them listen to a lecture.

Over the years, I have come to understand that not only am I responsible for conveying information about a subject, I am also responsible for helping students think in a reflective manner about that information.  The students need to understand that the solution I present to them may just be one of many solutions and they need to be able to critically analyze more than one approach.  I encourage them to do this whenever possible.  In the lecture, I might give two or more possible solutions and ask them to evaluate them with various criteria.  It might be in time or space complexity, or ease of implementation, or some other factor. Other times I might ask students to reflect on some of the major paradigms of computer science, such as RISC architecture or object-oriented programming. For example, I might ask them to give me the advantages of RISC architectures on one exam, but on another to give some disadvantages of RISC architectures and explain why recent architectures depart from RISC in various ways. I generally give some indication well before the exam that they need to think critically about these issues.

I also try to put the material into historical context.  I find that students are engaged more when they understand how the methods and systems we have now came about.  They also need to understand that current form we have these systems was as the result of decisions made years before and that if different choices had been made in the past, our present technology might be more secure or better in some other way.  If I can help students realize this, perhaps they will be motivated to make critical thinking a habit throughout their careers.   Another way to put historical context into the classroom is by using personal anecdotes (I call them “war stories’) about my experiences as a software engineer at Stata Corporation or as a NASA faculty fellow.  

I must examine whether my approach works, and look for ways to further improve it.

I have also come to realize that students come from diverse backgrounds and have different personalities and learn in various ways.  Although in a large section such as I usually teach, there is little opportunity to tailor the presentation of the material to any one individual or group, I find that if I use more than one approach to explain a particular concept, it usually helps the understanding of the group as a whole. If an exam indicates that a substantial number of students are having difficulty grasping a concept, I will revisit that topic and try yet another approach. Whenever appropriate, I ask students what topics they would like to see covered more in-depth. Sometimes they want learn about a topic about which I have only superficial knowledge, and if I can fit it into the schedule we will discuss that.  And occasionally those requests have resulted in a new course proposal or a revision of the curriculum.

One-on-one consultations give me the opportunity to hear an individual student’s concerns and to better tailor the explanations to that individual’s needs.  Perhaps finding an analogy to explain a concept, drawing a sketch on scratch paper, or looking over their code and giving hints on how to improve or debug it.

In summary, it is my philosophy that the goal of teaching is not only about helping students increase their knowledge of a subject, but also enabling them to engage in lifelong learning.  Keeping these principles in mind helps me accomplish both of these goals.