Eccentric Flower:199906/Blood sweat and code

A few days ago, I cleaned out my t-shirts and found one I hadn't worn in a while. It's a black shirt with a yellow stripe across the front that reads "Blood, Sweat, and Code."

I'm wearing it this morning. I'm unshaven, in full hacker mode, still trying to clean up the last of my boneheadedness. And this reminds me of why I don't call myself a programmer. I don't call myself a hacker either. (I make jokes like "hacker mode" sometimes, but even then, that connotes a degree of impostordom - hey, look, I'm dressed as a hacker today!)

Two jobs ago, I worked at a software company in Cambridge. This was the first job I held upon arriving in the Boston area. I began as a software tester, the last job I had held in Baton Rouge. I soon became aware of what had been swimming around the back of my brain even before leaving BR - that I was rather overqualified to be a software tester, and that the tedium and repetition of the job was really not getting any better. So I pushed to have them promote me to programmer. They did.

As it turns out, I am overqualified for software tester, but - at least then - I was way underqualified for programmer. I write decent code in some ways, but my focus tends to be on getting user input and parsing it (which is why CGIs are where I naturally excel). I have never learned algorythms. I couldn't write a sort procedure in an efficient way to save my life.

More to the point, my knowledge of C was adequate but incomplete. At the time, I still got confused about pointers and addresses and matters of memory allocation. This is not minor stuff. It's something that you bump noses with in C all the time.

Now, if I had been dropped into relatively simple code to begin with, I'd have caught up gradually and all would have been well. I'm a quick study. But I wasn't dropped in gradually, and the code wasn't simple.

First off, in commercial software, nothing is ever done at a careful pace. This is why I'm not in commercial software any more. Due to the stupidity of certain market realities, and the fact that most managers have no idea of the reality of the programming trenches, all software is created in a tearing hurry. Most software you buy at your local store ("shrink-wrapped" software is what the industry calls it, to distinguish it from direct-to-customer software, programs used internally by a company, et cetera) was released before it was ready. This is why software is so buggy. There is never enough time to do it right.

Second, the code at this company was incredibly crufty. It was written originally for DOS, before Windows, and as a result did some things which a Windows program would let the system do for it - such as its own virtual memory handler. (DOS didn't have a VM handler of its own. Everybody wrote their own back then. They also wrote their own device drivers and a lot of other, similar overhead, which is why, as bad as Windows is, most Intel-style programmers don't miss DOS. Basically, when writing complex DOS software, you not only had to write the software, you had to fill in holes in the operating system as well.)

When the code moved to Windows, though, they didn't drop their DOS methods. So, for example, the product was trying to do its own VM handling on top of Windows' VM handler - and the two seldom got along. The Windows product nearly sank that company, it was so horrid.

Also, the code was about searching and retrieving data. A simple search engine is indeed simple - Ivy was written in an afternoon - but it gets complex fast. And search highlighting - where you look at the results page and the found terms show up in an obvious way, like a different color - is such a pain that even Ivy's simple implementation of it doesn't work quite right. This is because the location of highlit terms has to be stored separately from the data itself, and merged back in when the user looks at the results ... somehow. Usually not well.

I hit my nadir when I was asked to fix a very difficult highlighting bug in a particularly fast and loose portion of the deepest dregs of the code - the heart of darkness, as it were. Now, the original code wizards who had made this fast and efficient but very convoluted and indecipherable code had all moved onto other things. Programmers, as a whole, hate maintaining their work. They wrote it, they solved the problem, and now they want to solve another problem. So all the people who understood this heart of darkness had either left the company to chase new riddles, or wanted nothing to do with their old works. Meanwhile the people who had to fix the problems had never been trained in this code by anyone who might possibly have understood it.

I had no idea how to fix the bug. I studied that horrid, undocumented code for a month and I still could barely make out what was going on. It was an all-time low in confidence for me, the first time a problem has refused to yield even in the face of careful study and hard work. I literally could not wrap my head around what this code was doing.

As I've described at some length above, there are plenty of reasons why it wasn't my fault. But all I could see at the time was that I had been assigned this work and literally could not do my job. It was one of the worst working experiences of my life. And I nearly got fired over it, because I hated going to work so much that some days I would invent reasons to simply not show up.

Eventually, we got the person who'd originally written the code to come in and "help" fix it. In fact, he did everything but make the edits himself - showed me where it was and exactly what to do - and he let me have the goodwill that he deserved once it was fixed. He knew immediately how little I knew, but he never told anyone else. I had heard many bad things about this guy, but he's on my good list for eternity.

And I moved on to a project which involved connecting our search engine with a web CGI ... the pacing was slow enough, and it overlapped with my skills enough, that I could finally get the hang of pointers and memory, and when I left the job, I was on good terms with C.

But I still don't consider myself a "programmer." Because if I call myself a programmer, someone is going to expect me to be able to deal with any code they throw at me. And I know, for a fact, that at least three-fourths of the code my co-workers deal with on a regular basis would bewilder me.

It's not easy to go to work every day feeling like an impostor, but I manage.