I am not a very smart man. I am going to repeat that because, listen, it's an important point and we will touch on it time and again. I am not a smart man.

I make istakes. Er, mistakes. They happen and, in fact, do so with alarming frequency. Big ones, small ones, and, on the exceptionally bad days, slimey ones. Of particular note is a recent design decision, the subject of this heady and, in retrospect, brash blog. Remember all that oh-so-clever stuff we put down about heterogenous collections and the application of the visitor pattern? Yeah. Garbage. Clever garbage, let's make that clear, but prodigious in its garbageness.

Here's the problem. I got righteously caught up in this whole, "oh man i man going to encapsulate the bejesus out of all this noise and be the most kickin' software engineer who ever done his buisiness." And in that, I barfed out a design that glistened with what I hastily proclaimed its "best practices" luster, but one altogether too corpulent in its excess. Thankfully, I took a step back and looked at where that bullheaded application of ungrounded ideals was taking me. It was a bad idea, pushing up the system complexity and adding a layer of clumsiness to the whole process without any real gain. At the end of the day, I decided all I wanted was something simple, easy to work with with, and open to expansion.

Anyway that made things clear. I relinquished the idea of the visitor-builder before implementing it because, at the end of the day, it didn't sit well with me and I think I'm glad I did. I mean, you can see the hesitancy in that blog and I should have gone with my gut rather then trying to follow through on an idea because it was attached to some vague notion of correctness. The bulk of the building process, including registering components with engines, ended up tucked inside the components themselves. So here we go. I think this is better. Writing it out, it feels better and I should have taken the time to sit down and think about the root of the problem at hand. The visitor pattern works and, hell, we could make it work, but that's simply more structural complexity than we need.

So, this is maybe cause to doubt all my deicisions and, well, that can be good or bad, but what I'll take away from this instead is that I should trust the force - er, my intuition. If I find myself internally resisting an idea or implementation, it's essential I take the time to put a name to whatever it is is giving me pause so I can decide whether or not it's a legitimate concern. I would say it's to my benefit to keep in mind engineering practices and overall design policies, but they are guidelines, not laws and it is goddamn important that I critique my choices and have more concrete justification for the decisions I make.

At a talk I recently attended, the speaker discussed the importance of making mistakes and, this is the important part, learning from them. In this project, I'm going to arrive at some bad ideas and on more than a few, I won't realize just how bad they are. In this case, I chose a method that was more convoluted than it needed to be. However, in doing so, I picked up some techniques that I can see greatly benefitting the concept of components, our disreputable visitor among them. As long as I can learn from what I do wrong, I'm doing something right. The truth is that I'm not in this so much to make a game as I am to learn to make a game, so let's do that.

Wow. You can cut the shmultz in that last sentence with a knife.