Natatliia Bielova (most content from Tamara Munzer)
Before you start the writing phase for a paper, you should give a "pre-paper" talk. That's the talk as if you're presenting the work at a conference. This approach helps you distill the critical bits, rather than getting caught up in writing individual words. Do the pre-paper talk where you get group critique before starting the draft. This rule holds for both papers and thesis proposals.
I expect to see a reasonably complete paper draft one month before the deadline, at the latest. For most of you, that means starting writing at least two months before the deadline. That timeline might sound insanely long to you at first glance. But explaining your ideas clearly in writing in fact takes an immense amount of time.
I will provide a lot of help with your first paper/talk, including doing quite a bit of actual writing as needed. The model is "you write, then I rewrite, then you rewrite, then I rewrite, ...": we pass the paper back and forth. As your graduate career continues, you need to take on more and more of the paper writing job yourself. By the time you're on your last paper as a PhD student, you should be doing all the writing, with limited amounts of structural guidance from me - maybe only a bit more critique than you get from the other members of the group who are not authors during paper discussion. The model we want by the end of a PhD is you write a draft, I critique, you rewrite. Note that this model typically requires more time then "you write, then I rewrite". I will tend to write papers faster than many of you because I've done it a lot more. But your job is to learn how to do it yourself. I will also be in the loop for your final PhD defense talk.
Do your literature search before starting the project. Take detailed notes, you'll want them later when you write up.
I highly recommend that you write an outline before you start writing prose. If you have a tendency to get stuck in wordsmithing, consider a sweepline approach, where you do multiple outline passes to fill in levels of detail. Start with section titles. For your next pass, fill in subsection titles. For your next pass, have one bullet point per paragraph. For your final pass, have a few bullet points per paragraph of the main points you want to make. You monotonically advance through the paper, you don't get to go back and fiddle with what came before until the next pass. Then, and only then, write up in words.
Writing up is typically a combination of bottom-up (work up from results) and top-down (work down from master plan). Consider starting writing the paper shell (intro, previous work, algorithm) even before you have final results. A more extreme approach that's worth trying is to do this before you've started programming anything. Then we can decide if it sounds like a strong enough project to bother doing it! It's also a lot easier for us to discuss the algorithm you have in mind if you've written it down, and we may be able to improve it before you spend a long time on coding. It's almost always true that once you have the results, you will drastically change the spin of those early sections. But you'll probably end up with a better paper if you do it this way, and maybe even spend less total time.
If a paper doesn't meet my quality bar, it doesn't go out. As an author, you also get veto power over whether a paper is good enough to submit.
No matter how much experience you have with public speaking, you need to do practice talks. The first time you give a particular talk is always less coherent than later ones. So it should be in front of a few of your peers, not in front of the actual audience! Then you can refine it, both at the structural level and the slide-by-slide tweak level. This rule holds for me too. If you are not totally comfortable in front of an audience, then the need for practice is even more urgent.
You are judged in the real world by results not effort. That's how I judge as well. If you deliver, then I don't care how much, where, or when you work, as long as you've got a reasonable amount of time/space overlap in the building during some standard hours to interact with me and the rest of the group. That is, be around and available for one-on-one meetings, for group meetings, and for discussions with your fellow students. This flexibility on how, when, and where you work is part of the joy of grad school. But - if you're having trouble delivering, then I'll inquire more and more closely about your working habits and possibly introduce explicit expectations on when you're here to help you get back on track. That's how grad school finishes in a finite amount of time.
I do not expect deathmarches on projects/papers. It's not an impressive sign of macho committment, it's a sign of poor planning. If you're consistently doing them, then you have a time management problem and/or an unrealistic expectations problem. I can't sign up to do them with you, I have too many students and too many papers each year for that to be wise on my part. I may occasionally be able to parachute in to help at the last minute, but you absolutely can't count on it. When you don't get enough sleep, you're physically damaging yourself, you're emotionally more brittle, and you're not as creative. Worse yet, you're not nearly as smart: the more sleep-deprived you are, the stupider you are. ALL OF THIS IS TRUE FOR ME TOO. I am trying hard to change my own work patterns to not do this at all, for papers or anything else.
I do expect you to work hard. Research is a game where you're directly competing with lots of other people who are just as smart as you are, and many of them are working very hard. It's also true that to a first approximation, the harder you work the better results you will get at the end of the grad school. But I don't expect you to work all the time. If you don't have a life outside of work, you will eventually burn out and/or be deeply unhappy. The only question is whether it will happen during grad school or after grad school. Neither is good. There will be times when you're in sprint mode to meet a deadline. That's hard to avoid, and not such a bad thing. But you shouldn't be in sprint mode permanently.
You should take some vacation. A good rule of thumb (and an Inria requirement) is at least 4 weeks a year. You should let me know at least one month in advance when you'll be gone. If you're asking to be gone too much, or at bad times given previous committments like paper deadlines, I'll let you know. One of the benefits of academic life is tacking on vacation time at the end of a work trip to some interesting place. I fully expect you to take advantage of that.
We will have group reading meetings once a week. At these meetings we watch video presentations and critique talks and papers. I have one-on-one meetings with each of you for an hour a week.
I want short reports on what you've been up to since our last meeting at least 24 hours before our scheduled meeting time, as plain text email. In most cases this will be a half-page or less, in bullet points. (Sometimes it will make sense to write more down, if there's some sticky algorithmic issue that's worth documenting for the record.) These writeups help me, and your co-supervisor if you have one, understand what you're doing. They will also help you when it comes time to write up papers or your thesis. They may also help you understand how your spend your time, which can be surprisingly surprising!
In many cases it will be useful to also include images, graphs or other results in a separate report that you send alongside the short report before the meeting.
Prepare for meetings with a brief agenda, also due via email 24 hours before the meeting. Also, do whatever other preparation would be useful ahead of time. If it's a software demo, have that up and running on your machine before we start. If it would help to have snapshots, make them in advance.
Use real version control for any and all source code that you write that is work I'm paying you to do. It's up to you whether to do it for personal projects, but I highly highly recommend it. Don't just make occasional tarballs, and/or comment old stuff out. Disaster will inevitably strike. You will need to be able to recover your code to the exact state that it was at some previous time. Sometimes it's because you went down a coding rathole and just want to get out. Sometimes it's because we need to compare a later algorithm to a previous algorithm, whether in a discussion or for a paper results section. A good default choice is Git, we have Gitlab at Inria for that.
Use reasonable naming conventions for data filenames right from the start. Don't save it as "foo" and plan to rename it later. Disaster, where you lose work that could take from minutes to days to weeks to regenerate, will inevitably strike. If you're changing some parameters, try to encode them in the filename. If that gets unwieldy, record filenames and parameters in a README file that you keep in the directory. Don't forget that if your code is changing a lot, it probably doesn't make sense to always overwrite the same file, even if your parameters don't change. Consider making dated directories or something, so that old data files are still accessible instead of blown away. Everything I said about code above is true for data - we will often need older stuff for algorithm comparison or paper figures.
Back up your work. Verify that your Inria machine has automatic backups on Inria servers. If you do any work on a laptop, you need to set up something explicitly, and do it regularly. Do not put this off, disaster will inevitably strike.