A story of demotivation
During the second semester of my junior year, I decided to switch majors from chemical engineering to environmental science. I was still taking engineering classes that semester. In two engineering classes I worked hard, learned a lot, and got a good grade. In the other, I did the absolute minimum, learned nothing, and earned a poor grade as a result. So, why did I proceed so differently in the classes? Motivation. I liked the challenge of classroom problem solving in engineering, I just didn’t want to do it for a career for various reasons, so I was still generally self-motivated to learn. That was sufficient for two of the classes. In the third class, Natural and Synthetic Fossil Fuels, there was a tremendous amount of what felt like wrought memorization with no connection to previous material or practical use. The assignments were both unclear in scope and purpose. To make matters worse, there were only three students in class and half way through the semester the professor didn’t know my name. When all three of us were confused, he would throw his hands up in the air and exclaim, “This Mickey Mouse, This Mickey Mouse!” Presumably frustrated that we didn’t understand something that seemed so simple to him. In this case, my self motivation was insufficient to overcome the demotivating factors. The lack of connection to existing knowledge, lack of an awareness of purpose of the assignments, inability of the instructor to recognize that expert blind spots in instruction (as indicated by 100% of the class being confused), and feeling that the instructor didn’t care about us as individual learners resulted in me doing the minimal amount to pass the class and nothing more.
A story that will help motivate Software Carpentry learners drawn from personal experience
Before I thought seriously about analytical workflows and when I knew nothing of version control, my standard operating procedure was to write R scripts and run analyses and send the scripts and result outputs back and forth with coauthors via email or dropbox. Usually we’d end up with about a dozen versions of scrips and outputs and even modified datasets. The file structure would consist of similar file names ending with dates and initials. The folders would get bloated and confusing and not reproducible for all practical purposes. This continued until I started doing analyses (MCMC sampling) that would take hours and even sometimes days. Finally, this back and forth resulted in the deletion or saving over of the final output. There was not clear path back to the output and everything had to be recreated. Due to the mess of the R scripts with multiple files and versions it was a nightmare to recreate the right analysis of the right data in the proper order. It took at least a week of full time work to get the code figured out and another week to rerun everything. It was completely wasted time and to this day I have no idea what happened. I just realized that the entire system was broken. It motivated me to dedicate the time to learning git/GitHub and teaching my collaborators. The time spent learning and teaching as been saved many times over with efficiency, plus things are reproducible. Maybe your analyses don’t take as long or the code isn’t complex or your workflow isn’t quite as messy, but at some point you’re likely to be involved in more complex situations (many authors on a paper, lots of code, long analyses, etc.). It’s far better to invest the time to learn a system like git/GitHub in advance of a problem, rather than finding yourself in a disaster down the road. It’s embarrassing to even admit how messy things used to be. I wish I could say it was perfect now, but it’s not a disaster and it’s getting better with every project. Hopefully, this story inspires you to establish a workflow with version control and documentation so you don’t create your own embarrassing story.