I had an interesting conversation two weeks ago about the working process for doing theory work in CS and EE. We discussed two extremes of working styles. In one, you meticulously prove small statements, type them up as you go along, getting the epsilons and deltas right and not working on the next step until the current step is totally set. I call this “prove as you go.” The other is that you sketch out some proofs to convince yourself that they are probably true (in some form) and then try to chase down the implications until you have the big result. When some deadline rolls around, you then build up the proofs for real. This could be thought of as “scaffolding first.” Fundamentally, these are internal modes of working, but because of the pressure to publish in CS and EE they end up influencing how people view theory work.

The advantages of the first method is that you have everything set when you want to actually write a paper. The disadvantage is that you often prove the wrong lemma or you prove some useless lemmas, and it’s hard to see the forest for the trees. Scaffolding lets you get a good sense of what you want to prove and how to do it and can figure out some new directions/more interesting problems faster. But since the details get fleshed out at the end, there’s a long hashing-out process when you decide to put a paper together.

Of course, most people work somewhere in the middle of these two extremes. How should graduate students be mentored in this process? From a pedagogical standpoint, it seems best to get younger graduate students prove as they go to get their technical chops down. Later on they can think a bit more in the scaffolding vein. But this is bad from the motivation standpoint — if you are so caught up in the details it’s hard to stay motivated on the problem. If you go the other direction, you run at cross-purposes to a major aim of graduate school: learning how to take a real problem and find a good technical formulation for it. Starting out with the scaffolding approach is like throwing a first-year graduate student in the deep end and hoping they will swim. How should students train themselves and how can advisors help in the process?

Another question is where the balance should be in steady-state. It seems like the prescription is to always “prove as you go,” which is how mathematics should work. But in CS and EE the theorems and proofs are less baroque and the culture is to publish more frequently than in mathematics. So some unhappy medium is struck and with the pressure to submit papers to conferences things often swing more to the scaffolding end, but with the hashing-out of proof details getting deferred. Page limits mean the full proof cannot be published in the proceedings, so many people who see the talk or paper say “well, I’ll believe it when I see the journal version.” Unfortunately, sometimes there is no journal version (because the conference is considered “archival”) or it takes a while for the full paper to get put together. This gives the scaffolding approach a bad rap because really, if the paper that you produce in the end has all the technical details worked out then it should be fine.

Here is where ArXiV can help. Right now what happens in information theory is that people submit a paper to a conference (say ISIT) and then put up the 5 page ISIT paper on ArXiV for faster dissemination. It might be better to put an extended version with full proofs on the ArXiV. It’s like a technical report, really. The downside is that it is a lot of extra work just in terms of writing. The upside is that you get faster dissemination but also give readers more to go on. There are worries about being “scooped” and so on, but you can just not put the paper on ArXiV then.

In any case, it’s a fun corner of epistemology to think about. I’m sure others have had deeper thoughts about it.