On time management

Prodded by several comments, I have finally decided to write up some my thoughts on time management here.  I actually have been drafting something about this subject for a while, but I soon realised that my own experience with time management is still very much a work in progress (you should see my backlog of papers that need writing up) and I don’t yet have a coherent or definitive philosophy on this topic (other than my advice on writing papers, for instance my page on rapid prototyping). Also, I can only talk about my own personal experiences, which probably do not generalise to all personality types or work situations, though perhaps readers may wish to contribute their own thoughts, experiences, or suggestions in the comments here. [I should also add that I don’t always follow my own advice on these matters, often to my own regret.]

I can maybe make some unorganised comments, though. Firstly, I am very lucky to have some excellent collaborators who put a lot of effort into our joint papers; many of the papers appearing recently on this blog, for instance, were to a large extent handled by co-authors. Generally, I find that papers written in collaboration take longer than singly-authored papers, but the net effort expended per author is significantly less (and the quality of writing higher). Also, I find that I can work on many joint papers in parallel (since the ball is often in another co-author’s court, or is pending some other development), but only on one single-authored paper at a time.

[For reasons having to do with the academic calendar, many more of these papers get finished during the summer than any other time of year, but many of these projects have actually been gestating for quite some time. (There should be a joint paper appearing shortly which we have been working on for about three or four years, for instance; and I have been thinking about the global regularity problem for wave maps problem on and off (mostly off) since about 2000.) So a paper being released every week does not actually correspond to a week being the time needed to conceive and then write up a paper; there is in fact quite a long pipeline of development which mostly happens out of public view.]

Another thing is that my ability to do any serious mathematics fluctuates greatly from day to day; sometimes I can think hard on a problem for an hour, other times I feel ready to type up the full details of a sketch that I or my coauthors already wrote, and other times I only feel qualified to respond to email and do errands, or just to take a walk or even a nap. I find it very helpful to organise my time to match this fluctuation: for instance, if I have a free afternoon, and feel inspired to do so, I might close my office door, shut off the internet, and begin typing on a languishing paper; or if not, I go and work on a week’s worth of email, referee a paper, write a blog article, or whatever else seems suited to my current levels of energy and enthusiasm. It is fortunate in mathematics that a large fraction of one’s work (with the notable exception of teaching, which one then has to build one’s schedule around) can be flexibly moved from one time slot to another in this manner. [A corollary to this is that one should deal with tasks before they become so urgent that they have to be done immediately, thus disrupting one’s time flexibility.]

It helps a lot here to be able to honestly and accurately evaluate your work potential (a function of your location, your current level of motivation and energy, your upcoming duties and commitments, availability of resources, and the expected level of distraction) for a given period of time into the future (e.g. the rest of the day): being either overconfident or underconfident about what you can achieve leads to taking on either more or less than you can properly handle, both of which lead to inefficiencies (I have learned both sides of this from direct experience).

While I have a large number of things on my “to do” list, at various levels of complexity, difficulty, and length, when it comes to any task requiring dedicated thought, I try to focus on it exclusively, postponing or shutting out everything else; I find that multitasking only works for me when none of the tasks requires more than a fraction of my attention (in particular, it seems to work best when I am not inspired to do any one particular task). Quite often, these tasks take longer to complete than I have the energy, time, or patience for, in which case one has to find a natural break point (e.g. proving a key lemma in a paper that one is writing up, or writing down a full sketch of some idea that just came up in conversation or on the blackboard or scratch paper) where one can safely set the task aside and forget about it for a while, and be able to resume later without losing one’s place. The thing to avoid is to drop a task when it is only partially finished, without any good “closure”; it then either gets lost, or weighs on one’s mind and prevents one from fully thinking about something else, or has to be redone from an earlier point when one picks it up again. But one doesn’t have to finish each task off completely as it comes, as long as it can be picked up later. A mundane example: when I get around to writing physical letters (usually a low priority, when I don’t feel ready to do serious mathematics), I type them, print them out, seal them in an envelope, and then deposit them in my “out” tray, but I generally don’t mail them (or process any other paperwork in my out tray) until it piles up and I have nothing better to do, at which point I go out and deal with all of it at once.  [I find that a particularly good time for doing this is when my computer needs to reboot or is somehow not easily usable.]

More generally, tasks that require little concentration seem to be best done in batches if possible, while tasks that require a lot of concentration seem to be best done individually, with as few distractions as one can manage.

Related to the point about “closure” is the desirability of being able to chop up an extremely long task into smaller, self-contained ones, ideally each with its own immediate “payoff”.  To give one example: I doubt I would ever attempt to write (let alone finish) the equivalent of my 19 or so lectures on the Poincaré conjecture if I had decided to write one enormous article or monograph rather than 19 reasonably manageable and self-supporting shorter pieces.  (It helped also to “paint myself into a corner” a little bit here by announcing the lectures in advance, and building up some momentum, to stop myself from abandoning the project half-way.)

[One very nice thing about modern text editors, including the one on this blog, is that it is very easy to save a draft at some intermediate stage and flesh it out or polish it later, which greatly assists the task of writing long papers by chopping up this task into a sequence of much smaller tasks, as discussed above.  I am quite impressed by mathematicians from before the computer era who were able to meticulously write out high-quality papers and even books; even with good secretarial support, I would find this extremely difficult to do myself.]

It also makes good sense to invest a serious amount of time and effort into learning any skill that you are likely to use repeatedly in the future. A good example in mathematics is LaTeX: if you plan to write a lot of papers, it makes sense to go beyond the bare minimum of skill needed to jerry-rig whatever you need to write your paper, and go out and seriously learn how to make tables, figures, arrays, etc. Recently I’ve been playing with using prerecorded macros to type out a standard block of LaTeX code (e.g. \begin{theorem} … \end{theorem} \begin{proof} … \end{proof}) in a few keystrokes; the actual time saved per instance is probably minimal, but it presumably adds up over time, and in any event feels like you’re being efficient, which is good for morale (which becomes important when writing a long paper).

There are also many situations in which it makes tactical sense to defer, delay, delegate, or procrastinate on any given task, and go work on something else instead in the meantime; not everything is equally important, and also a given task may in fact become much easier (and be completed in a much better way) if one waits for one’s own skills to get stronger, or for other events to happen that reduce the importance or need for the task in the first place.  My current papers on wave maps, for instance, have been delayed for years, much to my own personal frustration, but in retrospect I can see that it was actually a good idea to let those papers sit for a while, as the project as I had originally conceived it was a technical nightmare, and it really was necessary to wait for the technology and understanding in the field to improve before being able to tackle it in a relatively civilised manner.   [Perhaps this very article on time management is an example of this, also.  There are also a number of other draft articles hidden in this blog that I felt were not quite working at the time, and are awaiting some further inspiration to complete.  It seems that not every idea or topic for an article necessarily leads to a viable end product; cf. “use the wastebasket“.]

My final suggestion is to pick some sort of organisational system and make a real effort to stick to it; a half-hearted system is probably worse than no system at all. [A corollary to this is not to try to make an overly ambitious system ab nihilo that one is unlikely to follow faithfully; it is probably better to let such systems evolve over time.] I have my own system involving a PDA synchronised to my laptop, my email account, some in trays, out trays, and other designated spots in my office, and a “reserved” blackboard, that probably only I can understand completely, and I don’t think I can even explain it properly here, but I’m used to it now and it seems to work well enough (though I sure hope nobody ever erases that blackboard!). The choice of system though is presumably a very personal matter and I wouldn’t be able to advise on what would work best for anyone other than myself. But I do find that such systems free up a lot of memory; if I don’t have to worry about what I’m supposed to be doing at 3pm on Tuesday, or what work needs to be done on X, Y, and Z for purposes A, B, and C, I can devote more of my attention to trying to understand a mathematical argument, or proving a tricky lemma, or whatever else I need to work on.  [I also find it psychologically satisfying to be able to physically cross off an item from my organisational system, which can be a useful motivation when one feels otherwise uninspired to deal with something.]  On the other hand, one should not obsess too much about such systems; as a rule of thumb, I would say to devote about 1-5% of your productive time to time management, and 95-99% of your productive time to actual work.

Oh, and one final disclaimer: sometimes one should abandon one’s own rules and allow for serendipity.  There have been many times, for instance, when I had planned to work on something during my lunch hour (grabbing something quick to eat), when I was interrupted by a colleague or visitor to go out to eat.  It has often happened that I got a lot more out of that lunch (mathematically or otherwise) than I would have back at the office, though not in the way I would have anticipated.  And it was more enjoyable, too.  (Similarly with skipping talks at conferences (or skipping conferences altogether) to go work on one’s own papers, etc.)