Making it Easier to Do the Right Thing
I know that a lot of the code that I write is disappointing. One of the first things that you learn in a computer science class is how to wrap up things into modular little bits and turn everything into a function.
But since most of my code only runs once (after it is working) and answers a specific question (How many students satisfy these conditions, Make a spreadsheet that we can use in a mail merge, Is there a statistically significant difference between this situation and that situation, etc.), there is no need to properly modularize it. Even the SQL queries are a little bit different from one problem to the next. Do students who switched classes count as drops? Sometimes yes, sometimes no.
Yesterday, however, my so-far-futile efforts to predict the future inspired me to make a function! It is not a small function. It is roughly 60 lines long. If I were taking an undergraduate computer science class, it would probably be broken down into smaller functions.
So what inspired me to create this function? My future needed a lot more past. My new function asks the database about the past, and then it arranges the past into a format that can be understood by standard future-prediction algorithms. Not only did I feel a deep sense of existential dread even thinking about copy-pasting a 60-line chunk of code, I knew that I was going to have name collisions. And the easiest way for me to deal with that was to hide all the names of the intermediate variables inside the scope of the function. The downside was that I had to do fussy stuff with string manipulation in order to pass in some parameters that are used by the SQL query inside the function.
Unrelated: We are going to have weather today. Unlike on Game of Thrones, where seasons last for years, in San Diego we have micro-seasons. First Summer starts today and may last for almost a week.