This was my life recently — I had worked on an algorithm for emulating a FIFO buffer using a switch and clocked delay lines last summer, but couldn’t manage to get my lower bound and upper bound on the switch size to coincide, so I sort of figured that my effort wasn’t really worth it.
On the 13th I was approached by the professor I worked with on this project last summer and was told he wanted to send it to the Globecom 2004 conference. The deadline was 12 AM today. So I worked on the proofs for my bounds, typed it all up, and sent to him. A few days later he got back to me and asked for some better figures, which I made. Then on Friday he said he had reformulated my proof a different way, because mine was too obfuscated. It seemed to me that he had misunderstood my algorthm (because of the obfuscation, perhaps), so it ended with me saying I would rework the entire proof.
At this point we started q2q for Marat/Sade, so I was in the theater 12 hours a day and couldn’t really use my laptop. But I sat on stage and during holds I scribbled out a new proof. Around dinner time on Saturday I got an email saying that he had worked out the misunderstanding, so I didn’t need to work out a new proof. I celebrated by partying with the cast that evening. Sunday was more q2q — at lunch I got another email saying that there was an error in one of my proofs and that unless I could fix it, the paper was a no-go. I spent the rest of q2q and rehearsal revising the proof in little breaks. Then before leaving I typed it up, planning on sending it when I got home.
When I got home, I sent the email, but had gotten another one saying he had proved the lemma anyway, and all was good to go except for a figure that needed to be fixed. The deadline was a mere few hours away. I managed to get the figure done, and the paper made it in by the deadline. My first real publication ever, possibly. Now he thinks we can send it to a journal if we can append a literature review to contextualize it.
There’s a lot to learn from this experience of alternating rapidly between “this paper is wrong and not worth publishing” to “it just needs a few more fixes.” It was certainly stressful, and the fact that I have a lot more at stake in terms of my career by having something published made it even worse.
One of the things this professor said to me is that “proofs are meant to be machine checked” — this runs contrary to the pedagogical approach to proof-writing that I am familar with. In many of my mathematics classes, starting with Mike Artin‘s 18.701-702 abstract algebra class, the emphasis was on building an intuitive notion of why certain propositions were true, and also (more subtly I think) on the process by which certain results were reached. It’s important to know that because A is true, then B is true, but there’s also value to know that B is true because A implies C and C implies B, not because A implies D, since D does not imply B. The route is important. In engineering papers of this type the focus is the result, and the proof is there more or less to cover your ass. As such, it should be concise and almost mechanical, as all good ass covers are.
A related lesson is that once you want to package some idea, it’s good to write it from scratch. Change all of your pet notation, which might be legacy notation from previous approaches to the problem. Condense lemmas into super-lemmas. That way, when you give it to your co-author, they don’t develop misunderstandings about what you are trying to do and then throw up their arms in frustration, saying that your algorithm is totally wrong.
Finally, it’s never over until the fat lady sings. The moment one commits to submitting a piece of research for publication, it will remain an albatross of stress around your neck, squawking loudly and pecking you mercilessly until you submit the damn thing. If the bird seems to be quiet for a little bit, that’s just because it’s preening, and you can be damn sure it will resume attacking you at the least convenient moment.
But then at the end you have something to be proud of.