What Students Can Expect of the Instructor
I don't know everything.
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 too 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/C/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
knew 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
Taxonomy
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. Be respectful. Honor your
commitments. Give your best effort. Endeavor to produce
quality work.
Strive for clear communication.
Communication is the core of a successful team. Make a
conscious effort to become a better listener and a more clear
communicator.
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 2 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 make assumptions.
Like the old adage says, assumptions make an "ass" out of "u" and
"mptions". Again, you must uncover omissions and
assumptions and seek clarification.
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.