Engineering Students

In my last blog, I talked touched on the fact that I identify as an engineer, meaning that, when something needs to be done, I look for available resources and strategies, design a way to put those things together to solve the problem and then assess and redesign as necessary.  This is true for developing software, creating academic programs, handling my academic department, parenting, and many other aspects of my life.  It is also at the core of how I handle my teaching responsibilities.

My primary responsibility as a software engineering faculty member is to help my students become productive and successful software engineers.  Part of achieving that goal is by continuing to improve our curriculum.  We certainly do that - I don't think an academic year has passed where we did not revise the curriculum as the result of our assessment of student learning. But there are much more personal things that are necessary to really help our students.

When I am assigned to teach a course, my primary responsibility is measured by the ability of my students to meet specific learning objects by the end of that course.  My academic freedom means that I am allowed to design the structure of my courses with that goal in mind and that no one else can tell me that I must lecture or the course must be flipped or anything else about how I must teach that course (other than the possibility of a common text book).  That means that I engineer each course.  I look for ways other people have taught the course, look through my two decades of experience teaching similar courses, and think about what experiences I should design for my students.  At the end of the semester, the culmination of all of those experiences should allow my students to meet the given learning objectives.  I put together the syllabus and start traversing the course with my students.  Along the way, I assess how things are going and redesign the experiences as necessary.

About a decade ago, it was common for people to talk about what was the "product" of higher education.  The general consensus was that the degrees or the courses were the product, but I disagree.  For me, the capabilities of the students are the product.  In some ways, teaching is the art of growing and connecting neurons.   As a product, it's really hard to think about manufacturing that product.  I can't produce a neuron with some mechanical or even biological process and then sell it to my students.  Instead, I have to design experiences that allow the students to produce and connect those neurons.  This analogy clearly demonstrates that teaching and learning is a process that requires engagement of both the faculty member and the students.  The faculty member has to design the experiences and provide the appropriate support for the student.  The student has to actively engage in those experiences, analyzing what is happening and connecting that with the things they already know.  Neither of us can be successful without the other.

Of course, the students and I are engaged in that process in the classroom, and I work to serve them all there.  However, there are a few students who honor me with the opportunity to teach them in other ways.  These students challenge my directions, question the experiences I have designed, share their struggles with the material, and share more of themselves with me, and, as a result, we both learn much more than the learning objectives of a course specify.  These are the students who are taking the best advantage of the opportunity college provides, in which I see the most growth, and who become an integral part of what I am.  The students who come after them benefit from what I learn from them and, invariably, they become very successful software engineers.  I remember a long list of them and am grateful for each one.