Coding Your Own Stunts: Good or Bad?


When I tell other entrepreneurs that I am half of the development team for 7 Generation Games, I’m met with a variety of reactions, few of them good.

  • Polite disbelief: “So, you just use like Dreamweaver or WordPress to clean up some html, right?” Um, wrong.
  • Disapproval: “As CEO, aren’t you supposed to be doing more important things, like fund-raising or strategic planning?”
  • Condescension: “Well, we outsourced that. I’ve got some very good people in Elbonia who will work for $32 and a pound of goat chops per week.”

goat meat Thank you David Blaine for posting the lovely picture of goat chops on wikimedia.

Sometimes I feel a little defensive about this and point out that I do have two other co-founders, without mentioning to the skeptics that one of them in fact does nothing but coding. The truth is that it would never be possible for me to do all of the coding and everything else by myself. In fact, the limits of growth with a sole founder are a topic for a post in itself, but let me say that I certainly understand why investors tend to shy from sole founder start-ups.

Other times I want to point out that I have managed to write grants funded for over $550,000, as well as working with one of our co-founders to run a successful Kickstarter campaign.

The truth is, I think there are a LOT of benefits of coding your own and having another co-founder available to handle much of the tasks of applying to incubators, presenting at trade shows and other marketing has allowed our company to enjoy these benefits.

First of all, there is the speed at which changes can be made and decisions executed. I know exactly how our backend development is going because I’m doing it. If I decide that we should have the fields be text instead of numeric to allow students to enter answers like “6 years” instead of just “6”, I can implement that change now. Similarly, I can make the decision to have most of the error-checking done after the pretests have been submitted and just make the pages that way. There is a good reason for this – I want to capture as much data from the students as I can, and if they get frustrated because the page won’t accept 5 and 1/3 as an answer just as well as 5 1/3, and quit doing the test, I’m losing data. As I was looking at the database today, I thought, you know, I don’t just want whether the answer is right or wrong. Whether students selected the same wrong choice more than others may give me useful information. So, I changed the function for the multiple choice items. (We don’t have many multiple choice items, but there are a few.)

Secondly, when we get requests for changes, whether from our staff or users, I can confidently answer them as to whether or not the change will be made and when, because I know exactly the complexity of the task, as well as a general estimate of how long the other programming tasks on the table will take.

Third, as I’m working on a part of the game, I can see ways to work better, that I might not have considered if I wasn’t actually doing it – maybe this question with the rabbits can bounce in, that might make it more amusing. We could have the Ojibwe word for “rabbit” play as the page loads. Now, these aren’t integral to teaching math (though the latter example helps teaching the language), however, I’ve found that all the ‘juice’ – sound effects, unexpected animation even in the math challenge pages – amuse kids and that keeps them playing.

It’s not all a bed of roses. There is the obvious fact that it takes me personally away from always pitching to investors, going to meet-ups and meetings with school district personnel. The fact is I’m really comfortable sitting here coding in my office and I probably do less of the other tasks than I should because I really do like programming. There again is where having co-founders is helpful because Maria will insist at least a few times each quarter that I present at conferences, pitch to investors or write a grant. While I’m off doing that, Dennis can pinch hit on the back end development if necessary.

The other disadvantage, maybe, is that I don’t justify or document things as well as if someone else were going to do them. When I make a decision, whether it is to support Windows XP  (No.) or allow free-form input over structured data (generally, yes), I’ve given it some serious thought and usually have what I think are good reasons. I do discuss these decisions with my co-founders and other staff members, but maybe more discussion would occur if I really had to explain to someone else why he or she had to do things. It’s also possible that if someone else was doing the coding more documentation would happen. Dennis is really good about commenting his code, but I’m terrible, always have been. We have a great guy, Ernie, who has done some good work on a tech support manual and website. Every couple of months or so, I bite the bullet, sit down and go through the code and wiki and update everything.

Some people would say this is bad, and maybe I’m just justifying it, but one advantage is I often think of better ways a couple of months later, when I’m doing the documentation and clean up the code a little bit. I also  think reviewing what I’ve written several weeks later is a good thing, just as a refresher when I’m off on something new.

So – do you code your own? Yes or no? Good or bad? Should I do like some people suggest, grow up, buy more suits and go out and do more CEO things?