By ASHISH AKSHAT
As I prepared to test a program I’d been working on for the better part of the weekend, I prayed that this time it would finally work. I typed in the relevant commands, and hit enter.
An error message popped up: “Seriously, give me an actual number.”
While I had enjoyed embedding mildly sarcastic error messages throughout the program, it was less funny when I received one of them. The cycle of debugging and re-testing started again, with sometimes more dismissive errors.
Oh wait, I don’t actually code for a startup (yet!). I’ve been working on an assignment for my Intro to Computer Science class. I’d figured that this class would be a pushover, what with my two years of high school experience in coding and getting “A’s” on the finals, along with the programming I’d done for fun. I was going to be fine.
I was so wrong.
The assignments given in class — writing long, functional and useful programs — are different from typical startup tasks, such as learning all the features of a new language or playing around and writing small programs that solve very specific problems. Long programs have a lot of errors, and that is taken very seriously in class: we’ve had entire lectures on error handling, creating meaningful errors to trace mistakes and making sure mistakes are discoverable. It is not a question of whether there will be bugs, it’s how many. Even all that had not prepared me for the avalanche of errors an assignment for class would give me.
Simple procedures like adding quantities seemed to break midway through running. I had heard of communication problems between programmers working on different parts of the code, but it turned out that I couldn’t get different sections of code that I had worked on to work.. I had misunderstood what I had written last week, 400 lines ago. I realized that the lectures on handling and dodging errors were probably the most useful of all lectures. Designing my own error handling mechanisms gave me better error reports than the cryptic errors one expects from a computer (think Windows’ infamous Blue Screen of Death).
That is what programming for the real world is like: the actual code that does the “trick” — optimizing traffic lights or sorting customers’ pizza preferences by age — is often a few lines long, but setting up the foundation may take hundreds of times as many lines. Thoroughly testing each part takes thousands more. Indeed, good programmers don’t live without errors; they learn to anticipate them and have practice at handling them. And without that practice, the smartest coders of the world are at a loss.