Echoes From The Pit: A Beginning

I hadn't thought so far in advance. I was staring at a blank code editor, the carat blinking in half second intervals with no text behind it. At this point I only had the most nebulous inkling of what this thing was going to be. It would need to take words in one computer language and reconstitute them into something else. There’s always this tension when writing code between a sort of punk-rock hacker attitude and the deliberate thoughtful process of an engineer--I often either  fall into it  face first and risk causing costly problems later or intellectualize the problem into meaninglessness, being paralyzed by my own good intentions and hopes that I won’t just find a good solution, but the best solution. Hesitant, I write the first line.

string[] delim = new string[] { ":: " };

The class it sits in is called Parser. The namespace that surrounds it is called Silk. Objects like Silk already exist, but this one is mine. There’s something to be said for code you write to solve problems that you alone have created.  When I was in the throes of learning how to program, I often found problems that I didn’t know the answer to. Furthermore, I was beset by many more problems that were unknown unknowns, which was a massive impediment to learning how to think computationally. How could I, when I didn’t know the problem existed? I came to solutions that were weird or sometimes obtuse, but they were mine. In the dark past of last year, when I wrote the first hideous version of _transfer’s graph traversal algorithm, I barely knew that the term “graph traversal” existed, much less how deep a hole it was. Suffice it to say, graphs are a solved, but extensive problem. Plenty of people with way more experience than I have worked on them for their entire lives. And here I am, a late-20-something gamedev with no background in computer science basically making it up as I go along. The funny thing is that sometimes I get it right.

Now, what getting it right means differs greatly from person to person. There have been philosophies kicking around for a while that espouse the virtue of the “egoless programmer”, and while I understand the value of not letting my attachment to my work get in the way of the ability to change it later, seeing code as completely objective is naive. Programming is seemingly the purest representation of logical thought we can muster. Machines cannot think, after all, they can only run instructions. However, code itself is a designed artifact, as is everything it is used for. This comes front loaded with its architect’s values, expectations, assumptions,  and life experience. As far as I’m concerned, no one, no matter how analytically inclined, is capable of making something and removing themselves entirely from the equation. The decision, or necessitation to attempt objectivity is in itself a reflection on the creator. So why do we want to get ourselves out of our code so bad?

Why do I want to put myself into my code is the real question. Beyond wanting to know it intimately, I sometimes simply prefer systems that haven’t had all of the edges sanded off. They feel more human, in a still cold mechanical way. Plus, I know my audience better than anyone, and I know what I need this thing to do. Even if I haven’t quite figured it out yet. I type on.

void SplitTokens(string newText)

{

//something will go here soon. I promise

}

This is a beginning I am okay with.