The expression “Couldn’t see the forest for the trees” may be clichéd, but it’s certainly accurate, and can be used in the reverse. Especially when you’re a beginning VB programmer and you’ve been asked to find and fix an error in a code sample. Two weeks ago, I was given a program that had a number of errors involving the logic used to navigate an array to display the array’s records. One of the bugs was the code to navigate the array, which improperly used the index numbers as well as used values outside the array. The program created a function to get the items needed to display, and used sub procedures to call that function when I issued a command to move to the next, previous, first or last records.
For the past two weeks, when I had class time, and time at home to work at this program, I kept trying to alter the code of the procedure to step forward and backward through the array. My brother, who is also studying VB and other programming languages, came home for this weekend, and I had him look through the code with me, to see what I had to do. We looked at the code for the function, and at the sub procedures, translating into English the code statements. It turns out that the line of code that needed changed was not in the function that displayed the array record, but in the sub procedure, that used the value determined by the function. The call statement to display the Next record displayed the record with an index number of the current record, and did not increment that value to get to the next value. The simple addition of a “+ 1” or a “- 1” to two lines of code fixed the bug, when I thought I had to rewrite the DisplayRecord function.
Having my brother there, to help decode what the program was really trying to do, helped me see which tree needed to be trimmed. I had been looking at a forest of lines of code, totally lost, and without a clue what needed to be done. Seeing what was wrong flipped a switch in my head that was so big that I’m still baffled by my earlier confusion. Anyway, this is a good example to remember next time, to carefully translate code into common language to diagnose what is happening and what should be happening.
Reading news like this concerns me about working in the game industry, but it also is a call to arms, to do my best as a programmer, and try to fight the good fight against the big quasi-monopolies like Electronic Arts. Companies like Cyan, which created the Myst series of games, began as a small entity, and changed the way people thought about computers and gaming. As much as I would like to work with a big, famous software company, I would relish the opportunity to work for a small, dedicated group of people who have a dream, and a desire to accomplish that dream.