The Writing Rules

These rules are for my research lab.

Do not use ChatGPT or any other genAI tool. Since 2022, my students and my research team have been increasingly using ChatGPT to help (re)write sentences, abstracts, or even entire paragraphs and sections of a paper. The argument is that it looks more professional and has fewer errors. As a reader, I am tired of reading generated text: It is often repetitive and shallow. It can miss entirely the point you are trying to make or worse make up an entirely different point. You can write it better. Even if it is rougher, or seems less polished, we understand you better when we hear your voice. We also spend more time editing out the generated fillers than refining rough text. 

The bigger concern here is that “writing is thinking”. If you let a tool do the writing for you, you are not clarifying your ideas, figuring out the bigger picture or logically constructing and validating your arguments and algorithms.

This rule applies even to abstracts. If you can’t distill the main contributions and claims of your paper into a single paragraph, how will you give an elevator pitch to anyone who asks about your research?

Do not fill space. If you can write it clearly in a sentence, don’t write a paragraph! If you need a paragraph, don’t write a page, etc. Brevity is an art and one you should perfect. From now on, ignore whatever notion you may have about how much space something should occupy. Some of our conferences penalize papers that are unnecessarily wordy. Gassy writing stinks!

Do not use passive voice. Experiments were not done, you did them. Show some professional accountability by owning up to the work. I have zero-tolerance for passive voice. It has no place in scientific writing. If you are intentionally obfuscating attribution, we have bigger problems. Also, active voice is easier to read and flows better.

Do not start with “Data is exploding …” or other tropes. I get that it might help you get over the empty page intro block, but how about you just get into it and tell us what the problem is; the rest will naturally come together.

Do not cite papers you haven’t read. If you can’t meaningfully describe a system in related works and how it compares with your work, don’t put it in. Everyone is tired of lazy citation lists. Also don’t use citation lists to back common sense claims such as “database systems are used in healthcare [1, 2, 3, …100], finance [100, … , 200], blah, blah, blah …”

Do not be pompous. Write simple and clear. Think “KISS — Keep it simple, stupid.” This rules also applies to algorithms, mathematical formalisms, etc. Strive for simplicity. I will institute a pomposity jar: you will pay a dollar for every1 Greek alphabet, ten for every subscript or superscript, and a hundred for every convoluted or over-the-top sentence. All proceeds will go towards a coffee fund for the readers who have to go through your paper.

Disclaimer: Writing rules are not legally binding. I bestow the rights of judge, jury and enforcer to myself. Violators can pay in the local currency: 1 US Dollar=3.65 UAE Dirhams. No students have been charged … yet.

  1. I considered adding “extraneous” to the use of Greek notation but then if I’m going over a proof or algorithm, I sure do need the coffee. ↩︎

How to write a critique for a research paper?

Note: this is an active post and I’ll be updating it as I receive feedback or find helpful illustrative examples.

One of my many awesome advisors and teachers, Daniel Abadi, made us write critiques of research papers in his graduate database systems course. It was an excellent exercise as it allowed us to:

  1. think deeply of the work,
  2. create a summary that we can later visit whenever we need to refresh our memory of the work or even to write the related works,
  3. think about new research problems or different research perspectives on our current work, and
  4. practice writing (and believe me you need the practice).

If you read a paper and you like it (or dislike it), write a critique! Adrian Colyer has a popular blog where he critiques research papers in systems and ML.

Read the rest of this entry »

Managing your advisor: the art of the meeting

An effective student-advisor relationship is the foundation of good academic research. This relationship is often structured around weekly meetings.

As a student, keep in mind that your research problem is your main and only work focus and you are expected to initiate and test out ideas as well conduct the majority of the creative (design prototypes, UIs, design experiments, code, think of a proof structure, etc.) or grunt (code, prove, conduct experimental runs, etc.) work.

The advisor is usually your backup, wiser brain. Often, the  advisor presents you with the research problems. She will likely guide you through the problem, outline solutions, remind you of the big picture, refer you to papers, make you think of alternative solutions, designs, implementations, unstick you if you find yourself stuck, help you analyze or figure out the experimental data, and so on. The advisor, however, is a busy, multitasking machine, often advising multiple students with varying demands on her time, teaching courses, writing grants, building research networks, serving on conference committees, or dealing with university business. I never appreciated the faculty workload until I became an assistant professor.

The advisor brain is thus an expensive resource, which you must efficiently manage. I hope you would find some benefit in these advisor meeting & management tips: Read the rest of this entry »