My Best Programming Moment

The "add your story" pages seem to do well here (c.f.: TheJobMarketSucks, NamesGivenToComputers). Let's see how this one does.

What was the best moment you have had in your programming career?

I was working on an oft-neglected web-based tool used internally by the company.

To test it, I had to run through the same steps that the users of the tool had to run through. There was this one point where the steps looped ("Wash, rinse, repeat"), but, for reasons I can't recall, you couldn't just hit "Back".

You had to go forward
- to the tool home page,
  - then through two more links after that.

To make matters worse, the real users had to do this series hundreds of times in a day.

To make matters inexcusably bad, each page load often took over five-ten seconds to complete (long story).

All that is to say that when I was testing the tool I got infuriatingly impatient at having to go through those extra, slow steps. So, for my convenience sake, I added a "Go back to <relevant step>" link. I didn't think anyone else would care. The code was quietly promoted to live use later that day.

When it went live, one of the users came in crying tears of joy because the link saved them so much time.

Maybe we shouldn't be doing this for money.

It is a beautiful story. Thanks for sharing it. :)

The day I learned to stop worrying about bugs and get on with my programming.

Ok, this is not particularly a best programming moment, but it was an important one for me. I was working on a summer project as an undergraduate, attempting to model electric fields within electron guns using a ConnectionMachine over in Edinburgh. The problem fitted perfectly with the architecture of the connection machine (well the modelling part did, at any rate) - I was basically doing a simple stepwise refinement over a two-dimensional array.

The algorithm was painfully simple, but it didn't work. I got some beautiful coloured charts back (they looked like those temperature charts you get on weather reports) but they were going the wrong way. I went through the process of checking the equations, the code and the output for an inordinate amount of time, to the point where I was almost losing my sanity.

Then I noticed that(*):

 ( v_1 - v_2 + v_3 - v_4 ) / 4

Should have been(*):

 ( v_2 - v_1 + v_4 - v_3 ) / 4

I had the signs the wrong way round! How on earth had I managed to get that wrong? How on earth hadn't I spotted it before? The problem was so excruciatingly simple, and the error was so painfully obvious. My first thought on looking at the wrongly-coloured graph had been that "it sort of looked like it was a graph of the derivative of the field"(*). Of course, after the dust settled it took about five seconds to work out that this was, indeed, what I was graphing(*).

To this day it still makes me cringe, but in a nice way. Sometimes you just need to chill out, take a coffee break, read a book, go look at some mountains, get another pair of eyes to look at the code.

(Of course, I still ignore my own advice far too often :)

-- DavidMcNicol

(*) I am recalling these details from nearly ten years ago, so I can barely remember the details or the physics. :)

I was writing a tool to allocate unique numbers to client programs running on a cluster of transputer based nodes. Odd operating system, with very few facilities. I'd worked out the problem and my proposed solution, wrote the pair of programs (client and server), compiled it, fixed one typo, and it all worked as intended. Never needed to change it again. It wasn't that big a program, but very satisfying -- PaulHudson

MyBestProgrammingMoment came when during my first year of actually doing programming work, when I actually had to optimize some code. The code had to scan a really large grid (say 10000 x 2000) of cells and find the smaller window (say 30 x 20) in that grid that had more errors than any other window. I wrote it brute-force at first, and it was correct, but it also took about five minutes to scan.

Then I realized I could save the intermediate column totals in a queue, and each time I had to compare with the next window over I simply had to total the next column, shift the queue, and add the totals on the queue. The new algorithm resulted in a scan that took about 15 seconds.

So although I always try to stick to the maxim OptimizeLater, I can understand the temptation people have to always optimize now -- it feels pretty cool when it works. -- francis

A few years ago I was working on a small control system that was used to analyse grain. It had a conveyor belt and a number of shutters controlled by solenoids. I was having trouble getting a consistent flow through the thing. There were several photo-sensors and LEDs used to detect the presence of grain and I was getting confusing signals from these, which was messing up the logic. I just couldn't understand why sometimes it worked fine, and at other times it failed.

Then (several days later) I saw the light - literally. I was running the machine with the side panels off, and if it was sunny outside and I wore a white shirt, enough light was reflected into the machine to dazzle the photo-receptors. I put on a dark jumper and the machine started working perfectly. The solution was not software at all - I just had to change the operating level of the LEDs and the sensitivity of the detectors. The software was working correctly all along.

Not really my best moment, but I did laugh.

-- DaveBerkeley

I wrote a kind of generic tester for Java recently. It iterated over Jar files, and the classes within them, and the methods within the classes, calling each method with a set of random arguments (which sometimes needed to be objects, made by calling constructors with various random arguments, and so on). I came up with a set of rules for what constituted a "bug" - basically if a method threw certain classes of Exceptions when it shouldn't. When I had finished writing it, I wanted to give it something to chew on to see if it was good at finding bugs. I didn't have much code to hand, so I decided to feed the program it's own Jar file as input. In a few seconds the program had found a null-pointer exception in one of its own methods. The recursiveness of the whole thing was, I thought, quite pretty.

--WilliamBland?

The day I realized how "Premature optimization is the root of all evil" - Knuth. It's amazing how much time I wasted for how many years by being anal retentive about efficiency over simplicity and functionality.

-- Steve Jorgensen

In 1981 I wrote a program in 8080 AssemblyLanguage to read and write 5-bit telex tape from a then-popular PC. It was my first application in a language I'd taught myself.

It worked fine, but I felt I would be more productive if I didn't have to keep switching between the telex program and the text editor. What I needed was an integrated full-screen text editor.

I pondered it for a day, then woke up the following day (Saturday) with the code just there. I sat up in bed, grabbed a yellow pad and a fountain pen (no, I didn't use ball points -- biros -- back then), and began channeling ASM code as fast as the pen would move. By that afternoon I had a paper-and-ink copy of a text editor.

Monday came, and I transcribed the code into my telex program. I had to change one piece because I'd mis-read the hardware design. Everything else worked.

That day redefined my career. I was no longer a Telex Operator who wrote code, I was a programmer with a day job.

-- GarryHamilton

This one is from the freak-side of the fence. I was trying to write a very loose and heuristic parser for an undocumented file format, and I just couldn't wrap my head around the problem to get started. Finally that night I went to sleep with the thought "I'm gonna dream about this and get a solution" - I was very into LucidDreaming at the time. In the dream I headed over to Finland and "asked them how to write it" - after seeing their code in the dream I remember thinking "ok, now I'll just copy their code and transfer it from my brain to the computer when I wake up". When I woke up the next morning I had somehow wrapped my head around the problem and went to "transfer the code" - it wasn't as easy as a straight upload, but was far better than the day before. In the process I found a few bugs in the "dream version of the code" and refactored out some redundancy. . . It wasn't until after finishing the parser that I fully realized just how odd and surreal the process had been. I still feel a little guilty for "stealing the dream-guy's code". . . It did make me realize I had gotten to the programming level where it was active at the subconscious level. . .

--LayneThomas

See WeirdDeveloperDreams

One of my first multi-user projects was a billing/invoicing system to be used by about 50 billers around the country. After being in production for about 2 years, our parent company wanted to replace all billing and accounting systems with a bundled deal in order to get consistent data from each subsidiary, which up to this point had independent and different systems. This meant my billing system was going to be history.

The main manager of one of the satellite offices was near retirement and thus had a tendency to say exactly what was on his mind. After his office did an initial evaluation of the new billing system, he wrote a memo to the head coordinator of the new system. It said something like the following:

I have been watching our gals [billers] working on the existing billing system, and they have grown pretty damn proficient at it. We have finally gotten to the point where billing works like well-oiled machinery after being a sore spot years ago. The new system threatens this new-found productivity so much so that anybody who replaces the current system should be summarily shot.

It indeed did say "summarily shot". That phrase became a "private cliche" within our local department. I joked with my boss, "What's the difference between being summarily shot and specifically shot?"

Despite other accolades, my billing system was finally replaced anyhow due to Bush-like "steadfastness" by the higher ups to put their system in place at any cost, but it did not go down quietly. Other billers also gave it praises. One biller who was initially one of the toughest users changed her tune when she had to learn the new system. She said something like, "After using that new system, I realized yours was a godsend. It takes me 3 times longer to produce a bill on the new system".

I also happened to maintain a reporting and graphing system that tracked the "capital turnaround", which was more or less the time it took to tend send out bills to customers after recording the charges into the accounting system. (The new system had no ready replacement for turnaround analysis, so my original one was still used after the conversion.) When the new billing system was put in place, the turnaround time doubled. Management initially attributed it to the learning curve of the new system and gave it more time. (They budgeted in some amount of conversion delay costs.) However, the curve stayed high for several months and there was talk of a financial crisis due to lost interest and missing billing items. They eventually brought in more billing staff; in other words, threw bodies at the problem.

The thing is that the success of my original system (and other successes) never brought about significant raises or formal praises. Users dug it, but that did not translate into official rewards on my part. They later outsourced my position just like everyone else's. I learned an important lesson: Happy users satisfy the soul, but not necessarily your career. It is still who you know more than what you know that counts. Sometimes you just have to take personal satisfaction alone as the sole payment.

Another interesting moment was when I was asked to "clone ebay" by building an online auction system in 4 weeks. I actually pulled it off, but was tired as hell at end.

-- top

(By the way, anyone want to hear my anti-tree epiphany?)

Circa 1991, I and one other guy (Hi, Chris!) wrote a program to record and play back automated tests of mainframe 3270 programs. They called it, oddly enough, Automated Testing System, or ATS. It took us 3 months to do it all: requirements gathering, design, and coding. They they ran out of money and didn't renew either of our contracts. Six years later I was updating my resume, and called the ATS project lead and asked him how it'd fared over the years. He said that a) they'd lost the source, but not the compiled program, in some sort of crash shortly after the end of development, and b) they still used it, and it was essentially bug free. -- Larry Clapp

I wrote a software simulation of a proposed hardware solution to a computationally intense task. So that I would have correct results to test the simulation against, I created a simple-to-prove-correct algorithm that I thought would be reasonably fast (so I could conveniently test on fairly large, complicated datasets). Then I wrote up the report and sent it off to the client, together with all the source code. Among the feedback I got was that someone had been intrigued by the reported performance of my test implementation, compiled it himself, and found that it ran twice as fast as their programmers' best efforts. Fortunately, that only whetted their appetite for the hardware version.

My best moment lasted a whole day. It was the time I over-estimated on what turned out to be a simple solution, and wound up earning $1200 per hour for eight hours of work. (Invoice for less than the estimate? Of course not! A software mercenary gives no mercy.)

Once I wrote a web crawler to download pages from competitors' bookstore websites to collect price list, image, title, synopsis, etc. And later parse those pages, and import all to our website. Still remember how good it felt to import something like 10.000 books in 4 hours. Imagine how long it will take to manually type those things, maybe 3 months! Well.. I was still young and full of creative idea.

Until you and/or the company get sued for copyright infringement. I was once working on a project that had similarly pilfered catalog info from a competitor (perhaps you did it). When I pointed out the info was growing out of date, they quietly admitted that they stole the info and didn't want to continue because it would risk cluing the competitor in on the copying.

Your best moment here...