Advice to systems researchers

Presentation

• The science of scientific writing Gopen and Swan
• Strunk and White, The Elements of Style. Read this book at least yearly. ***Required***
• How to give a bad talk
• How to give a good talk
• An Evaluation of the Ninth SOSP Submissions -or- How (and How Not) to Write a Good Systems Paper Roy Levin and David D. Redell, Ninth SOSP Program Committee Co-chairmen
• THE TASK OF THE REFEREE Alan Jay Smith
• "A Guide for New Referees in Theoretical Computer Science" Ian Parberry
• Hints on writing technical papersArmando Fox (local copy) ***Required***
• Pointers to Advice on Research and Writing (Mark Leone)

Career and general advice

• Paul Krugman "How I work"
• Eytan Adar's collection of links to advice for graduate students and researchers
• Dr. R.W. Hamming's Advice on Research
• Allen Newell: "Desires and Diversions" -- how to have a successful research career.
• Pithy advice for researchers
• Time management Randy Pausch, CMU
• How to Have a Bad Career in Research/Academia David Patterson
• Accreted wisdom related to computer scienceArmando Fox
• The Ph.D. Job Hunt - Helping Students Find the Right Positions E. Lazowska. CRA News May 2002.
• Tips for a Massive Academic Job Search: Ellen Spertus (the original page has disappeared; here is the page from archive.org.)
• Academic Job Resource Page( Steve Lumetta)
• Job search tips Mary Baker
• Is work hell? Life in industrial research (John Wilkes)
• A list of research labs and contact information for job hunters (thanks to Jian Yin).

System building and productivity

• Some suggested standards to follow...
• Programming with threads *** Required ***
• LESS SW Engineering Manual (section 1: ***Required ***; the rest is optional)
• John ousterhout
• Group and startup culture
• How to make decisions
• Fortnight milestones
• Steve McGuire Writing Solid Code. Some of the specific techniques are dated, but the attitude is timeless. Learn to think this way and you will build better systems with less effort. Debugging the Development Process also by McGuire is also worth reading if you can get a copy (it is currently out of print.) (p 164--167 of Debugging is *** Required ***, the rest is optional.)
• EWD1305: "A programmer has to be able to demonstrate that his program has the required properties. If this comes as an afterthought, it is all but certain that he won't be able to meet this obligation: only if he allows this obligation to influence his design, there is hope he can meet it."
• C. A. R. Hoare. The Emperor's Old Clothes. Communications of the ACM, Vo. 24, No. 2, February 1981, pp. 75-83.
• [Lampson 83] B. W. Lampson. Hints for Computer System Design. Proc. of the 9th ACM Symposium on Operating Systems Principles, October 1983, pp. 33-48.
• Coping with complexity Jerome H. Saltzer (MIT)
• Saltzer J., Reed D. and Clark D., "End-to-end Arguments in System Design.", ACM Transactions on Computer Systems (TOCS), Vol. 2, No. 4, pp. 195-206, 1984.
• Sermons on system building and career as system designer (for undergraduate OS class)
• Sermon 1: Simplicity (Tom Anderson channeling John Ousterhout)
• Sermon 2: Performance Tuning (Tom Anderson channeling John Ousterhout)
• Sermon 3: Programming as Craft (Tom Anderson channeling John Ousterhout)
• Sermon 4: Information = Property (Tom Anderson channeling John Ousterhout)
• Sermon 5: Stay Broad (Tom Anderson channeling John Ousterhout)
• Basic statistics for systems research from Eric Brewer

Big thoughts

• Vannevar Bush's paper: As We May Think Atlantic Monthly, July 1945
• Richard Feynman's paper: There's Plenty of Room at the Bottom
• What Next? A dozen remaining IT problems Jim Gray
• Computer systems research: past and future Butler Lampson (Microsoft Research)