2. Golden Rules for Projs and Progs

The goal of this class is to give you a set of rules, guidance, and some hard-earned wisdom to help you write better programs and develop better projects.

I’ve spent more hours of my life fixing bad programs and issues caused by project management mistakes than I have spent watching the Detroit Lions be awful. So, please, let me help you avoid that tragedy! Don’t let the Lions OR bad project/program habits ruin your Thanksgiving!

It turns out that these issues are not unique to me. Economists, financiers, social scientists, and researchers that are trained outside of software engineering or computer science are often (especially early on in careers) unaware of solutions those fields solved for problems that social scientists are only now (at least to them) just facing. It’s very common, for example:

  • You can’t replicate an early version of analysis because it calls functions that have been moved.

  • You want to change your sample for tests #4-#12 (in an analysis with 15 test), but the code that defines the sample has been copied and pasted throughout our project directory, and making the change requires updating dozens of files. Turns out, there were copy and paste errors, so those tests didn’t even use the same sample!

  • You return to a project after weeks (or months…) (or years…) away. Despite all the documentation and comments you left behind, it takes days just to figure out how to run the analysis again.

I love this line from a document this part of the website is heavily based on:

Here is a good rule of thumb: If you are trying to solve a problem, and there are multi-billion dollar firms whose entire business model depends on solving the same problem, and there are whole courses at your university devoted to how to solve that problem, you might want to figure out what the experts do and see if you can’t learn something from it.

Let’s start by looking at a project that doesn’t abide by these hard earned wisdoms…