So often these days we visualize a problem and try to attack it with the most scalable and high-tech solution. As more and more systems rely on automated solutions, the human element is consistently pushed lower and lower on the scale of importance.

This article by Derek Sivers is a great side-step from that ideal. In a market where everyone is automating, a great way to stand out is to integrate a little more human intervention. I completely agree, and at OverDog we have many challenges where this applies. It’s a great (and short) read.

My day usually starts with browsing the daily newsletter from CodeProject. Today I found this article from BBC entitled ‘When are we going to learn to trust robots?’:

http://www.bbc.co.uk/news/magazine-21623892

As a programmer, I understand that we can hard code limitations, checks, and fail safes to ensure that a robot is as far from harmful as possible. However, the question in my mind isn’t whether we can trust a robot; my question is whether we can trust the companies and people who develop and maintain a networked connection with them. Robots are a tool, at least at this point in history. They cannot freely make decisions, ponder their reality, or intentionally harm anyone. However, like a firearm, it’s the user who is in control of the tool who causes the real damage.

So, I’m perfectly comfortable with a programmable robot in my home. It’s my lack of trust in peoples’ intentions that makes me wonder if a robot in every home is really a good idea.

With our Kickstarter stuff, and only a few weeks left of development time before beta release, I’m too swamped to post today. Expect some interesting posts this weekend to make up for it!

OverDog is my first project which uses Xamarin, a cross-platform tool for creating applications in C#. I love the platform, but one of the first learning experiences I had when I dove into development was the linking functionality built into MonoDevelop.

The linker basically reads your applications possible execution paths and removes unused code. I was unaware of this functionality when I started development, but soon ran into problems when trying to deserialize some JSON into a class I created to hold user data. The JSON.NET library was telling me that my class was missing a default construtor, which simply wasn’t the case. After pulling my hair out for awhile, I came across Xamarin’s documentation on the subject.

I alleviated the problem by attaching a [Preserve] compiler tag to each of my data model classes. To prevent all members of the class from being touched by the linker, you simply add an AllMembers argument:

[Preserve(AllMembers=true)]
public class User
{
...
}

That solved my issues with the linker. This was a huge headache without any obvious acknowledgment by MonoTouch that this was occurring. What was confusing to me is the fact that my application’s execution paths should have included my model data classes. The fact that they were being chopped up by the linker seems to be a bug.

I recently moved my PC to the living room, hooked it up to my 32″ LCD, and started using an Xbox controller for gaming. As a big PC gamer and also a programmer, this just made sense. I got sick and tired of gaming from a computer chair with a mouse and keyboard, where I already spend 10+ hours of my day working. However, last night (as I gathered building materials for my house in Skyrim) I started thinking about my personal motivations for playing video games.

Sure, they’re fun. But real life is fun too. What is so entertaining and relaxing about a video game? The first point I came up with was instant gratification. I’m an extremely impatient person by nature. I can’t stand lines, traffic, or waiting in general. The ability to press a button and instantly engage in a mentally stimulating activity from the comfort of my couch is extremely appealing.

Another thing I enjoy about video games is the feeling of accomplishment when you hack off the head of an ogre or locate that lost treasure. But we all know these things aren’t real; so, what makes it feel like a true accomplishment? I came to the conclusion that the Epic Sword of Doom is just as useful, if not slightly less tangible, than a sports trophy or blue ribbon. An accomplishment is as internally important as the feeling generated by it. Maybe I’m not bettering the world when I finish my dream home on Skyrim, but it still feels like more of an accomplishment than watching ‘Cops’ re-runs. Being an extremely driven person who has a hard time relaxing, the ability to both accomplish (even if it’s just pixels) and relax at the same time quells my guilt at sitting on my ass after a long day at the office.

- Kiefer

Hey there, welcome to my blog.

My name is Kiefer. I’m currently a software developer for a company called OverDog, a Nashville-based tech start-up whose goal is a system where professional athletes can challenge fans to video games. This is an interesting case of social connectivity, and I’m extremely excited to be the primary front-end developer on the project.

A little about me: I recently moved across the country from Olympia, Washington to Nashville, Tennessee. I’m loving Nashville so far. Great people, great music, and great food.

Computer programming started out as a hobby for me. My interest came from a love for video games, and a desire to understand how they work. My first foray into anything related to software development was Campaign Editor in the original StarCraft RTS. The idea that I could not only enjoy a video game but that I could also manipulate it and create new worlds blew me away. It also gave me a little insight into the logic behind a program: from inputs and triggers, we get output. We follow the path of those inputs and try to generate the proper output.

From there, I dove into Visual Basic 6 and started teaching myself. My first project was a RuneScape “client” and server switcher (which was really just a web browser wrapper with some tools attached to it), which taught me the basic concepts of variables, loops, custom data types, etc. Module based development is interesting, but it wasn’t until I decided to study software development professionally that I moved toward a truly object-oriented approach. My first OOP experience was with Java. I hardly touch the language anymore, but it showed me the light of C syntax and the joy of OOP.

This blog will be my showcase of problems solved, roadblocks vaulted, and tears shed during the coming weeks and months of OverDog development, as well as my personal projects (mostly related to video game design and development). I hope you enjoy the reading material and learn a thing or two. I’d also love to learn a thing or two from you, so feel free to comment and tell me when I’m making a fool of myself.

- Kiefer