I stared at the screen in front of me, watching the green text scroll by on the black background. Lines and lines of information, most of it moving by too quickly for me to read.
Of course, I knew that I didn’t have to strain my eyes to capture those fleeting words. Everything was logged, was being saved and preserved.
I leaned back in my chair, interlaced my fingers behind my head, closed my eyes…
…and then opened them in annoyance as the computer beeped.
It wasn’t supposed to finish that fast. And sure enough, as I looked at the bottom of my screen, I saw an error. Some inane code, followed by a bunch of gobbledygook that doesn’t make sense to anyone except the programmer who wrote the thing a decade ago or more.
My program was still sitting there, confused, waiting on me like a dog that doesn’t know how to proceed when faced with a new obstacle.
I grimaced, and then killed the program.
Killing programs… it sounds so vicious! Like an act of violence, not simply the press of a button. Yet although it’s just a couple of key strokes, the act does have an almost satisfying finality to it. The click of the keys, and the program vanishes, aborted before it can reach its normal conclusion.
I’ve seen some programmers that exult in this savagery. Although they can’t kill the alpha males that walk around the building, bragging about their sales numbers and effortlessly scoring women hotter than the programmer can ever hope to bed, these quiet and introverted individuals can kill their programs, at least exerting their control over something.
Some programmers even force their creations to kill each other. I remember reading over the code of one especially bloodthirsty colleague, notorious for creating subroutines basically only to slaughter them en masse a dozen lines later. Even I felt a twinge of squeamishness at the sight of that writing.
Opening and closing files is done all the time, of course. There’s no real violence there, no more than hanging up a phone call. But programs are alive, are in motion, and premature termination prevents them from reaching the conclusion they strive to achieve.
Of course, most of the time it’s necessary. Now, for example. My program isn’t running right. I killed it, but only to open it up and perform surgery, after which I will breathe new life into it as I try the commands again. It is not a true death, but merely a nap, a temporary spell of non-existence.
And, paradoxically, the more I kill a program, the more I appreciate it, come to love it. Some of my programs have been terminated hundreds of times, but each termination leads to new growth and improvement. I kill it, but bring it back each time to be stronger than it was before.
I am not like some of my colleagues, I tell myself, as I open up the code to search for the source of the error. I love my creations, and want for them to succeed.
But still, I cannot completely purge myself of that desire to shatter the programs I write, to cut it apart and dissect it into single-line fragments.
If I could speak to my program, if I was forced to tell the truth, I know what I would say.
“I love you, but I can’t wait to kill you.”