[ Previous entry: "Punkie Needs to Heed Warnings from Friends" ] [Main Index] [ Next entry: "Do you remember where you were when...?" ]

03/19/2003 Entry: "Happy Programmer" I have spent the last few days deep in PERL. I am typing this as my brain takes a break, but I have been instructed at work that a MAIN priority is to write this PERL program, after months of delay by other projects. Finally. Real work. I do programming in several stages. First, I get hard-core, defined lines of what I am supposed to do. No "make this program chart blah" is acceptable. What is the input? What will be the output? Who will be using this data? What are you doing this for? What defines a demarcation for you? Knowing this before you write the code makes it more flexible. Like for instance, if someone says, "I need a program that counts how many calls on this system report a bad TCP/IP stack," I ask for ALL the error codes. That way, when they go, "Oh, and how about count all the calls that report a Carrier Loss?" all I have to do is redo an equation, because I was already counting all possible outcomes. I learned this after a project where I was asked to sort two items, errors and non-errors. I had a simple program. Then it asked, "Well, how about how many errors per hour?" Total rewrite, and wasted time. Next, I write a skeleton of the program, something I call "The Plot" (where data is called "The Characters," I guess). All my programs have descriptive logging functions built in from the beginning so when something breaks, I know where. As I go through each plot element, I check what I have done, and fix any new errors that crop up. I also see weaknesses in my plot, like "Well, what if someone wants the data in another format?" It's easier to change this while you are building it, not six months later when you have forgotten what the hell you did. Once the plot is fleshed out, and the program works, I release it as a test candidate. I ask people, "Tell me if this is what you are looking for as output?" I get comments back, hopefully. I used to work with one person who never gave me any feedback when I asked for it, but yet would complain only at meetings ... months later. What a pain! I then start to flesh things out, look for "what if some bozo does this with it?" Like recently, someone started to change the spelling of the carrier. It used to be "SPRINT." Then they changed it to "SPRT IP," but only on SOME of the data. Of course, my program thought they were two different carriers, so they started to generate reports for "SPRINT" and "SPRT IP." Luckily, I had made adding these "oops" factors easy, and with one line of code, made "If the data says SPRT IP, it really means SPRINT." I also deal with capitalization, because some people will have data that says "Sprint," "SPRINT," and "sprint," and I have to plan for that. Then I deal with "what happens if the program or data gets corrupted?" Like I get data in a different format suddenly? Well, sadly, I just do a "Can't figure this data out - Ending program," and then get notified by the program before anyone else notifies me. I try to make my programming proactive. After I have released the program, I do maintenance work on it. My logs help me figure out the real-world problems I hadn't thought of. Like when the network is down, what happens to those systems mounted with data network shares? How will my program deal with that? Or when someone spells "SPRINT" wrong? Or when someone moves the data to a different area? You'd never believe some of the stuff that creeps up. Last, I try to be as user friendly as possible. Recently, I wrote this line of code: sLog(1," ... $test_path NOT found!"); sLog(1," ... $system_name may not have written tests for this day - check $system_name"); sLog(1," ... check to make sure of correct spelling, capitalization, and path mounts (smbfs/nfs?)"); This is a fairly descriptive error with even some helpful self-diagnosis suggestions. On some of my Visual Basic programs, my dialogue boxes have things like, "Error #2006: Pathfile to data not found. Please check your path file, without trailing backslash, and start again. If this error persists, click 'Send to clipboard' and paste error it into an e-mail, and send it to [my e-mail address]." What gets put in their clipboard is the last few lines of the error log, which will have a very descriptive series of events. That way, the user doesn't have to cut and paste, or try and remember or spell things they saw on the screen. I really try and make my programs as helpful and friendly as possible, and keep the end user in mind. Sure, I could just end the program without a peep, and let them fend for themselves, but that's mean and unfriendly. This is why I get chosen a lot for programming at my company.