Your Daily Knuth

I keep meaning to write a script that greets me with a Knuth quote when I log in every morning, but I haven't had time.

Today while looking up something else I came across these two gems, though, and thought I'd share:

"Premature optimization is the root of all evil" 

and

"If you optimize everything, you will always be unhappy."

I sometimes think Knuth is like the Mae West of Computer Science. Or maybe Confucius. Which I guess makes Stallman... Sun Tzu? :-)

Room for Failure

Back long ago when I was a wee undergraduate lass, there was a mathematics professor at my university, let's call him Smith. I have no idea what caliber of researcher Professor Smith was back then, looking now at his citation count in Google Scholar I'm not feeling impressed, but maybe those sorts of numbers are more common for Math.

We undergraduates knew Professor Smith not for his mathematical brilliance, but for his tendency to insult people when they came to his office hours and asked questions. I.e., "How could you not know that? You're stupid." To my knowledge he was completely gender-egalitarian in doling out insults, in fact I first heard about his behavior from a male student.

Yesterday when I read Amy Chau's WSJ article, "Why Chinese Mothers are Superior", I thought back to Professor Smith. In those days we all though Professor Smith was a jerk with no social skills, a demotivator, and a poor excuse for an educator. But it occurs to me - maybe he was tough on us because he expected us to be top notch students, and thought we should be pushing ourselves harder. Maybe he came from a cultural background where calling people stupid is acceptable practice and he missed the memo that it is Not Okay in the US.

Growing up, I was lucky to have parents who did not flip out when I got a low grade, and teachers who were always respectful and kind towards me. I did hear tales of some people whose parents would flip out when they failed a test, and I do wonder what effect that has on the developing mind. Does it lead students to cheat? Commit acts of self-harm when they fail? Drop out of school entirely? (I have no doubt it is a major contributor to grade-grubbing).

We seem to stress measured, quantifiable success both in education and in science - receiving high scores, publishing positive results. But I really wish there was more room for (and encouragement of) failure. I wish more stories were told about how a lot of good science comes out of making mistakes, or how a lot of brilliant thinkers flunked out of school.

Once I gave a talk and a young student came up to me and said, "Thank you so much for telling us about the mistakes you made in your research. I've never seen anyone do that before." I was astonished. It just always seemed like the honest thing to do.

The gift of declining service

On reflection, I feel like I should clarify yesterday's post a bit. I was mostly targeting the post toward early-career researchers (ECRs). I think a well-established researcher is in a great position to take on lots of service tasks, and at my current institution that is most certainly how things are done. This division of labor ideally frees the ECRs to focus almost exclusively on doing their research, which I think they should definitely take advantage of.

The problem is, as an ECR it can often be difficult to know in advance which service tasks will help one further their research agenda and which ones will just be distractors. One example of this is paper reviewing. The first time an ECR gets a request to a review a paper it's really exciting and flattering, particularly when it's a high-profile publication venue or high-profile editor/PC member sending the invitation. If the ECR is really new to the research world, they may not yet know what they are and are not interested in, they may not yet know the literature. It's also a great way to keep up with the field. So frequently saying yes to review requests is often extremely helpful at first. As the ECR progresses in their career they start to begin to improve at filtering the good papers from the bad; however, they may not have learned to start declining the bad ones. Bad papers often take longer to review than good ones, especially as an ECR who thinks they need to also copy edit the whole thing.

Conference organization is another example. At first, the ECR is flattered to be invited to help with conference organization. Great way to meet people, to network, etc. But then hours, and hours, and hours go by. Weeks and weeks of time sending emails, preparing budgets, booking rooms, doing all of these things that have absolutely nothing directly related to one's current research. In my experience doing this when I was an ECR, the very best thing that happened was that maybe three more people knew my name. It was fantastic to help out all the people I helped, but it did not help my research career. Who knows, maybe three years from now someone will say, "Oh, yeah, Ada! Didn't she order tables for our conference banquet three years ago? What a sport - let's nominate her for best paper award!", but I rather doubt it.

Mostly, as an ECR, you want to take advantage of this remarkable gift senior researchers are giving you - a chance to do uninterrupted research. A chance to present at and enjoy international conferences without having to do anything remarkable other than show up. It's hard to just accept this gift - you want to give something back. But the best way to give back as an ECR is to publish some kickass results. This makes everyone in your management chain look good, it makes your institution look good, it makes your funding agency look good, and it makes your research community look good. That's how you can best "give back" at this stage.

I'm not suggesting one says "no" to every service request - certainly many tasks are fun, rewarding, and worth doing. But it's ok to consider these requests carefully before accepting, and viewing them with a bit of a selfish eye for how a particular activity might be useful to you in the long run research-wise. For example, I know of people who do CS Education research and can turn outreach events into data gathering exercises, or HCI people who turn administrative meetings into studies of workflow and technology use. (Maybe this is harder if you're, say, a Compilers gal, but you never know). Anyway, it's just good to keep these things in mind, particularly for the tasks that suck up a lot of your time.

The Word is No

This article in IHE reminded me of an important point I'd like to emphasize in this here blog:

If you are interested in a research career

And someone asks you do something that does not directly help your research career

Just say No!

This is yet another critical survival skill that often goes unmentioned. Sometimes it is difficult to tell what helps your research career and what doesn't, but in the end, it's going to be the quality and quantity of your publications. Occasionally service to your community may give you a slight edge in the review process, but in general it's unlikely to make much of a difference. (While good writing may compensate for mediocre research, I've yet to see service do the same thing).

I think a lot of people are afraid that if they don't say "Yes" to everything people will think poorly of them. In my experience this has not been the case. In fact, if anything, it reflects that one is a mature researcher who knows their limits and can manage their time well.

Research takes time - uninterrupted blocks of time where you can think, write, and do. If you are interrupted frequently it's hard to gain traction while at the office and tempting to procrastinate. But the "work at night/weekends" solution has its own set of distractions that also make finding uninterrupted blocks of time difficult (housework, family, blogging :-), pets).

To help learn to say oh-nay, I will share one of my favorite Sesame Street videos, in all its 1980s splendor:

Another reason to diversify your publication venues - drama insurance

Recently I wrote about how to select a publication venue, and in the post suggested that it's good to have a "diverse portfolio" by aiming for a mix of top conferences, journals, and workshops that you publish in each year.

Another aspect I should have mentioned - it's also very good to diversify within each of these groups, in order to have drama insurance.

Whenever groups of humans get together to organize something, there is drama. And it's not always due to cantankerous individuals, I think it's somehow in our nature as human beings. I've seen it emerge in every organization I've ever participated in, from work projects to bake sales. It just happens, like rain.

As an author trying to get your name out there, you don't want to get caught in the crossfire of other people's drama. You just want to publish your paper. But as we've discussed before, a lot of getting your paper accepted at a top conference often has an element of random chance associated with it. For example, at many conferences, the majority of papers are "borderline", and it is up to the whim of your paper chair to decide whether or not to spend precious minutes discussing it. But this PC member likely has an agenda - perhaps s/he is involved in a posturing contest with another PC member. Perhaps there is some talk that too many papers from Podunk University have been accepted recently, and the PC member is afraid to advocate too strongly for your paper because Author #2 is affiliated with Podunk. And so on.

All of these goofy things happening that have absolutely nothing to do with your science!

An unbelievable amount of drama goes on underneath the hood of many conferences, and by diversifying you have extra insurance against this silliness. If Conference A gets caught up in a self-destructing snowball of doom, you still have Conferences B and C.

The best thing about Computer Science is we pretty much can work in any field. Physics. Music. Psychology. Astronomy. History. Architecture. Really, anything. So if your sub-field conference implodes, and your super-field conference implodes, branch out a bit. It's fun to solve problems in other disciplines, and in my experience they're always very glad to have you! Unless you're cantankerous.

Fashion Tips, Part I

I have recently been asked by several people to provide fashion suggestions for how to dress in professional settings. This is going to be a multipart essay - there is much to cover, and I'll make some more specific suggestions in future posts. 

When in professional settings, it is good to dress professionally. Professional settings are defined as one's workplace, a conference, a job interview, giving a talk, etc.

However, defining "professional dress" can be tricky, and selecting the right attire for the organization can be tricky. I have worked for some organizations where professional attire means jeans and T-shirts. But usually professional dress falls somewhere between "business casual" (button-down shirts, nice looking pants, non-boots/non-sneakers*) and "formal" (suit, dress shoes).

The most important aspect of picking the appropriate level of professional attire is this: If you are inside the organization (i.e., employee), dress exactly as everyone else dresses, but if you are outside the organization (i.e., job candidate), dress one level up from what everyone else is wearing.

For example, if you work at an company where all the other employees wear a suit to work every day,  you should wear a suit to work every day too. If they wear jeans, you wear jeans. It's all about blending in. You don't want to be noticed for your clothes - you want your clothes to be background noise to your brains.

Now there is one exception here - if you want to get promoted, or seen as able to fulfill a role "higher" than where you currently are, dress a level up. So if you want to be promoted to be a project leader, dress like all the project leaders do. If you want to be hired as a professor, don't dress like a graduate student at conferences. You want to be seen as a peer.

If you are outside an organization, for example, as a job candidate, you want to dress slightly better than what everyone in the organization wears. If they're all wearing jeans and sneakers, go one level up to "business casual". You probably don't want to wear a suit - especially if you're interviewing in Cupertino! If the employees wear a mix of business casual and jeans, then it's reasonable to wear a suit. Once you are employed you can figure out what to wear, but if you're an outsider trying to get in, dress slightly better than everyone.

If you don't know in advance what the standard attire is for the organization, err on the side of formal dress. People (including you!) take you more seriously when you are dressed up - there's peer-reviewed articles on this. :). I know some Computer Scientists who fiercely debate this, and argue that the scruffy person in flip flops and torn jeans is always the smartest person in the room, but take my word - don't be scruffy as an outsider.

(*) Dear CS Men: I beg of you, from the bottom of my heart, please do not wear those sinfully awful black sneakers (c.f. this). I don't know which uber-geek started this trend, but he was wrong to do it - they are a fashion abomination. Go buy yourself a nice pair of Rockports, or something from the Walking Company. If you absolutely must wear sneakers, get a pair of Converse or some trendy Adidas or something. 

Being Brilliant vs. Writing Well

In the vast world of academic Computer Science publishing, I am about to tell you the greatest secret of all:

You can make up for lack of genius by being a good writer.

Being a good writer will never guarantee a paper acceptance. But I'll tell you, if your paper is like butter for a reviewer to read, it makes it all the more difficult for them to tear it apart. If your writing is crisp and clear and sharp and snappy, it makes reviewers feel joy in the hearts. Especially compared to the other poor abuses of the English language they had to sludge though before your paper walked through the door.

It's actually quite easy to learn to write well. Here are some tips:

1) Practice, practice, practice. A blog can really help, actually. Twitter probably not so much. You want to aim for cogent prose.

2) Read a lot. Read well-edited publications - newspapers, magazines, journals. Journalists are excellent at grabbing your attention and keeping it. This skill is invaluable in scientific writing.

3) Less is more. You are not getting paid by the word here. (In fact just the opposite - many conferences have page charges if you go over the limit!). It is not necessary to give every gory detail. It is highly unlikely you need to paste code into your paper. Just convey the information that is most important - what is it you want people to take away after reading your paper?

4) Once you're confident, take some risks. I know your 3rd grade teacher told you all of these things about structure and topic sentences and a conclusion section and an outline section and all that jazz. But really you need to figure out your own style that best helps you convey clear ideas.

5) Proofread your paper very carefully before submitting it. I am shocked when I read papers with grammar errors, spelling errors, and typos, particularly from senior academics who are fluent English speakers. Take the time to proofread, or outsource. (Occasional errors are understandable, but a paper should not be littered with them).

6) Practice!