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.
No comments:
Post a Comment