I work professionally as a programmer at an atmospheric science department at a major university. One of the biggest things about atmospheric research is our reliance on computers for everything. While we’re nowhere near the limit of what we can do with observational data (and indeed in many areas, observational data is woefully short), there are so many things we simply cannot do in laboratory experiments. Because we can’t reproduce most things in a laboratory setting, we’re stuck creating computer models. That’s fine. However, the result of this is that we are almost an applied computer science field with how much we have to wrangle computers day in and day out.
What troubles me is that, at least in my place of employment, practically no-one really understands computers.
I work in a primarily Fortran shop, which many of you would think “well, there’s your problem right there.” Not so much, as there’s a huge literature of already perfected Fortran code to solve nearly every tricky numerical gymnastics problem you can think of (and twice that number of ones you can’t think of). Fortran90/95′s greatest win, and flaw, is that it has incredible backwards compatibility with old FORTRAN77 code (and even some FORTRAN66!). Re-writing the millions of lines of FORTRAN77 that passes through the department on a semi-regular basis would be costly in sanity, time, and money.
But what about how you work with that code? Some of us know a certain friend of mine who sat up for hours manually inserting rows into a dataset to account for missing time in hourly reports. It’d have taken half an hour to whip up a MATLAB script and have it loop through the dataset. Almost nobody uses any form of version control (those that do have a sea of directories resembling projectname_vers-num, with num being their revision number), and most of the Unix programming is done through running VIM in vi compatibility mode. Changing an identifier within the code from one to another is typically a day-long affair for most (hint: it should take perhaps 5 minutes, 10 if the SAN is feeling sluggish), and inter-routine data dependencies are best described as a maze of twisty passages, all alike. Makefiles are written in a manner where it’s a requirement to run “make clean” before any recompile, and some folks swear by Intel Fortran’s -save flag, which makes all local variables static. That flag is used entirely for its side effect of initializing all local variables to zero, however, and not a thought is given for the actual effects.
This is actually a rather sad, sad state we’re in right now. It isn’t anyone’s fault, either. There’s no overarching culture of programming and software engineering at my place of employment, so there’s not many examples of folks “doing it better”, with those of us who are being categorized as “Oh, but you’re one of those crazy geeks who just know how to do it.”
I’m one of those crazy geeks because I sat down and forced myself to learn how to do it, because I saw that it would pay off, in dividends. It has, too.
I’m not trying to claim I’m some wunderkind, either. There’s gaping holes in my expertise and practice that hinder me daily (which I’m trying to correct). What does it come down to for me? Right now, I’m sitting down and reading the GNU Emacs manual. I can’t be arsed to dig up my copy of The Pragmatic Programmer, but there is a section in there that says one should really master a text editor. I’ve taken it to heart, and with my limited time, that’s my “journey of a thousand miles starting with a single step.”
What have you done to be a better programmer today?
