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
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 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!)
Reduced
I nstruction
Set
Computers
Redundant
Array of
I nexpensive
Disks
Recovery
Oriented
Computing
…
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 midcourse 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