The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds castles in the air, from air, creating by exertion of the imagination.

The biggest problem I’ve had has been getting started in building castles in the sky. I suppose part of it is lots of practice from day one, but it’s almost like a case of agoraphobia seeing the vast expanse of nothing in my editor. From there, there’s so much stuff to add. There’s a fair bit of not wanting to lay down the boilerplate code inherent in any programming. Otherwise, though, there’s the vague idea of where I’m wanting to end up, and a blank page doesn’t offer any assistance in helping with that first step.

I’ve been learning to take more advantage of the REPL, which has really been helping me get going. It makes it possible to just worry about little snippets of code and then tie them together instead of laying down hundreds of lines of FORTRAN and hope it all works out when it first meets the compiler.

While trying to still have a life away from this keyboard, I’m pushing myself to get back into recreational programming, where everything starts as a blank page.

Both of these jobs also had me essentially be a one-man team to take care of what I’m programming on; while figuring out what I’m supposed to be doing, I’m also supposed to take lead on whatever project it is that I’m working on. While working in the academic position, I certainly had a lot of work ahead of me in learning how to be that one-man team; I quickly started having questions that people around me had no answers to, and my too-often muppet flailing in figuring out how to figure things out like that was an endless source of frustration to both me and my boss. That said, the experience was invaluable training for my next job with SpiderOak, where the working condition was even more uncoupled- instead of working halfway by myself, I was essentially completely alone. Instead of an office, I had my home office, working remotely. Instead of people around me who also work for the platform and the language, it was just me and The Internet trying together to figure out how to make an iPhone application that people would want to use. I’m now developing the Android client for SpiderOak, which again finds me being the only guy working on the platform and language, and Android is a tricky system to develop for, with the steepest learning curve I’ve had to deal with yet.

It’s been a trying experience. I feel like I’ve been hitting my head on a glass ceiling in terms of my development as a programmer by not working as much on a team with people; for the past three years I’ve felt like I’ve been more working for people instead of with them. When I have problems or issues, it’s been tremendously difficult to solve them, as it’s hard to simply show someone the tricky code for tips if they don’t understand it. Come to think of it, this lone-wolf programming experience has been demoralizing- it feels like where you’re at a party and everyone’s in their conversation circles, and you can’t quite get into one and you’re just stuck on the outside. Code reviews in particular are a little sad; the best response I’ve gotten so far has been “I don’t really know the language but I like that you have unit tests.”

I’m spending next week in Kansas City with some of my co-workers, getting my hands dirty with the back-end storage code that runs SpiderOak. I’m tremendously looking forward to it, because for once I’ll be the junior developer on a team. I’ll be able to look up to people for help and guidance, and they’re paying attention because it’s part of their product as well; they know the language, they know the platform, and they know the system. On top of that, I’ll be able to see and be walked through how other people tackle things. I’m looking forward to this learning experience, and hope to be able to sit back down at my mobile development with fresh eyes.

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?