Quick fact of life: in computer science, unlike other academic fields, most research papers are published at conferences. For a given subfield, there are usually 2-3 top conferences a year, and shooting for their submission deadlines defines the life of many a PhD student.
First of all, let me lay down my credentials -- I am an avid practitioner of the deadline scramble. Recently, someone I have collaborated with quite a lot told me that I tend to "work on the verge of chaos, but manage to keep it together". For some reason, I took that as a compliment.
That being said, let me try and describe the last push of putting together a paper submission for a CS conference. The end result is a polished-looking PDF file, beautifully typeset, in which a groundbreaking idea is strongly backed by tons of data; all this articulated in a clear, logical and concise manner. Or at least a tired group's best shot at this. This PDF ends up going through the conference submission system x minutes before the hard deadline (x typically being a very small number). A deeply satisfying moment that calls for a drink and/or some sleep.
Backtracking several minutes, someone in the room (where the majority of authors are all sitting together) shouts "Did we actually run this through a spellchecker?" or "Does it render properly on <obscure platform> with <obscure PDF reader>?". Somewhere around this time, the version control system holding the sources for the final PDF is getting hit like there is no tomorrow.
Some hours before that, things are starting to shape up. The last-minute data (those minor results that everyone knows will not change any conclusions, and didn't bother to gather in advance) finally arrive and it is time to finalize the whole paper argument and focus on the joys of polishing writing. Food delivery also arrives somewhere in that period for the last time in several days. The team is naturally excited and fully concentrated on wrapping up multiple months worth of work, so there is shockingly no more need for coffee or other stimulants.
In a classical scramble scenario, a small number of days before the deadline, the situation looks grim. Crucial results are still missing; a bug pops up here and there and the team looks for a fix that will not require rerunning month-long experiments; some preliminary feedback from a third party arrives exposing a design flaw... you get the picture. This initial stage can start even weeks before the deadline -- it is characterized by a looming fear that all this work could not possibly be done in time. Dealing with it requires a great amount of concentration and devotion. The team likely switches completely to coffee/delivered food, abandoning any hope of sleep, personal life or personal hygene.
The beginning of the scramble is hard to pin down. I am going to go ahead and formally define it as the moment when the team starts making suboptimal choices because of the deadline itself. Let me give a couple of examples:
Alice has just gotten a set of new preliminary results that look promising, but continues using the scrappier set from two weeks back, which she has already analyzed, because using the new results means she won't have a paper.
Bob is still collecting data for his paper close to the deadline. He can choose to model feature X in gory detail or just grab a rough estimate for feature X, say from literature. He chooses the high-level estimate because writing and testing new code so close to the deadline means he won't have a paper.
Don't get me wrong -- choices like these occur all the time in the process of evaluating a new idea. And most times it is perfectly reasonable to choose, for example, Bob's higher-level model. What I am picking on here is the process of choosing it because it is the only option during scramble time, not the best one.
Now that you have some idea of how the scramble period feels like, let's look at its causes:
Poor planning. As shocking as it sounds, scrambling literally until the last minute before a deadline could be due to lack of planning. Academia is not exactly known as the most well-organized walk of life, especially compared to a large corporation, where several layers of management have the sole purpose of whipping respect to deadlines into their underlings. One can even argue that the lack or organization is inherent in scientific exploration.
A specific piece of the process that usually gets overlooked, especially by junior grad students, is writing the paper itself. It requires switching to "writing mode" -- not the most exciting concept for the stereotypical tech person. Thus, she is often tempted to draw the technical part out, or simply procrastinate until it really is time to start writing (this blog post is a prime example of such procrastination).
Uber-optimism. Interestingly, some of the best researches I have met and worked with are also the ones who have the most problems with deadlines and planning. In a way, this sounds reasonable -- in order to be able to break the status quo in a certain discipline, one has to employ "a healthy disrespect for the impossible" (excuse the cliché). In software engineering, Hofstadter's law ("It always takes longer than you expect, even when you take into account Hofstadter's Law.") tries to capture the concept of excessive optimism. In such uber-optimistic teams, I usually try and play the role of the sceptic in an effort to bring some balance in planning.
High stakes. Finally, the stakes for getting the paper out there are indeed high. As I mentioned in the beginning of the post, the major publication venues for a particular topic are usually 2-3 per year. Which means that not making the deadline carries a significant risk of a 6-month delay or completely missing {graduation, job search, tenure}. In a currently hot field, those 6 months might also be enough time for someone else to demonstrate the beloved idea. Thus, the risk of submitting an imperfect paper can be perfectly tolerable in comparison.
Productivity boost. Seasoned scramblers know very well that productivity at such times is very high. They can try and force themselves that period of high productivity by forcing a scramble scenario, f.e. by juggling different projects until it is absolutely necessary to enter scramble mode for one of them. Admittedly, I usually fall in this category.
To sum up, conference deadline scrambles are a ton of fun. Whatever the actual cause, I like to think of them as moments of both extreme concentration, and extreme teamwork. However, the strong concentration often requires a long period of recovery before any other meaningful work can be done afterwards. In any case, I have to run now -- if I don't start writing very soon, I won't have a paper...
First of all, let me lay down my credentials -- I am an avid practitioner of the deadline scramble. Recently, someone I have collaborated with quite a lot told me that I tend to "work on the verge of chaos, but manage to keep it together". For some reason, I took that as a compliment.
That being said, let me try and describe the last push of putting together a paper submission for a CS conference. The end result is a polished-looking PDF file, beautifully typeset, in which a groundbreaking idea is strongly backed by tons of data; all this articulated in a clear, logical and concise manner. Or at least a tired group's best shot at this. This PDF ends up going through the conference submission system x minutes before the hard deadline (x typically being a very small number). A deeply satisfying moment that calls for a drink and/or some sleep.
Backtracking several minutes, someone in the room (where the majority of authors are all sitting together) shouts "Did we actually run this through a spellchecker?" or "Does it render properly on <obscure platform> with <obscure PDF reader>?". Somewhere around this time, the version control system holding the sources for the final PDF is getting hit like there is no tomorrow.
Some hours before that, things are starting to shape up. The last-minute data (those minor results that everyone knows will not change any conclusions, and didn't bother to gather in advance) finally arrive and it is time to finalize the whole paper argument and focus on the joys of polishing writing. Food delivery also arrives somewhere in that period for the last time in several days. The team is naturally excited and fully concentrated on wrapping up multiple months worth of work, so there is shockingly no more need for coffee or other stimulants.
In a classical scramble scenario, a small number of days before the deadline, the situation looks grim. Crucial results are still missing; a bug pops up here and there and the team looks for a fix that will not require rerunning month-long experiments; some preliminary feedback from a third party arrives exposing a design flaw... you get the picture. This initial stage can start even weeks before the deadline -- it is characterized by a looming fear that all this work could not possibly be done in time. Dealing with it requires a great amount of concentration and devotion. The team likely switches completely to coffee/delivered food, abandoning any hope of sleep, personal life or personal hygene.
The beginning of the scramble is hard to pin down. I am going to go ahead and formally define it as the moment when the team starts making suboptimal choices because of the deadline itself. Let me give a couple of examples: Alice has just gotten a set of new preliminary results that look promising, but continues using the scrappier set from two weeks back, which she has already analyzed, because using the new results means she won't have a paper.
Bob is still collecting data for his paper close to the deadline. He can choose to model feature X in gory detail or just grab a rough estimate for feature X, say from literature. He chooses the high-level estimate because writing and testing new code so close to the deadline means he won't have a paper.
Don't get me wrong -- choices like these occur all the time in the process of evaluating a new idea. And most times it is perfectly reasonable to choose, for example, Bob's higher-level model. What I am picking on here is the process of choosing it because it is the only option during scramble time, not the best one.
Now that you have some idea of how the scramble period feels like, let's look at its causes:
Poor planning. As shocking as it sounds, scrambling literally until the last minute before a deadline could be due to lack of planning. Academia is not exactly known as the most well-organized walk of life, especially compared to a large corporation, where several layers of management have the sole purpose of whipping respect to deadlines into their underlings. One can even argue that the lack or organization is inherent in scientific exploration.
A specific piece of the process that usually gets overlooked, especially by junior grad students, is writing the paper itself. It requires switching to "writing mode" -- not the most exciting concept for the stereotypical tech person. Thus, she is often tempted to draw the technical part out, or simply procrastinate until it really is time to start writing (this blog post is a prime example of such procrastination).
Uber-optimism. Interestingly, some of the best researches I have met and worked with are also the ones who have the most problems with deadlines and planning. In a way, this sounds reasonable -- in order to be able to break the status quo in a certain discipline, one has to employ "a healthy disrespect for the impossible" (excuse the cliché). In software engineering, Hofstadter's law ("It always takes longer than you expect, even when you take into account Hofstadter's Law.") tries to capture the concept of excessive optimism. In such uber-optimistic teams, I usually try and play the role of the sceptic in an effort to bring some balance in planning.
High stakes. Finally, the stakes for getting the paper out there are indeed high. As I mentioned in the beginning of the post, the major publication venues for a particular topic are usually 2-3 per year. Which means that not making the deadline carries a significant risk of a 6-month delay or completely missing {graduation, job search, tenure}. In a currently hot field, those 6 months might also be enough time for someone else to demonstrate the beloved idea. Thus, the risk of submitting an imperfect paper can be perfectly tolerable in comparison.
Productivity boost. Seasoned scramblers know very well that productivity at such times is very high. They can try and force themselves that period of high productivity by forcing a scramble scenario, f.e. by juggling different projects until it is absolutely necessary to enter scramble mode for one of them. Admittedly, I usually fall in this category.
To sum up, conference deadline scrambles are a ton of fun. Whatever the actual cause, I like to think of them as moments of both extreme concentration, and extreme teamwork. However, the strong concentration often requires a long period of recovery before any other meaningful work can be done afterwards. In any case, I have to run now -- if I don't start writing very soon, I won't have a paper...
No comments:
Post a Comment