Charles Leiserson Tips for Technical Writing

Here are some useful tips about technical writings that I learned from Charles in his advanced performance-engineering class:

• Avoid word New in the title (it will not be new 20 years from now). The same problem about novel (less serious).
• Avoid needless words in the title ("building a").
• avoid week words such "is" "to be" and "have". e.g., replace "they are unable to" with "they largely fail".
• Always embed "however" in the middle of sentence. It is not the same for "But". In that case, use short sentences (break "xxx , but" with "xxx. But," ). 
• Verb is the most important part of the sentence. After that, the subject is the second important. So, never restrict a subject to a "This". Add a noun after "This". Also, avoid "it", e.g., avoid "it is clear that".
• Related to the previous point, replace instances of "is focused on" with "focuses on" (a more powerful verb).
• Avoid semicolons as much as possible.
• It is OK to have passive verbs, however, only when it is required. 
• If you are using "while" as a connector, replace it with "whereas".
• Replace instances of "very" with "damn" and then remove "damn" (inspired by Mark Twain diary). For example, replace "very good" with "excellent".
• Be careful about hyphenating. "cloud-computing services" is different from "cloud computing-services". No need to hyphenation of "quickly growing function" because "quickly is clearly adverb (do not hyphenation adverbs ending with "ly").
• Use "Performance-Engineering" instead of "Performance Engineering" because it the subject. In this example, "Performance-engineering" and "Performance-Engineering" are both fine. In similar situations, always make "Is" capitalized because it is a verb,
• Replace "There are a number of " with "There are several" or "There are many". Then geAlso, "there are has previous problems.
• Use present tense. Avoid future tense and, even worse, "would" "could", etc. It is fine to use past tenses depending on the context.
• Make a context first in long sentences: "when attempting XX, teachers face YYY" is better than "Teachers face YY when teaching XX". 
• It is OK to Highlight a term in both abstract and body
• "IDs" vs "ID's". Acronym to be plural do not need apostrophe in modern English. Charles is OK with the old style, however. 
• "a, b, and c" is preferred to "a,b and c".
• This is about using digits vs spelling of numbers. Knuth says if the number is less than 10/12, then you spell it out; otherwise, use digits. However, it is a bad rule for technical writing. Let's do the following: If you do math on numbers, use digits, otherwise, follow the other rule. 
• Be cautious in using "we", since it can be all authors or authors plus readers. The distinction should be clear. 
• The first sentence of the paper should be about contributions rather than describing. 

Here is an example:

Performance-Engineering of CilkSan

Compressed Dictionaries for Optimizing the Shadow Memory

This paper explores new solutions for maintaining the shadow memory of CilkSan, a debugging tool that detects determinacy races in programs written in Cilk. At the heart of CilkSan lies the SP-bags algorithm, which is a provably good, efficient race-detection algorithm. The SP-bags algorithm maintains a shadow memory data structure that stores the IDs of the previous reader/writer procedures for each memory location. Unfortunately, the large size of the shadow memory is a bottleneck for detecting races for programs with high memory demand.

We tend to decrease the size of the shadow memory by applying compression techniques. We introduce the concept of Compressed Dictionary as an abstraction of a shadow memory with high spatial locality. This abstract data-type is expected to have applications beyond CilkSan. We employ different techniques such as run-length encoding, Lempel Ziv, and Burrows-Wheeler encoding to implement a compressed data structure. Using these solutions, one expects the size of the shadow memory to be considerably smaller than the memory requirement of the current serial program. As a result, we can determine races in real-world applications in which the current version of CilkSan fails due to excessive memory usage.

Postdoc Improv Class

I attended an Improv class arranged for MIT postdocs. It was different (much better) that the class that I described here.  It was a two-hour class in which three instructors from Improv-Boston introduced around 20 postdocs with the concept.

We started with a counting down exercise, where we counted from 8 to 1 then 7 to 1, etc. For each count, you have to move one of your hands/legs. This is to help breathing and getting comfortable about the situation.

The first task was to 'imagine an extra-human power for yourself and pick a name for yourself based on that, and then act that name'. For example, my extra-human power was to 'be able to impeach any president', my name was 'Shahin-the-impeacher', and the action was just 'playing throwing off something'. 

The first real improv excessive was 'list-5-things' where you asked a random participant a random question, and they had to answer with listing 5 items. For example, I was asked about 'my sports that I like to play' and after answering with a list of 5 (after listing each item, others cheered), I asked another postdoc 'list 5 animals that you want to reincarnate to'. There is an element of surprise, and you have to answer without knowing the questions.

Another exercise was about 'gift-presenting'. Two participant attended, the first one pretended to give the other a gift. Based on the way he/she acted, the second one should improv what the gift was and thank him/her for the gift. For example, I can pretend to give you a big, heavy bag, and you can thank me for giving you a bag of potato. Again, there should be an improvisation on what the gift is, and how to handle the question that follows it: 'how did you know that I need a bag of potato'?

 

For the next exercise, we were partitioned into groups of around 10 people. Each group had to advertise a product. The instructors throw random questions at each member. For example, our product was inspired by the problem of 'people not cleaning after their pet'. The first question was 'hat is the name of your product?', followed by 'how does it work?', 'where is your market?', 'what is your moto?', and so on. I was asked 'which celebrity uses your product?' and my answer was 'Peter Griffin'. Finally, we had to advertise our product with an improv act. One of our group members played the role of a dog, one was dog-walker, and I was the narrator. 

The next task was a random improv dialogue. I found this one the most interesting. Two people started a conversation with short sentences. The conversation followed by each person repeating the sentence of the other person, and adding 'And ...' where their sentence followed. For example, you could say 'I love Boston' and I could answer 'Yes, you love Boston, and I think the weather could be better in Boston'. Here, I am showing a sort of disagreement, but I do not use 'But'. This seems to be critical in continuing an improv dialogue.

In the final task, we were given a page where we wrote a problem on one side and the name of a random object on the other side. In pairs, we you to use improv to solve the problem of other person with your own object. For example, I had to provide a solution for 'not having enough time' with 'a pair of glasses'. It was quite challenging, and I think I was not creative enough in providing a solution.

I found the class very interesting and helpful. I am considering to register for the next class that starts in a few weeks, and ends just before my departure from Boston.

Sliceform Studio

I am sitting in the Eric Demaine's class on Geometric Folding. This course is not a typical Computer Science course that I enjoy. However, occasionally, it involves cool, interesting topics and tools.
Last week, I learned about Sliceform Studio, developed by former MIT student  Yongquan ‘YQ’ Lu under the guidance of Eric.

The idea is to use geometry to understand/reproduce the beautiful designs often found in Islamic (particularly Iranian) tiles and fabrics. I enjoyed a lot playing with this tool. The code is open source and one can play with it.
I discussed with Eric the idea of making a font with this tool. I believe one can make a beautiful font with an oriental look with Sliceform Studio. More details about the tool can be found in its website.
An example of the design that it generates is followed.

MIT EECS Postdoc Visiting Committee / postdoc issues

Since last Fall, I have been a member of the postdoc visiting committee, which is aimed to get some feedback about postdoc lives and their concerns/issues at MIT.
In the course of a few months, we collected information/surveys from postdoc. Rabia Yazicigil was managing our efforts and presented the result last Tuesday.
We were reporting to a group of MIT faculty/alumni, who seemed very willing to help postdoc lives. I think the postdoc management and leadership workshop that I attended on January 2016 was inspired by the last visiting committee report.
The main concerns that postdoc at MIT have can be summarized as follows (from my point of view):

• A sense of ``belonging'' to MIT. Postdocs spend relatively short period of time in the institute, and at a relatively older age. It is harder for them to ``connect'' to an environment which already ``belongs'' to students and other staff. Postdocs are mostly occupied with doing research and planning for the future, and a result of this pressure, have little time to participate in activities which help them make a community and adapt to the new environment. Note that this issue is inherent in postdoc structure. MIT has done a good job to address this problem. But still it seems to bother many postdocs.
• MIT has two concepts of ``postdoc-fellow'' and ``postdoc-associate''. I am both because I receive money from both MIT and outside MIT (NSERC). But if you want to ``partition'' postdocs into the two categories, I will be a fellow because most money that I receive comes from outside. Now, there are distinctions in benefits for these groups. In particular, me and other fellows do not receive any health benefits. A postdoc fellow pays around 300-400$ per month for health-related insurances, which I found astonishing. Health insurance has been the worst memory that I have from MIT (and arguably this country).
• Postdoc Leadership Workshop has been great in helping postdocs to from a community in which they enhance their leadership skills in Endicott House, which is located outside Boston. This workshop takes two days, and many postdocs cannot attend it because they have a family. This reveals one of the main differences between a typical postdoc and a typical student. I think MIT is planning to hold similar workshops (but one-day workshops) in the near future. 

I have found the idea of Visiting Committees very exciting for understanding and solving the issues that students, postdocs, and other staff experience in an academic environment.  You can learn about MIT visiting committees here.

My Supervisor, Alex ...

On March 12th, just after a Sunday hike in Blue Hill Reservation in outskirts of Boston, I received three emails from Waterloo. Ian Munoro, senior professor in Algorithms group in Waterloo, as well as Khuzaima Daudjee, in Database group, and Daniela, a friend, informed me that my PhD supervisor, Alejandro Lopez Ortiz, had died earlier in that day. I had visited Alex last time in February, where I found him very thin and tired. He had lost almost half of his body weight, and looked very exhausted. There was no further treatment, and he was just waiting for his time to go.
In our last meeting, I took my PhD degree to the hospital and asked him to sign it. Instead, he wrote a long note on the back of its cover. It remains very dear to me. That meeting happened in Waterloo general hospital cafe, where Alex's two kids, his father, and Daniela were present
I attended the memorial for Alex on Saturday, March 18th, just before the Spring and the Iranian new year. A music was being played, which was selected by Alex, and we were given a sheet of paper with a poem that he chose for this occasion. I realized that he has done many of the arrangements, as this sad occasion was expected.

For me, Alex was a fun friend and boss,  who taught me a lot about research, and about life. He helped me a lot in all stages of our collaboration, from the moment that I met him for the first time seeking for a professor who helps me switch adviser, to the moment that I was negotiating my job offer with University of Manitoba. I remember the time that I received an email from Dr. David Johnson, my PhD external committee member whom I wanted to work with as a postdoc, informing me that we probably cannot work together since he had cancer. When I told Alex that David has cancer, Alex became very sad and shocked.  That happened a bit before Alex himself was diagnosed with a much worse cancer. I remember the day that he was diagnosed, and how gloomy and shocked all the Algorithms lab was. I left Waterloo for MIT a month after. Alex helped me a lot on this path, and later I realized that David has also recommended me for that position. I miss both of them. David passed away a few months earlier than Alex. I lost two great mentors in a few months. I cannot stop thinking about Alex. He will be dearly missed.

p.s. here and here are two pages on Alex's memory.

p.s. the first picture is from the day of my defense. From left to right: Ian, me, Alex, Jonothon Buss, David, and Jochen Koenmann. The second picture is from the day of my convocation with Alex.