programming

(If you haven’t read part I, make sure to start there!)

After a night of hardcore, sloppy programming (a phrase that just missed being caught by my work’s naughtiness filter by a single word), we had a program that did the exact opposite of what we intended. Meaning: it didn’t do anything. The next day, my small group went to see our professor shortly before our project was officially due to get some last-minute help. After listening to our sob story and suppressing one’s natural instinct to laugh outright, he actually took pity on our hapless souls. Realizing that we had never before been put into such a situation and could learn a valuable lesson, he gave us some advice on how to fix our program and granted us a couple extra days to get our act together. Our professor’s advice essentially boiled down to this:

Scrap what we have and start over from scratch
Break the overall program down into chunks, and design each chunk individually

(more…)

For my first instructional posting, I thought that I’d reach back to one of my finest failures in my history of being a programmer. This little tale harkens back to when I was first starting out in programming, back to my freshmen year in college. I never did a lick of programming prior to entering college, unless you count hacking away at the BASIC source code for that hidden artillery game in DOS 5.0 when I was supposed to be paying attention in high school typing class. Actually, doing that was quite fun, making the explosion radius half the size of the screen — I even showed the trouble maker in the class how to do it, which promptly got him in trouble with the teacher. He never did have that innate instinct for ALT-tabbing when said instructor was walking past you.

Note quite the same game (this is from Blarworld.net), but close in appearance.

(more…)

How NOT to design programming code, part II

How NOT to design programming code

Recent Posts

Archives

Categories

Good tech reads

Links