GCS Professional Programmers Panel is Back

Last year and the year before, we did a panel at GDC's Game Career Seminar for students (and others) to ask questions of professional programmers. We're doing it again this year, and we want your questions!

If you have questions, you please tweet them with the hash tag #gcsppp and we'll select the best to be part of the panel. In addition, I'll be watching that hash tag during the panel and pulling our favorite questions from the audience to ask the panelists.

Our panelists this year are:

  • Mike Acton - Engine Director at Insomniac Games
  • Brett Douville - Formerly Lead Programmer at Bethesda Game Studios, now independent
  • Anna Kipnis - Senior Gameplay Programmer at DoubleFine
  • Sven Bergström - Developer for Celsius game studios and underscorediscovery

If you have questions for them, be sure to get them in early, and we hope to see you at the panel!

GDC 2013 – Programmers Panel

GDC is over, and it was fairly awesome. I'll have a quick "thoughts on GDC" post later, but I wanted to get the information for the GCS panel I participated in up as soon as possible.

GDC did not record this panel this year, but thankfully, we have a fairly good unofficial recording of the panel thanks to Jeremiah Ingham. (sssshhh, don't tell GDC)

You can also just download the file, if you'd like.

The only real resources we recommended this year were at the end, where I asked each of the panelists recommended a book, and here they are:

If you have other questions of the panelists, please feel free to ping us on twitter. We're all pretty approachable (especially if we can respond in 140 characters or less).

Open Environments in a Closed Office

I've been railing against open offices and office meetings (especially micro meetings) on my blog for the last few weeks, and I have one more thing to add to this series. I'd like to talk about creativity in a "meetingless" / "interruptionless" office. Generally, people that believe in open offices believe in the creativity of the micro-meeting, and they believe in the collaborative power of spontaneous large group meetings (hence the open office). There is some truth to the fact that a spontaneous large group meeting, or hallway discussions, can lead to some very interesting and creative decisions. But why? And how can you create a creative environment within a constraint of few to no meetings?

First, let me say that an interruptionless office does not mean that there will be no hallway discussions, discussions over coffee, lunch, donuts, etc. In fact, I've found that even in semi-closed offices, these happen more often, because people feel more at liberty to just walk around. There's no chance of them disturbing anyone directly, so when they feel the need to be creative, they'll wander the halls, go to the cafeteria, or sit in a lounge, and just talk.

Second, as I talked about in the "Meetingless" post, a Meetingless office doesn't have no meetings, it just creates a culture of most group meetings being optional, minimizes interruptions caused by meetings, creates times that are guaranteed to have no meetings, and creates alternatives to split-second, micro meetings and micro decisions that I feel are an overall team detriment.

In general, there are three things that I feel open offices achieve automatically, that a closed office needs to work on:

  1. Removing psychological barriers to communication. As I've stated before, I admit that walls create psychological barriers to communication. To remove these you need to create an atmosphere that people are approachable in and outside of their office. Team building (the next point) helps with this, but managers, and leaders have to take extra steps to make sure that they are approachable. A few suggestions are to implement skip levels, hold frequent one-on-ones (which you should be doing anyway) and to meet outside your office. Coffee shops and established open areas in the office are great for this.
  2. Foster team building.  This doesn't mean everyone has to do trust falls, but it does mean you need to make efforts to bring the team together. This can be anything from catering lunch (which is what Fog Creek does), hosting in office Happy Hours, office Board Game Night (a personal favorite), or other office parties. Just make sure people mingle.
  3. Create open spaces for work and discussion.  This may sound like it goes against everything I've said, but I do still believe in having portions of the office be open spaces. Sometimes, you want to get out of your office, sit on a couch, and relax. Maybe go with a few other team mates to look over a problem. Maybe discuss something in a smaller open environment. Make these comfortable spaces and give employees the means to work in them (laptops or otherwise portable workstations, whiteboards, lots of power and wireless) and people will.  Even more so if they know they won't disturb others by doing so.

Generally, I feel like, cost aside, closed offices create happier, more productive employees, and that the benefits of an open office can be simulated more readily than those of a closed office.

The Interruption-less Office

In a previous post, I talked a bit about why I'm not a fan of open offices, and one of the main reasons is because they are too prone to various types of interruptions that actually keep creative people from being "in the zone." In addition, the types of "meetings" that happen in open offices can actually create a culture where split second decisions and decisions between small groups are the "norm." While this is fine in smaller studios, it can become an issue as teams get larger.

First, let's look at the common types of meetings that are encouraged in an open office, or one that encourages meetings, and see how we can remove most of them.

  • Quick Questions – You know these meetings because they're always prefaced with the person interrupting you saying, "Hey, quick question…" Frequently these are anything but quick, and almost always it is not imperative that they be answered immediately. However, in an open office, the person will frequently ask you directly, which means you need to give an immediate response. These meeting can be handled in private chat rooms where the question can be either answered by someone else or answered at a more opportune moment.
  • Class A Bugs – These are bugs are actively blocking, and need to be fixed ASAP (and I'm talking actually ASAP, in that people are actively losing work). These things happen. My recommendations for this are, first, make sure that all bugs are documented and tracked. Frequently with class A bugs like this, people just report it to the person they "think" is responsible verbally. If they're wrong, you can get two people working on the same bug at the same time, which can be hugely problematic. Once the bug is documented and tracked then you can interrupt the responsible coder (or producer responsible for assigning it).
  • Micro Meetings – Micro meetings are when (usually) two people decide to discuss an issue quickly to try to come up with a solution. These actually have two forms:
    • Idea bouncing – One person has an idea they want to flesh out, or run past someone, and just wants to talk it out. Frequently, this doesn't actually require the other person, just something to talk to. (I know a designer that keeps a stuffed monkey on his desk for exactly this purpose). I'm actually okay with these types of meetings provided they do not actually interrupt someone's work
    • This Isn't Working – These meetings come about because someone feels something "isn't working" and needs to be reworked. In my experience, these meetings have several drawbacks, besides the interruptions they frequently cause. First is that they rarely involve all of the people that need to be part of the decision making process, which means that  certain people are left out of the loop and surprised by changes they didn't know were going to happen. Second, these meetings frequently cause or require snap decisions without a real good amount of thought, which can be problematic. Lastly, decisions made at these meetings can contradict other decisions that were already made and documented. Now not only do you have a change that isn't documented based on a decision process that isn't documented, but it contradicts documentation that does exist. Again, these are probably better handled in group chat rooms, so that all people invested can see the discussion, the decision, and update the documentation accordingly.
  • Micro Meeting Turned Team Creative Session – This is really what people that want open offices cite as a benefit of open offices. Start with a "This Isn't Working" micro-meeting which becomes a full fledge, whole room creative discussion about how various systems and designs should work, interrupting everyone. The results of these meetings can be great creatively, but because they're always impromptu and records are scant, decisions made can affect entire teams without their knowledge or input. These meetings have the same all the same drawbacks as micro meetings, except with the added benefit of you keep several members of your team from working (including those that aren't in the micro meeting) for several hours. These should be avoided at all costs
  • Actual Meetings – Then there are actual meetings, which I'm not against, but only in certain forms, which I'll talk about in a bit.

In general, you should be always be striving to move to an "interruption-less" and "meeting-less" office. But, there are a few types of meetings that I'm okay with, with one caveat: you should strive to have days with no meetings at all, and as many of them in a row as possible. In addition, if you can schedule meetings to overlap with other times that people are taking breaks (lunch, for example) this means you're not interrupting actual work flow. This gives people lots of time to get into the groove not only on a single day, but multiple consecutive days.

The type of meetings I'm generally okay with:

  • Review Meetings – We have to review our work. Artists need art review, coders need code review, designers need design review and the whole game needs to be reviewed as a whole. It's important, and frequently it's important to do this with groups rather than one on one (depending on the type of review). If you can get these to be outside of meetings with tools (like Review Board) that's great.
  • Creative Meetings – Large group creative meetings can be great, but they have their own place and time, and their own rules. This is the subject of another post.
  • Planning Meetings – Generally I'm okay with planning meetings, provided they're shorter. This is for sure a good candidate for a lunch meeting.

Any other types of meetings I'm missing? Do any of these meetings work better in an open office? Am I right about most of these meetings being avoidable?

On Air Hangout with Mike Acton

In case you haven't heard, this coming Monday, September 10th, I'm doing an On Air Hangout with Mike Acton, talking to him about his thoughts on leadership. If you can't tell from my recent blog posts, leadership, and how to be a good leader, are new interests of mine. So, I'm super excited to talk to Mike about his role not only as a lead at Insomniac, but also about his role as an industry leader, and get his thoughts on how to create better leaders in the game industry.

On Air Hangouts are cool because they are recorded and posted to You Tube immediately after they're done, and as soon as that happens, I'll post the link to the recorded hangout here.

Update: If you missed it, check out the results of the hangout on You Tube, and let me know what you think!

Thoughts on Open Offices

There's been a lot of talk on twitter lately (some of it pushed by me) about open offices, interruptions at work, and generally how to avoid being multitasked to the point of lost productivity (frequently the cause of being interrupted and asked to fix too many things at once).

From an individual standpoint, there are things you can do to make sure you stay on task, but that's the subject of another post. For now, I want to focus on the external factors of interruption, and the negative impacts there. This is probably the first of several posts on the factors that lead to interruptions at the office.

First, let me talk about open offices. Many of us, especially at game companies, work in open offices. No one really knows why, except that it is less expensive to build cubicles and set up tables than it is to build actual offices. The given reason for using open offices is that they foster team collaboration, information sharing, and that they work as a way to bring the team together. By having an open office, people can (essentially) eavesdrop on each other's conversations, and offer their input to creative or technical decisions, should they want to. But the downside of an open office is that everyone can hear your conversations, whether they want to or not.

"Open offices aren't a problem" you say. "If you don't want to be disturbed, just put on your headphones. Have a standing rule that you can't be disturbed if you have headphones on, and your music will drown out the office noise." But what if you're like me and don't like the feel of headphones (they push my glasses into the side of my head). In addition, I can't think clearly on hard problems with music playing. I can only listen to music when I have a clear direction, or when I'm doing a less thought intensive task (I'm sure many people are like me in that respect). If you have the rule of "you can't be disturbed" and you're actively encouraging people to escape from office chatter, how are you say that the open office actually encourages creativity and collaboration? Instead it forces interruption unless people explicitly block it out.

Interestingly, I've not been able to find any studies on open offices fostering collaboration or productivity, and neither could the authors of Peopleware, though they could find numerous studies showing how interruptions and open offices hurt individual productivity. Though not backed by science, listen to Jason Fried's TED talk about open offices, and why "Work doesn't happen at work." Anecdotally, I'm sure you've experienced exactly what he's talking about. Fog Creek takes this to the extreme. Everyone has an office and can't be interrupted when the door is closed. It also has a no meeting culture, which I may also write a blog post on. People communicate through private chat. Bugs and support requests must go through their bug tracker.

The problem is, I think an open floor plan does encourage communication in some ways. Not through eavesdropping, but by removing psychological the barriers between you and other people. I think people are more likely to come talk to you if you're sitting at a desk on an open floor than if you're sitting in an office. Additionally, being able to just poke your head up and ask a question feels less intrusive than having to walk into someone's office. That said, this is kind of the point. If you do a Google search on the cost of even minor interruptions, you'll find that they can be extremely damaging, to productivity, to stress levels, and to quality of work.

For me, 90% of these "micro meetings," questions, etc, are better handled somewhere that would keep a record, a place that questions asked could be asked as easily, and more efficiently, and be easily ignored if someone is "in the zone" or doesn't want to be disturbed. Fog Creek recommends HipChat (which is what Fire Hose uses), but 37 Signals own Campfire also gets good reviews. These both have the added benefit of, if you have remote workers, it Is less likely that they will be excluded from the decision making process if your team is good about using chat for minor / micro discussions over open office eavesdropping.

What do other people think? Am I missing a benefit of open office plans (other than cost)? Do people feel that the interruptions of an open office aren't as bad as I make them out to be?

Resources from the Professional Programmer’s Panel

I got an email recently asking about the resources we went over in our GDC 2012 panel this year. I figured it would be useful to have these in one place, so here we go!

Game development sites mentioned

Blogs:

Books:

  • Code by Charles Petzold

Mike also recommended (several times) that you get on Twitter (http://www.twitter.com), which is a piece of advice I whole heartedly agree with. Then you can follow all of the panelists.

When we were talking about game jams, we mentioned some longer game jams, including the Experimental Gameplay Project, Ludem Dare, and the competitions held on TIGSource.

If you have other resources for beginning game programmers, let me know and I'll add them to the list.

Post GDC 2012 Post

I'm back from GDC 2012, which is my 11th GDC straight, and I'm almost fully recovered. This year was certainly better than the last two for sure, but it doesn't take much to top getting minor food poisoning and getting (almost) deathly ill (I still can't top Darius who, three years ago, entirely lost his voice). I still have yet to find that balance of parties and not-parties, and when to just go hang out at the various hotel bars. I think I did better this year, but I still don't have it quite down.

This year, the high points were definitely the two events I ran. The first was the awesome Pre-GDC board game bash, which hosted probably about 130 people this year. This is always a lot of fun, and way more low-key than most other GDC parties which is why I like it. We're growing again next year, probably to about 150+ people, but I'm also looking for a bigger room with more tables (table space was certainly a problem this year).

In addition to that awesome event, this year I organized a private scotch tasting. This was really really awesome. So awesome, I don't have pictures of it. It was another great, low key, and educational event. Everyone there was really awesome, and I hope everyone had a great time. We'll see if that will happen next year, and if it will grow or not.

So what's up for next year? First, the board game night will certainly be running again. I've already started putting out requests for space the Sunday before GDC (and already been turned down once o_O!). Other events? Maybe the scotch tasting, and potentially a Black Tie Only reception. These last two require a good amount of planning and funding, so they'll probably be maybes until closer to GDC.

What else? I'll be posting more! Fire Hose announced that its next game (and the game I'm working on) Go Home Dinosaurs, will be shipping on Chrome Web Store using Native Client. I haven't been able to talk about this too much until now, but now that I can I'll be posting a little bit more on my experiences with Native Client and with Mono (which is what we're using for scripting). So keep an eye out for that!

The Up and Coming

Update: Better late than never, my talk is now on my site.

Happy New Year!

For those that don't know, in May (or so) I moved from Boston to Charlottesville, VA. Thankfully, the awesome people at Fire Hose have allowed me to stay with them and work remotely, so I haven't moved companies. I have, however, moved communities.

Charlottesville isn't a huge center for game development, but I think if could be a great place for game companies in the future. There's a lot of talent to be had from the neighboring universities (UVA, JMU, GMU, Virginia Tech, and William and Mary are all fairly close) and it's just a great place to live. It's not a big city, but that's actually what I like about it.

To try to help this along, I've created the Charlottesville Game Developers meet-up group. We've had a few small meetings so far, with mostly me talking, but coming up over the next few months, we're going to have some great talks about starting companies, working with the city of Charlottesville, and maybe more! (By the way, if you'd like to come visit Charlottesville and give a talk, let me know and we'll work something out).

Tonight, I'm giving a talk on tips for game jams. Since UVA has been nice enough (at my urging) to host a Global Game Jam site this year, I'm making sure everyone comes in prepared. Most of the tips come from my previous post mortems of game jams, but there will be some new stuff in there. I'll try to be sure to post the slides tomorrow as well, so everyone can get the benefit.

Anyway, if you're in the Charlottesville area, come out to our meetings! I'm really looking forward to seeing what the Charlottesville community can produce over the next year.

Cardboard Jam: Best Jam Ever

This weekend Boston Game Jams ran Cardboard Jam, a game jam where everyone made board or card games instead of making digital games. I have to say, I think I had way more fun at this game jam than at almost any other digital jam I've been a part of for a few reasons.

First, there's no tech choices or learning curve. At game digital game Jams, the first thing you have to do (once you have a game you want to create) is decide what technology you want to work in. This can be tough when you have multiple people who all come with different tech backgrounds and make them try to work together. Either you end up choosing teams based on tech that people know, or a few people end up working in tech they are unfamiliar with. This can make many digital game jams more about overcoming technical challenges, rather than overcoming design challenges in the game.

Second, other than the theme of the materials, there was no theme for this Jam. Though originally I thought this was a detriment, I am beginning to think that the lack of theme contributed to making this Jam awesome. In every game jam I've participated in, the themes have been aesthetic. They're themes like "immigration," "extinction," or "deception," and although they offer a good constraint on the Jam (and place everyone on equal footing for implementing an idea), they force most Jammers to think in terms of aesthetic first, mechanic last. This is why most Jammers can't "finish," because they're actually pushing for an aesthetic, rather than mechanical goal.

Last, jamming in board games meant that iteration cycles were really, really fast, which meant that you could focus on and tune the game and the mechanics quickly, which resulted in better games across the board. The game I worked on took about 10 minutes to play, and after initial discussion, we did nothing but play it, with short discussions in between. We probably play tested the game 50 times, each time with slightly tweaked rules to attempt to address problems we were seeing in the previous play through. Iteration times like this not only let you learn more about the game you're creating, but more about game design in general, since you see the results of you actions quickly. This speed of iteration and learning would have been impossible in a digital game jam, since implementing rule changes requires too many cycles. In digital game jams, if you get two to three full playtests in before time is up you're lucky, and that's including for teams that use prebuilt engines like Unity.

So in closing, if you get a chance to participate in a board game jam, you absolutely should. There's less stress, more learning, and way more collaboration. That, and you end up with an actually complete board game at the end, which is super awesome.