What Students Can Expect of the Instructor
I will say "I don't know" a lot.
As I see it, the role of the instructor is not to know all the answers.
My role is to show you how to find the answers for yourself. The discipline
of software engineering is to large for me to know it all. There are so
many tools and techniques I can't know every technical detail about all
of them. I may not know how to use a tool that you are required to use
for the course. My role is to give you resources, tactics, and methods
so that you can figure it out for yourself.
I will criticize Java/Windows/(your favorite software).
For some reason, students often believe that because language X has been
chosen by the department for use in our courses, that somehow this language
is beyond criticism. Students sometimes feel it is inappropriate for the
instructor to make critical remarks about it.
I feel a professional knows the strengths and weaknesses of his/her
tools and can make good judgements about when and how to apply those tools.
Any language has shortcomings, and we need to critically examine its drawbacks
as well as acknowledge its strengths.
The assignments may be vague, unclear, inconsistent, or have missing components.
Being able to cope with unclear and ambiguous requirements is an essential
part of a computer professional. If I made every assignment crystal clear,
then you would never have a chance to practice the important skill of asking
clarifyinq questions.
I won't tell you how to do everything. You may spend as much time figuring
out what to do as doing it.
An anonymous student complained: "Many of the things you asked of on the
project we had never done before. So it was not only asking us to do the
task but to research it and completely learn it before we could do it.
This took up the most time."
Most of the problems you will be hired to solve will have exactly these
characteristics: you will have to research and learn some new topic that
nobody else in the company knows about. If somebody already new how
to carry out the task, they wouldn't have needed to hire you, the computer
science graduate. Here's an essay about problem
solving in the real world from a student who has been there.
If I were to give assignments that required only filling in the
blanks, applying a formula, or following a rote procedure, you would be
operating at the lower levels of Bloom's
Taxonmy of Cognitive Objectives. I intend to give assignments
that will challenge your thinking to move to the higher levels of the taxonomy.
That's the difference between a computer technician and a software engineer.
I don't believe in the "transmittal theory" of teaching, where knowledge
is somehow magically "transmitted" from my head into yours. Cognitive psychology
has shown that knowledge is "constructed" in the mind of the learner based
on previous knowledge and structures that are already in place. I can't
know what you already know, so I can't explain everything to fit your pre-existing
conceptual structures. Real learning takes intellectual effort. If I were
to give you a recipe for every assignment that made it impossible for you
to make a mistake, I would deprive you of the essence of what learning
is all about.
What the Instructor Expects of Students
Behave professionally.
Be punctual. Be responsible. Do quality work. Strive for clear communication.
Don't spend more than 30 minutes being stuck.
It's not an effective use of your time to spend more than 30 minutes to
figure out how to proceed. Ask for assistance or find a workaround. (Example:
the team that spent 5 hours trying to make a widget blink, when in 10 minutes
they could simply change its color.) If you get stuck, I expect you
to come and see me, because I can give you lots of tips on how to get unstuck.
Ask when something is vague, unclear, inconsistent, or has missing components.
Because assignments are intended to be unclear, you MUST ask questions.
Don't procrastinate - it reduces the time you have to ask questions.
You need to start early to uncover the ambiguities so you can ask about
them before the due date.