How to behave in college

What do we call you?

For most teachers in college, the conventional answer is "Professor [LAST NAME]" or "Doctor [LAST NAME]." If the teacher's name were Albus Dumbledore, you would call them "Doctor Dumbledore," "Professor Dumbledore," or just "Professor" for short. In an email, you might write "Dr. Dumbledore."

For me in particular, we have a bit of an awkward situation to deal with. Tufts has given me the title "Lecturer," not "Professor," and I'd feel like a bit of a fraud asking you to call me by a higher rank than I am, so "Professor" is out. Also, I don't have a doctorate degree (a Ph.D.), so "Doctor" is out as well. This leaves us with a few options.

The good news is that you get to pick. As I have repeatedly told my 3-year-old daughter, I don't care what words you use; I do care about the tone of your voice. If you were to call me, "PROFESSOR STAFFORD!" in the same tone that my daughter uses for, "I WILL NEVER NEVER TAKE A DEEP BREATH AGAIN!", I would be irritated with you, even though you chose respectful words. On the other hand, people have been calling me "Brandon" every day for the last 4 decades, so it feels fine to me.

Does this really matter?

The truth is that I don't really care what you call me, and I will probably pretend not to be irritated with you even if I feel irritated inside. This is called presenting a professional persona, and it's one of the skills that you need to learn to be a good engineer.

Your engineering persona

One of the major skills of an engineer is working collaboratively in teams. Over time, you should cultivate a persona that you adopt when you are engaged in engineering.

Great engineers are particularly good at giving engineering criticism that makes you feel enlightened, rather than beaten down. Here are some suggestions to help you get started.

Criticize the design, not the person. When you feel criticized, check whether the target might be the design rather than you. You might adopt Jon Postel's Robustness Principle, from section 1.2.2 of the IETF's RFC1122, "Be liberal in what you accept, and conservative in what you send."

A few examples:

Be specific in your criticism. Try to anticipate failures and describe failure modes.