Instead of the internet, I lurked around the local library for game magazines with source code listings in the back.
I love this. I did the exact same thing at my local library looking for books on BASIC (now I lurk on HN instead of at the library). I always had trouble getting the code listings to work because they were usually written for a slightly different version of BASIC than what I had. Without the internet there wasn't really any way for me to figure out what the problem was so there was plenty of trial and error.
One of my best memories was finally buying Tricks of the Game Programming Gurus by Andre LaMothe. I remember reading almost the whole book the first day I got it and trying out all the great code examples. This was the first time I really saw how real games were made. It basically runs though making a game like Wolfenstein 3D only two years after it was released. I think it would be a struggle to write a book about how to make a triple A title from 2010.
Near the end of high school I stopped coding but when I got back into it several years later, I was amazed at the resources and tools freely available on the internet.
Looks good. I haven't heard of Speechhub but I look forward to your tutorial.
I recently added a blog to my static GitHub page using Jekyll (http://atomyard.com/blog/Blogging-with-Jekyll/). I found Jekyll to be very easy to use (and it's built right into GitHub) so I'd be interested to see how Speechhub compares.
Speechhub is much more simple then Jekyll. Actually, I last just few hours of two half-days on this project.
For sure Speechhub has lots of restrictions (no sintax highligh for codes, no comments but Disqus, no documentation ...), bu I intend to work on it ass soon as possible.
In the future you might want to consider Jekyll-Bootstrap (http://jekyllbootstrap.com/). It simplifies a lot of the early configuration and adds theming, commenting, tags on top of Jekyll.
I used to be of the opinion that the technical people did all the hard work and hence they should get the majority of the equity. However, once I tried to do everything myself I realised that the technical side was only one piece of the puzzle.
Business, design and marketing may not be as intellectual as programming but they are no less hard and often more important.
I really think that if two people are involved, the equity split should be 50/50 regardless of the skill set each one brings. If the equity is unbalanced, the level of effort each founder brings will be too.
1. Whether they're "no less hard" depends on who's doing it.
2. Many people claim they can do these things (at least, the "business" and "marketing" parts) - hence the surfeit of "nontechnical cofounders". But not all of them can.
3. There are fewer potential technical cofounders available in most areas.
4. Therefore, as a technical cofounder, you should pick only the best nontechnical partners, who will justify an even split of the equity. If you really don't find anyone who measures up in terms of demonstrated ability to hustle, connections that can actually be used, great business plans/prototypes and/or an impressive work ethic, then is it really worth starting up with a mediocre-or-worse cofounder?
5. If you insist on taking a nontech cofounder and you have only multiple mediocre suitors to pick from, it makes sense to me to offer less equity. If your potential partner feels it isn't fair, then look for someone else who understands that the product makers have precedence in this market.
Personally, I think making a good business plan and doing marketing may be as hard as programming at times, but at this time, more people claim to be able to do business-side things than coding. That fact in itself justifies the tech cofounders' being picky with their partners.
I think tech cofounders shouldn't let the thought that "oh, they work as hard as me" mislead them into partnering with someone who doesn't have capabilities that equal theirs, adjusted for supply and demand.
The problem is that, often times, much of the technical work is front-loaded, leaving most of the initial risk disproportionately in the technical person's lap. It's only after an MVP is built that the business side of the operation has to perform. Equity split should reflect the assumed risk.
That’s a fair point. However, there could also be front loading in the business role. Sounding out the market, figuring out who your customers are and what they want - the sort of stuff that should be done before writing any code. Isn't that still a significant amount of work?
There is also an interesting podcast on the process: http://theamphour.com/the-amp-hour-113-sudden-sinoamerican-s...