GIGO

Warning: Boring technical information to follow. This is really only me reflecting to myself on what I've learned from my last project. Feel free to skip over.

There used to be a saying in computers: GIGO. It was an acronym for "Garbage In, Garbage Out". It was a cute, simplistic acronym for a concept that is essential in computing; it doesn't matter how good your logic is it isn't based on good data to begin with. In recent years we've started to change models to one that more closely resembles this one: "The customer is always right." Whereas it used to be understood that if you wanted to use a program, you would first read the instructions and/or help files in order to understand what the program wanted of you, it seems like these days most users expect the programs to present themselves in a way that makes sense to them, and if they don't get the result they expected, the computer is wrong.

Why am I musing about this? I recently wrote a program as part of a contract job, and I was asked up front how long it would take. I gave an estimate that turned out to be considerably shorter than I actually needed. The problem was that I was thinking about how long it would take to solve the technical problems, but it takes a lot longer to solve the human ones. Tying in to libraries for database connectivity, encrypting data, calculating elapsed time, converting data formats, and tying it all together in the algorithm that most succinctly defines the problem only took up about two-thirds of the time. The rest was taken up defining the user interface and formatting the output, verifying all of the input data to make sure there can't be any unexpected behaviors, and most importantly checking all possible exceptions to make sure that there is a relevant error message that accompanies it (That's a huge pet peeve of mine, lazy programmers not bothering to create relevant error messages and instead leaving messages that are at worst completely misleading and at best uninformative. "Unknown Error" comes to mind). In the end what I came up with was really not that great presentation-wise, either, just a simple command-line interface.

So what do I take away from this? I've gotten a lot more experience in anticipating users' requests, and I've started researching a few new tools that I can use to present a more intuitive front-end for my programs. In the past I have mostly coded for my own benefit, so I haven't had to think of it much, but over the past year or so I've been trying to code everything in as generic a fashion as possible, so that I can with little change conform my programs to whatever need arises. Another goal for the upcoming year will be to write all code from the beginning as if someone might have to use it. This will probably mean creating some user interface templates that my functions can "plug in" to, insulating the user interface and internal workings of my programs from each other. I have a feeling that some of these things I'm learning thorough experience have fancy names and would have been taught to me if I had gone through a Computer Science degree program.

To sum up, here are the things I want to work on in the coming year:

1. Write more modular code
2. Get more experience with the various UI modules
3. Set up a better lab environment in my home for testing
4. Learn Python
5. Learn Monad
6. Get more experience with C/C++
7. Get more experience writing web applications
8. Finally get past level 8 in Action Mode on Bejeweled.