Clarity of Thought in Research, Reading, and Writing

Dr. Fred JIANG / 姜小凡Researcher, Mobile and Sensing Systems Group (MASS)

Microsoft Research Asiahttp://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

Outline• 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

The Scientific MethodScientific 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!)Reduced I nstructionSetComputers

RedundantArray of I nexpensiveDisks

…

Recovery OrientedComputing

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/writingtips.html

• “The elements of style” by S&W