How to write good code
Many people never systematically learn how to write good computer code. But many also know that their code could be better. After all, this would make it easier to debug it, or to go back to it after some time, when one has to run that additional analysis for this revision of the paper. And therefore it will save a lot of time at some point.
This is to say that it’s really a good investment to learn how to code well and to organize one’s coding a bit more professionally. My advice therefore is to develop your skills as early as possible. A very good starting point is the Pactitioner’s Guide by Matthew Gentzkow and Jesse Shapiro.
Two points they make strike me as particularly interesting. First, it is desirable that one can fully replicate the results in a paper, from the raw data to the final table with the results. If one makes this a general principle, then one will automatically write better code. Second, the process by which code is changed should be fully documented and it should be possible to selectively un-do some changes. Think of it as a more professional version of “track changes” in word. It actually exists: it’s called versioning software and it works great. Professional programmers use it, and for bigger projects there is really no reason why one should do so as well. Many institutions have a server on which versioning software is running (we have a SVN server here in Tilburg, just email ICT), but you can even run it on your own server (or NAS at home, like a Synology DIskstation), or only on your standalone PC.