A week ago was a paper deadline. As a first-year grad student, I was fortunate enough to be part of an existing project and helped to bring it to a relatively complete stage. It still felt quite unreal, but that was indeed my first paper submission. I thank all who have helped me towards this end.

Looking back, there were many lessons learned, and I want to write down the most interesting ones below.

• Staying up all night hurts the brain.
  I stayed awake for 20 hours, took a 1.5-hour nap (not even completely asleep...), and kept going for another 4 hours until the deadline. I have read about how sleep is very important and being deprived of sleep is equivalent to being drunk, but I did not take it too seriously. Maybe that was because I never stayed up for this long before. Now that I experienced it, I can confirm that all-nighters are awful. It gave me a very bad headache and even until the day after, I still felt retarded.
  To conclude, it is best to avoid all-nighters. However, based on what I heard from those with experience, it is relatively inevitable to stay up late for deadlines, especially in the early years of grad school. I guess I'll try my best, but...let it be.
• Writing is important.
  Being able to present the research in good writing is hard. It should be done early and iterated often. Sometimes it takes a lot of effort to come up with a way to say what I want to say. Also, it will be helpful to find others to read it because someone working on the project could easily make a lot of assumptions and fail to explain well.
  I tend to feel good about my writing and editing skills, but when working with others, it is hard to stick to a style I like. I will compromise and that is okay.
• Serialization is important.
  This is the first on the list of libigl coding tips. Serialization has saved me a lot of time. And what's great about libigl's serialization is that you don't need to worry about versioning; if there is a newly added variable and you added it to the list of things to deserialize as well, loading back data of older versions is not a problem because deserializing for a nonexistent name is just fine.
  In general, if you use libigl, the coding tips are highly recommended. I'm personally truly grateful for those tips.
• One has to live with different coding styles.
  Due to my scarce experience in writing code in industry, I have developed a tendency to conform to a certain coding style. Just like in writing, you inevitably collaborate with others in coding, and it is very hard to make others follow the style you like. This is unfortunate but I guess things balance out because I'm also forcing others to live with my coding style...
  And just a side note: I used to believe that the projects I'm part of should have beautiful codebases, but the reality is that research code can be crappy and badly written. There is not much incentive (for me) to fix it. So I have learned to lower my standards.

That is it. Hopefully, the lessons learned this time will help me do a better job in future submissions.