Have a Programming Party

Want to have a completely ridiculous amount of fun this weekend? Plan to have a programming party! Yes, a programming party. In one day you can combine the three guiding principles of Amphibian.com - thinking, building, and playing - together with your friends, pizza, and beer.

Here's the deal. Back some 15 years ago, one of my favorite activities was getting together with some friends in a unused, run-down room off the side of a honey bottling plant with a couple computers and writing software. Yes, I know that sounds a little strange but don't let that distract you. We were writing games for BBS's. That's Bulletin Board Systems for you kids that don't remember a time before the Internet. We'd eat flavored honey, drink RC Cola, and write what was probably terrible code, but it was great fun.

I think back to those days often lately, because if you look at the types of software products that are really making news today you'll find them to be striking similar to the old BBS games we worked on. They were small, turn-based, social games - the same kind you'll find on Facebook or your iPhone today. Except we don't use ANSI graphics anymore. That's a shame. But the point is that if the "programming party" paradigm worked for us back then, think how much better it can work today!

Goals of the Programming Party Paradigm

1. Development of a small game or game framework in one day

This seems like a lofty goal. Does a small game have any chance of really being completed in a single day? Well, keep in mind there are 24 hours in a day. And if you have 5 friends working together, that's like 120 mythical man-hours that can be squeezed into a single box on the calendar! Alright, so I'm not serious. I don't think you could actually have a polished, bug-free, ready-to-go application done in a single day. But you could have a playable, slightly buggy, half-working application done enough to share with other people. That should be enough to convince you to either meet again to finish it (after taking feedback from your testers, a.k.a. other friends) or use what you created as the springboard for your next project.

2. Creativity in design

Don't host the party as an attempt to extract free labor from your friends. If you have an idea for what you'd like to create, great. But the point of inviting people over to the party is to get creativity in the design. You need to all throw your ideas together, bounce them off each other, throw out creative feedback as soon as it jumps into your heads. Even if they deny it, I think most people who write software are creative people. They are creating things every day. They combine different software packages together to come up with new and interesting things. When you put a whole group of creative people together with the goal of coming up with something fun and cool, it will absolutely amaze you what can be produced. Yes, software is math and algorithms and logic and a whole bunch of other dull-sounding things, but to make software products that people are really going to enjoy takes a creative touch. Windows 7 and Farmville are both software products, but people enjoy Farmville (although I don't know why). Do people enjoy Windows 7? Eh, maybe if they used Windows Vista they'll say they enjoy Windows 7 because it doesn't suck as much, but that's a whole different meaning of enjoyment. Windows is a tool. Farmville is entertainment, made by creative people. While I guess you could use a party to make a tool, I really think they are best suited to making fun-to-use software that is like nothing the world has ever seen before.

3. Social interaction and fun

There's a stereotype that programmers are loners. Freaky nerds who like to sit alone in poorly lit basements cranking out code. I think people who like to write software are just as social as the rest of the world, but they have a harder time finding people to socialize with. For example, when I am visiting someone, usually because I've been dragged someplace by my wife, people try to talk to me about the local sports teams, or last night's episode of American Idol, or something along those lines. I have nothing to add to conversations of that nature, because I don't follow any sports teams or television shows. But if someone started talking to me about the new Facebook social graph API, I could go on for hours. So getting together with people who share the common interest of programming will be great fun. Even if you don't actually produce anything that works in the end, you'll have probably learned something and had a great time anyway. If you are tempted to try having your programming party over Skype or something like that, think again! You've actually got to get in the same physical location as your friends. Back in the BBS days, this wasn't optional. We were programming in DOS mostly. There was no multi-tasking OS to let us use Borland Turbo Pascal and dial up to BBS chat at the same time (in fact, many BBS's only allowed one caller at a time anyway!). If we wanted to talk to each other about what we were developing, we had to meet in person. It worked for us then, and it will work today.

Programming Party Plan

This is my outline for having an effective and fun programming party.

1. Set up your location. To use my old BBS programming analogy, set up your own honey plant. Everyone in attendance will need to have a computer to work on and a place to sit. Ideally, everyone should be in the same room or two really close rooms. Set up folding tables and chairs if you need to, and get extra furniture out of the way. If people are bringing their own desktops or laptops, make sure they can all hook up to your Internet connection, either wired or wireless. You should also try to have a whiteboard or similar large drawing area nearby.

2. Do your homework. Depending on what type of application you plan to create, you or some of your friends may need to do some research before the event has to start. You don't want to waste a lot of time the day of the party reading whole books, so make sure you tell people in advance if there is a particular topic they should brush up on. Using the Internet to look things up while working is one thing, but you don't want to spend too much time learning the language you are trying to work in while you're working.

3. Start with a schedule, but be flexible. I would recommend getting started early, like 0900. Plan on going until at least 2300. Make sure everyone has a good breakfast, lots of protein and Mountain Dew. Do a couple hours of brainstorming for ideas, then order some lunch while you get started on the programming. Keep in constant communication throughout the day, so if anyone gets stuck on something they can get immediate help. Take breaks every 1.5 hours and have a snack. And more Mountain Dew. Order some pizza for dinner, then break out the alcohol. You don't want to start drinking too early in the day, or the code will get really messed up later on. See what you end up with at the end of the day!

Addressing Criticisms

Many will read this and think I'm crazy. "This will never work!" they will cry out. "Games take years to develop and millions of dollars!" If you think that, you and me are talking about totally different kinds of games. I'm talking about casual games. The kind you pay $0.99 for on your phone or play against your friends on Facebook. They are no different than the old BBS door games. People like me used to crank those things out in no time, working alone, without the benefit of Google searches to help us out when we get stuck on something. This will work because the resources at our disposal today are infinite compared to what we had 15 years ago, and because when a group of friends get together to accomplish something fun they will never fail.

When you schedule your party, don't forget to invite me.