Image credit: WACs Learning Code. War Department. Army Service Forces. Office of the Chief of Transportation. 3/12/1943-6/11/1946. Retrieved from the Digital Public Library of America.
Some scholars love to create software. They arrived at NYU with extensive coding experience, they planned to do computational research, they hope to leave NYU and continue make software, etc. Other scholars end up creating software out of necessity. Maybe you came to NYU thinking you'd be interviewing people about economic inequality, figuring out how to restore a polluted waterway, or studying genetics, and suddenly you had to write scripts to analyze large data sets and generate visualizations for your analyses. You've had to pick up your software creation skills ad hoc but now, faced with a data sharing mandate, you're being asked to make your code public. Moreover, perhaps you are a grad student already feeling over-burdened and vulnerable to scrutiny.
Here's why, all those factors notwithstanding, we still encourage you to publish your code, particularly if it relates to conclusions you plan to publish or present.
For specific trainings and classes, please see the Data Services calendar. We are also always willing to discuss other reasons why you feel hesitant to publish your code, so we can better understand how we at the Libraries can support scholars working on computational research.
Our number one piece of advice as you embark on a research software project--even if you take over a research software project from someone else--is to implement version control. If you are unfamiliar with Git and Git hosting platforms like GitHub, GitLab, and BitBucket, you will face a slight learning curve. Luckily, Data Services regularly offers GitHub classes and has an excellent guide to using version control systems. Using a version control system
It's important to note that "Git" (a software tool for versioning files) and GitHub (a cloud-based service owned by Microsoft that uses git) are not the same. You can use Git with a different cloud-based service, or even locally on your own computer. Also, not everything you make using Git or GitHub is necessarily public right away. If you feel uncomfortable letting others see evidence of the early stages of your work, you can make a private Git repository, still get the benefits of version control, and then switch it to become public later on.
If the idea of using Git stresses you out, try using another software that has some ability to track history and changes, like Google Colab.