Having Fun in Research

1. Having Fun in Research Yuanyuan Zhou

2. Research is a Job! • You need to be responsible • You cannot cook your own results • Research should aim to make impact • Not just papers • Research pays • RAs ---- sorry, pay is a little too low • Professor---pay reasonable • Research scientist in a research lab • Patent commercialized • …

3. Research > a Job • What are the special characteristics demanded in research? • Hint: what is demanded in playing a computer game? • Your curiosity • Your passion • Your focus • Your patience • May take 2-3 years • Your obsess (your persistence) • Sometimes it does not work • Rejections (10-20% acceptance rate) • Do you have all?

4. A table to relieve your stress To avoid the only bad combination, you should just enjoy yourself! Because this is under your control, whether succeed or not in some degree also depends on others’ subjective evaluation!

5. Selecting Fun Research Areas • Match your interest/passion • Common mistakes • Limit yourself only within your comfortable zone • Something unknown must be fun • Consider only the ultimate research goal but ignore • Research reality • Research methodology • You need to enjoy the journey • Consider only job opportunities • Follow the trend --- hot areas

6. Adventurous in Your Research • Research is to find out the unknown • Adventure in research • Propose new (maybe weird) solutions • Jump into a new area unknown to you • Adventurous in research is fun • Not bored • You can bring a fresh air into a direction • Likely to yield unexpected results • Your start a new direction!

7. My Own Experience • 1992-1993: Database (Peking Univ) • 1993-1994: Mathematics & Internal medicine ( Univ. of Virginia) • 1994-1995: Computational biology (Princeton) • 1995-1999: Distributed systems (Princeton) • 1999-2002: Storage Systems (NEC Lab) • 2002-Now: Software reliability, Energy management (UIUC) • Future: ?????

8. Problem-Driven Research • Identifying problems is more important than finding solutions • Define the boundaries of your problem carefully • “Nobody will be impressed if you set the bar too low and jump over it. Nobody will be impressed if you set the bar too high and don’t jump over it.” (Dave Redell) • Don’t try to “solve the world” or “boil the ocean”.

9. Picking Fun Research Problems • Criteria (agree with Lui & previous speakers) • Exciting and interesting area • Important problems in area • Activities suitable to you (theory vs systems) • Take time to understand the problem • Catch up background • Get your own insights • Hands-on: repeating the most recent, authoritative work in this direction to understand the limitations from YOUR own perspective!

10. Defining the Solution • Make the problem concrete • Start with particulars, then generalize • Know what makes the problem hard • “Why couldn’t you just...” • Identify the standard of success • How will you know when you are done? • How to distinguish a good solution from a less-good solution?

11. Looking for Solutions • Don’t limit to your comfortable zone • Broaden your eyes • Talk with researchers from other fields • Attend talks in other fields • Don’t let fear of failure stop you

12. My Own “Gutsy” Solutions • Pushing bug detection support into hardware • Attended Ravi Iyer’s class at UIUC • Attended Darko Marinov’s class at UIUC • Combining data mining into compiler’s program analysis • Attended Jiawei’s data mining class • Combining NLP into program analysis analysis • Reading some textbook

13. Conduct Research in a Fun Way • Feasibility analysis • Find out the potential in a quick way • Talk with other people • Get feedback • Divide and Conquer • See progress along the way • Be proud of your ideas!

14. Team Research is More Fun • Team discussion is stimulating • You handle the up-and-downs together • Less pressure • Work party • Who likes to play games in a team? • Internet games • Poker

15. Eight Ways to Destroy the Fun of Team Research? • Fight for credits/author order • Not supportive • Over-defensive • Command each other • No communication • Blame each other • Passive waiting for tasks • No compromise

16. Tell Your Fun Findings to Others • Write a paper • Publish it at workshops/conferences • Present it at a conference

17. Writing is Fun • Writing helps you refine ideas • That’s why writing should be done in parallel with the design, implementation and experiments • Writing helps you communicate ideas • In most cases you will find out that you, your teammates and your adviser have totally different views of the project (the idea, etc)

18. Add Fun Analogies in your Presentation • Explain boring technical things in an easy-to-understand manner • Demonstrate your key insights • Make your talk more lively • Throw jokes

19. Analogy Examples • The analogies used in my job talk • The analogy used in my recent talks

20. Multi-level Server Cache Hierarchy Database Clients File Clients Database Servers File Servers Storage Servers Network Network … Client Cache Database Server Cache Storage Server Cache ~ (64MB – 128MB) << (4GB – 32GB) (1GB – 64GB) No need for inclusion property

21. Multi-level Server Caching accesses misses in cache? hits LRU? Storage server Cache Database or File server Cache Least Recently Used (LRU) Database Servers Storage Systems (Lower level) File Servers (Higher level)

22. Analogy: Storage Box (Basement) • Assumption for analogy: item = box • Question: do you keep the box? • If you have a basement, you can keep all the boxes Living room (higher-level) Basement(lower-level) pizza DELL Traditional Client-Server Cache Hierarchy

23. Analogy: Storage Box (Closet) • If you just have a closet, you may keep only the box for your holiday decorations! Living room (higher-level) cold access hot access hot miss Closet(lower-level) Database-Storage Server Cache Hierarchy

24. But If You Use LRU for Your Closet… • Your closet will be full of garbage! Living room (higher-level) Basement(lower-level) pizza

25. Atomicity Violation Bugs • Programmers want atomicity • They assume some code regions are ‘atomic’ • Lock/transaction are ways to ensure atomicity • Incorrect implementation causes atomicity violations

26. BUG! Challenges of Atomicity Violation Detection How to represent programmers atomicity intention? Detect violation tothe atomicity intention Infer programmer’s atomicity intention program How? How?

27. An Analogy ---Don’t Disturb • Assumption: • I work on some tasks everyday and some are repetitive • Preparing lectures • Writing proposal • Playing computer games • Thinking or day-dreaming… • Some tasks cannot be interrupted (e.g. playing games) • I don’t tell students explicitly about what can or cannot be interrupted----too embarrassing… • Question: • Can my students automatically figure out what tasks can be interrupted?

28. Infer Professor’s “Atomicity” Desire • Finding Clues: • When a task is interrupted unwillingly, the professor is a little mad, dis-oriented and cannot wait to get back • Infer this task needs to be “atomic” • Otherwise, happy to be interrupted

29. Research Impacts • Papers on top conferences • Best paper award---even better • Visibility • Discussed in other institutes’ seminars • Other people know about your work • Inspire other research projects • # of Citations • Start a new research direction • Used in real systems

30. Final Words: Enjoy Your Research • If you are not having fun in research now, ask yourself • Are you working on an area that you feel passionate? • Are you working on a fun problem? • Are you doing it alone? • Have you seen any promising results? • Do you see the impact of your research?