Clarity of Thought in Research, Reading, and Writing Dr. Fred JIANG / 姜小凡 Researcher, Mobile and Sensing Systems Group (MASS) Microsoft Research Asia http://research.microsoft.com/people/fxjiang.

Download Report

Transcript Clarity of Thought in Research, Reading, and Writing Dr. Fred JIANG / 姜小凡 Researcher, Mobile and Sensing Systems Group (MASS) Microsoft Research Asia http://research.microsoft.com/people/fxjiang.

Clarity of Thought in Research, Reading, and Writing

Dr. Fred JIANG / 姜小凡 Researcher, Mobile and Sensing Systems Group (MASS) Microsoft Research Asia http://research.microsoft.com/people/fxjiang

The Simpson’s take on Ph.D.

• “They just made a terrible life choice.” – Marge Simpson

The illustrated guide to a Ph.D.

by Matt Might

http://matt.might.net/articles/phd-school-in-pictures/

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 Patterson’s “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

• • • On research – The scientific method – – – – – – Selecting a problem Formulating a hypothesis Design experiments Evaluation Finishing a project The feedback loop On reading – Reader’s perspective – Reviewer’s perspective On writing – The writing process – Simplicity

Outline

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 doesn’t 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 – can’t convince others if they can’t get same results Be honest with results (anticipate criticism from reviewers and address them; use additional experiments – explain why something didn’t 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

• • • Don’t care about deep technical details – They will most likely skip the equations Don’t 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 (“don’t 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 can’t understand the ideas” Easier to claim credit for subsequent good ideas – If no one understands, how can they contradict your claim?

It’s 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 Patterson’s writing advices: http://www.cs.berkeley.edu/~pattrsn/talks/wr itingtips.html

“The elements of style” by S&W