Clarity of Thought in Research, Reading, and Writing Dr. Fred JIANG / Researcher, Mobile and Sensing Systems Group (MASS) Microsoft Research Asia

The Simpsons take on Ph.D. They just made a terrible life choice. – Marge Simpson

The illustrated guide to a Ph.D. by Matt Might

Some thoughts on research Why get a Ph.D.? – Make money? – To be called Dr. Blah Blah? – Allow you to teach at the university level – Allow you to do research and expand human knowledge – Dissemination of knowledge What I consider to be one of the most important takeaways from graduate study – Clarity of thought: in the research process, in understanding previous work, in dissemination, and in everyday thinking. No, a career in research is not for everyone – Sometimes you can contribute more by doing something else.

Credits Many slides are based on David Pattersons How to Have a Bad Career In Research/Academia Many advises are directly taken from my advisors David Culler and Scott Shenker Many thanks to my colleagues over the years

Outline On research – The scientific method – Selecting a problem – Formulating a hypothesis – Design experiments – Evaluation – Finishing a project – The feedback loop On reading – Readers perspective – Reviewers perspective On writing – The writing process – Simplicity

The Scientific Method Scientific Method Hypothesis Sequence of experiments Change 1 parameter/exp. Prove/Disprove Hypothesis Document for others to reproduce results Computer Scientific Method Hunch 1 experiment & change all parameters Discard if doesnt support hunch Why waste time? We know this

Selecting a problem Research starts with SEARCH (and RE-search) Solve real problem that someone cares about Select problems with definable success metrics Break larger problems into smaller checkpoints Cross-disciplinary projects (ACme signature analysis example) Pay attention along the way (they often lead to interesting problems and solutions)

Formulating a Hypothesis / Picking a Solution Simple solutions are better than complex ones! Best results are obvious in retrospect Anyone could have thought of that Reproducible

(And Pick A Good Name!) R educed I nstruction S et C omputers R edundant A rray of I nexpensive D isks … R ecovery O riented C omputing

Design Experiments Must be able to EVALUATE results! – Positive results vs. negative results Break it down – experiments that verify one dimension at a time Iteratively evaluate and improve solution (the debugging process) Use experiments to verify (fully) before moving on The Berkeley way vs. the MIT way

Evaluation Define metric of success (what to evaluate) Quantitatively (figures, graphs) Report in sufficient detail for others to reproduce results – cant convince others if they cant get same results Be honest with results (anticipate criticism from reviewers and address them; use additional experiments – explain why something didnt work)

Finishing a project People count projects you finish, not the ones you start Successful projects go through an unglamorous, hard phase Finishing a project is how people acquire taste in selecting good problems and finding simple solutions

The Feedback Loop Feedback at every step – Idea conception (usually get killed right away) – Project team formulation – Interact with peers, industry, luminaries Ability (and willingness) to consider mid- course correction – CS is a fast changing field; assumptions changed; new technologies appear; others have done

Reading an Academic Paper Different types of readers – The knowledge seeker: most people read academic paper to get a rough idea – The other guy: some one who is in a similar field or working on something related. – Members of the TPC: should I accept or reject it?

The Knowledge Seeker Dont care about deep technical details – They will most likely skip the equations Dont have time to read every word – And only look at figures and read captions May not have the relevant technical background – But will usually read intro

The Other Guy Comparison to your paper – how is my work different? – why is my work better? Reproduce / build on top of your work – An implementation of the concept / architecture of your paper – Reproduce results for comparison

Members of the TPC Technical contribution Originality Relevance to the conference/journal/workshop Scoring – Recommendation – Originality and impact – Technical correctness – Presentation – Expertise The champion / anti-champion

My Writing Process PPT with figures (figures are good) – May not be real figures, simply use figure templates Figure captions (lots of caption) Get feedback on PPT Write topic sentences Write Read aloud Get feedback (iterative process) Rewrite (dont be afraid to kill your own babies)

Brevity If it were not unsimple then how could distinguished colleagues in departments around the world be positively appreciative of both your extraordinary intellectual grasp of the nuances of issues as well as the depth of your contribution?

Sincerity Distinguish will do vs have done, mention drawbacks, real performance, reference other papers Be upfront with key findings / results Draw readers in early Earn their trust before preaching to them

Simplicity Best compliment: Its so complicated, I cant understand the ideas Easier to claim credit for subsequent good ideas – If no one understands, how can they contradict your claim? Its easier to be complicated

The Systems Paper Template Abstract Introduction Related Work / Background Architecture / Design Choices Implementation Evaluation / Deployment Future Work Conclusion

Specific Advices and References Quantity vs quality Journal paper vs conference paper (and workshop paper) Have impact Pattersons writing advices: itingtips.html itingtips.html The elements of style by S&W