Thursday, 24 March 2011

The Memory Remains

I arrived at my first day of my new job in the United States with a spring in my step. I was dissatisfied with my prospects in Australia, and this new gig was going to give me some coveted graphics programming exposure. The visa in my passport, issued at an Australian Consulate 16 hours ahead of US East Coast time, was stamped 9/11/2001.

Alright, I admit it: there was some trepidation involved. American airports had been closed for a while after the attacks, and I my arrival was delayed. I had sent an email to tell them when I would be arriving (having failed to contact anybody by phone), but nobody had properly acknowledged it.

Two other new hires started on the same day as I did, and soon I was ensconced in my own office (for the first and last time of my career). I had an office, but nothing to work on, so they gave me a textbook to read and a copy of the software to play with.
My first real inkling that things were not okay was not long in coming. The first time I opened the software, it crashed within three mouseclicks.

My first assignment came a couple of days later. When the software started up it would hit the settings files hundreds of times while it worked out how to configure itself. Our customers had recently begun installing antivirus applications, which interposed themselves every time we issued a file-open. Suddenly the time it took the app to start the software went up by an order of magnitude. The task I was assigned was simple: "Get the settings out of the INI files and into an Access database."

I knew this would only slow things down further, and I said so. My manager, Eric, was a bit put out, so I told him I would prove it. This, of course, backfired: in order to prove it, I had to implement it.

But the clock doesn't lie, and, a day later, he was forced to concede that Access was, indeed slower. He threw up his hands and asked how I would do it. "Read all the settings into a cache, rather than hitting the disk repeatedly."

Eric's face lit up. He showed me some code in the Model View UI that  used these horrible Microsoft containers to map data into memory, and told me to build my cache the same way. The Microsoft containers were ugly, clunky, obscure, and completely lacking in type safety. I suggested that I could do the work more quickly and cleanly using the map containers from the Standard Template Library, but Eric and the other senior developers had forbidden the use of the STL, which they considered exotic and tricksy. I reckoned I'd pushed my luck as far as I could, so I just bent my head to it and got on with it.

Suddenly, I was struggling. If Eric had allowed me to use STL maps I would have had it running inside of a working day--the same amount of time it had taken me to get everything into Access--but the Microsoft libraries had a horrible interface that required  extensive memory management and endless typecasting. It was ugly and I just couldn't get it working right. Even when the cache appeared to behave correctly, I could see in the debugger (this was the first time I'd used a debugger) that the data structures weren't treeing correctly. I asked Eric for help, but he just told me to refer back to the Model View.

Eventually, I thought I had it. The maps looked right. Performance was better than it had ever been, even before the antivirus problem... and certainly better than the Access version. But it was ugly as hell.  It was with some trepidation that I checked it in. I had grown to resent code reviews at my prior job, but as a junior working in a new development environment I found this highly disconcerting.

The next day, Eric came into my office with the complaint that, while it did what it was supposed to, it leaked memory. "Just do what it does in the Model View," he said. I fixed it, checked it in... and it still leaked. Eric showed me how the debugger reported memory leaks and I dived back in a third time. I found the documentation on the MSDN, pulled the whole thing apart, and spent another two days getting it drumtight. A one day project had now taken me six. Seven, if you included the false start with Access.

By this time, Eric had decided that I was an idiot. He told me to make sure that the cache was only enabled when the software started up and shut down; not because of the memory cost but because he was afraid it would spontaneously start leaking memory again. I swallowed my pride and accepted it... but it didn't bode well for my future at the company.

My first year passed in a haze of growing misery. I questioned my sanity on a daily basis: was absolutely everything I knew and held dear about software development utterly wrong? Eric and all of the senior developers (all of whom had come out of the same PhD program under the same professor, and none of whom had ever worked at another company) seemed to think so.

At the end of that first year we were acquired by a larger company. Another year later, when they were in the process of shutting us down, Eric assigned me a task scraped from the bottom of the defect barrel. It was an issue that had been present in the app for nearly a decade: a memory leak in a module I hadn't looked at since my first days at the company.

That's right: the Model View Eric had insisted that I use asked me to follow when I was building the settings cache was leaking memory.

Friday, 18 March 2011


'Syntactic Sugar' is a phrase that programmers use to describe methods by which concepts can be more clearly and easily expressed. 'Sugared' syntax is supposed to make your code more concise and readable; like a caramel sauce poured over the creme brulee that constitutes your hard work and perhaps a garnish exquisitely- sculpted chocolate flowers.

Which sounds wonderful and tempting, but... programming is not cooking, and programmers are well known for their overconsumption of fatty, sugary foods. 'Syntactic Sugar', in my expense, usually comes at the expense of whole dessert. That is to say, if the custard is actually a turd it doesn't matter how much caramel sauce your pour on top of it--it's still going to taste like faeces.

Hence, 'Unsugared Syntax'. I want to examine the custard/turd ratio of life as a software engineer, and this is where I'm going to do it.

Here we go, then.

Thursday, 17 March 2011


Welcome, one and all, to Unsugared Syntax.

In this blog I am going to write about my experiences as a software engineer; from early geekdom through university and then through the twelve ridiculous years I have been practising the dark arts of programming in the commercial world.

I will be speaking candidly about my own first-hand experiences. Names have been changed for reasons I'm sure I don't need to elaborate upon. That said, I'm not going for bitter or vindictive ranting. The internet is already brimming with that. I'm aiming for 'wry'; I should, at the least, be able to pull off 'goofy'.

Unsugared Syntax will attempt to concentrate on the personalities, rather than on technical problems: everything from management to quirky hobbies to office romances. These stories should be accessible to a general audience, but I will probably add sidebar posts that will go into greater detail about programming problems, if a particularly interesting or funny one occurs to me.

I do not have a schedule. I'll be posting here whenever the mood takes me, and without much regard for chronological order: if I feel like talking about a particular person, job, problem or locale on a particular day, that's what you'll get.