So, You Want to Organize a Conference

I recently got an email from a friend of a friend who was thinking of organizing a conference in her area. She had never done it before, and had a lot of questions about how to go about doing something like that. She was awesome enough to send me a list of questions, to which I responded with the following novel, and then realized that I would have loved to have just had all of this in one place when I was getting started. I didn’t even know what I didn’t know yet, and getting an idea ahead of time of what it would take probably would have helped me quite a lot. So, with her permission, I am posting an only slightly edited version of our email here. I hope it’s helpful! There’s a lot of information not in this post, and I’m happy to make future posts if anyone else asks me anything that I have any kind of answer to.

So first questions is, where the heck do we start?

Do you have a particular focus for the conference? A tech stack, topic, or anything? Being able to elaborate that will go a long way to writing up your sponsor prospectus and community announcements, as well as appealing to speakers.

The first thing you will want to do is pick a venue and a date. This can be harder than you expect, since you have to take into consideration how many people you expect to show up, how many tracks you want to have, and if you want to provide things like a speaker room, handicapped access, childcare, live captioning, diversity scholarships, speaker travel stipends, speaker gifts, that sort of thing. A note: it is expensive and hard to provide all of those things. I would pick a few that are very important to you and try to add something every year.

Once you pick a venue and a date, don’t sign a contract until you have worked up a comprehensive budget. There is going to be a lot that you don’t plan for, so make sure you leave yourself some room in that budget. Figure out how much you can realistically expect yourself to fundraise from potential sponsors. Make sure you account for merchandise and banners and name tags and whatnot, as well as AV costs and food if you’re providing it (both of which are always unbelievably expensive). That will give you a good picture of what you can sell your tickets at. I usually try something like what the total cost will be (don’t forget the taxes and gratuity your venue might include), minus expected sponsorships (be conservative), and then divide that by 80% of your projected attendance to give you a reasonable ticket price. Design yourself a bare-bones budget, a middle-of-the-road budget, and an ideal budget. This will give you some flexibility when you start panicking about ticket sales or sponsorships. The other thing to take into account is that everyone will think it’s too expensive no matter what, so eventually, you’ll probably need to add enough buffer to include some amount of discount. You’ll also want to provide different tiers of pricing, since everyone waits until the last second to buy their tickets for some reason. Early bird tickets serve to help that a bit – people who know they want to attend and are excited about your conference will buy early bird tickets and get a discount, and you will get some cash flow to help you start making things happen. I usually will do a similar discount in early bird pricing as whatever I buffered for the discount codes, however I make sure early bird tickets are always the cheapest option, since they really help me out in getting things planned and paid for.

Getting started is the hardest part, honestly. And all that stuff above is really hard to get right. Most conference organizers that I have talked to say that in their first few years, they end up paying quite a bit out of pocket. Even Self.conference had this issue this year.

One other thing to note – I have recently started getting some good advice from 10 year conference organizing veterans, and they mentioned that you can ask your venue for rebates on everything from the food to the drinks if you have an after party, to the hotel room block if your venue has a hotel. I have not done this yet, but I plan to for 2016.

Do we have to be non-profit to accept money from sponsors?

You do not have to be a non-profit, but in most states you need to be a licensed business. Lots of other conferences have various advice for doing this; I am not good at the business-y side of stuff, so I just have a partnership LLC in Michigan with another organizer. I know that Strangeloop is an LLC taxed as an S-corp. Codemash is a non-profit of some kind, but I can’t remember which one – I think it’s on their website somewhere. I just used LegalZoom even though it was expensive, because again, I have no idea what I’m doing there.

Eventually, you’ll also have to do your taxes, so quickbooks or freshbooks or xero or something is probably a good idea. That’s all over my head as well; I just put everything in quickbooks and filed for a tax extension until I can raise funds to see an actual CPA about it. Some sponsors will also require you to have a federal EIN that they can file with their accounting department for their taxes and whatnot.

How long does it take to organize one?

I’d give it a bare minimum of 6 months. You will stress about it either way, and there are a lot of ups and downs in organizing, but giving yourself enough time is a good idea. If you give yourself even more time than that, you have a better chance of getting on companies annual sponsorship budgets.

How many organizers are optimal?

I’d say at least 2 to get started, but honestly, the more the better up to a point. If you have a few organizers and they all have different strong points, you can split up the responsibilities which makes life much easier. Having a weekly check in so everyone is on the same page for a timeline is also a good plan. I have found that having a slack instance for self.conf was very beneficial – it was just the organizers at first, and then volunteers, and we ended up with some private groups for marketing with marketing volunteers, and speakers so they can talk to each other and us. It worked out really well.

What have you done that has been successful for you?

It was really beneficial to us to partner up with other diversity organizations to reach out for speakers and attendees. We tweeted every group across the nation that we could think of, as well as partnered with Blacks in Technology, and as a result ended up with about 50/50 male/female submissions/speakers, which was awesome. In terms of other forms of diversity, we did not do as well, but next year we’ll push even harder in finding and reaching out to even more groups.

Another thing that worked well – lots of speakers were very excited that they had their own partitioned off wifi network for their talks and resources, as well as having a speaker room for them to set up in. We also made sure we had enough macbook dongles for each room in case a speaker didn’t have one available – you will lose them accidentally, so get a couple extra.

Having a couple of invited speakers is also a good plan. Selfishly, this means I get to ask my software idols if they will come visit Detroit. Conf-benefit wise, it will make people not only want to attend, but want to apply to speak, as well as give them a picture of what your conference is about. “Oh, Brianna Wu is keynoting at Self.conference, I should apply to speak at that conference so I can go to it!”

One other thing you probably already know: make sure you have a code of conduct. has a lot of excellent resources for this. Make sure all staff and volunteers are aware of it and what to do in case something comes up.

What should I avoid doing?

I’m not sure… I guess avoid trying to be too accommodating. It’s easy to try to give everyone what they need or want, but make sure you’re paying attention to how much something will complicate your plans or budget before agreeing.

What is the best way to gain interest from sponsors/presenters/speakers/attendees?

Sponsors: We have not done a good job with this so far. One thing we’re planning for next year is to outline, from a company’s perspective (which means $$ and hiring, not just supporting the community and/or diversity) what things would really entice them to be a part of the conference. What would make it clear to them that they absolutely cannot miss the opportunity to have a booth at your conference. Then design your sponsorship levels with that in mind. Another thing people really like is the opportunity to sponsor a specific thing. Be it coffee, water, snacks, lanyard, diversity scholarships – whatever it is, people love being a thing sponsor.

Speakers: I already outlined some of that above, but other things that help people feel comfortable speaking is to outline your selection process, offer them free tickets to the conference (this should be obvious, but you’d be surprised), offer them a travel stipend or to cover a hotel room if they need one, and if your conference is accepting of first-time speakers, make sure they know that.


  • This is another thing I outlined above a bit, but if your conf has a specific focus, have awesome talks relevant to that focus at various experience levels.
  • An awesome venue will also help people want to attend.
  • Reach out to every user group you can think of to announce your conference.
  • Have a mailing list that you tweet about and have a sign up for right on your website.
  • Of course, discount codes will also help here.
  • Tweeting or blogging about milestones as they come up are also good – even silly stuff like “look at these prizes we are giving away” or “look at this food we’re going to serve you” or whatever it it. If you sell 100 tickets, tweet how awesome it is that you sold your 100th ticket.
  • Have your speakers and sponsors tweet about their involvement with the conference.
  • Another thing I’ve seen work in the past is to occasionally have contests to give away free tickets, because the winners will want their friends to go with them.

Learn a Language and EAT!

Here at Detroit Labs, we get together for an hour and a half weekly to play with a language that is new to all of us (except Nathan Dotz who has toyed with all programming languages ever). We pick a chef for the week, that person brings us in a crock pot of deliciousities, and we all gather round for the first half an hour and go through environment setup together. We try to look at the basic structure of one unit test and maybe how to make a function in said language, and when the clock hits twelve, we are done no matter how far we got. Then we go over the very quick rules and exercise. Our rules:

  1. TDD
    • Write the simplest test you can to make progress
    • Write only enough code to make your test pass
    • Only refactor on green!
  2. Pair!!! Ping Pong Style.
    • You write a very simple failing test (non-compiling counts as failing)
    • You pass the keyboard to your pair to make it pass writing only enough code as is necessary
    • Your pair writes another simple failing test and passes the keyboard back
  3. You’re not supposed to finish the exercise.
  4. Don’t be a wang.

That last one is in there just to have the team and individuals hold themselves accountable for not being negative. This is a safe, supportive place where almost none of us have any idea what we’re doing and are there to stumble through the often uncomfortable steps of learning as a team. As for the exercise, we always do the Prime Factors kata. That seems like it might get boring, but think of it like this: you use different katas in your everyday programming language to help you get better at that language. What you know is the language, what you don’t know is the new kata. In our case, we know the kata very well (we spent the first two weeks doing it in two languages we’re familiar with, just to make sure), but it’s the language we don’t know. We have the same balance (using something we know to learn something we don’t), we just flipped the script on what goes where in that equation. For those unfamiliar, the prime factors kata is:

Given an integer, return a list of factors for that integer that are prime numbers. For example:

Given Result
2 [2]
3 [3]
4 [2,2]

and so on.

So far, we’ve done java and objective-c (our first two), rust, elm, and go. Oh, in case I didn’t mention, we don’t pick the language ahead of time, we just choose from the pool of languages that we have put on a big list to try out. Soon, we’ll have a big wheel to spin and everything, but for now, we just choose at random. Guests are welcome to join, so long as they follow the above rules and RSVP in enough time to warn the week’s chef, so feel free to twitter at us at @DetroitLabs, or even just @crebma!

CodeMash 2014

I had the honor of being invited to speak at Codemash 2014, which was my very first big conference talk. Here are my slides, and here’s the link to the example codebase:


A Trick!

After spending a little while trying to figure out how to wrap tests around a bit of code that looked pretty similar to this:

Block within a block
[[NSOperationQueue mainQueue] addOperationWithBlock:^{
                [self.service getAThingWithSuccess:^() {
                  [self doOtherStuff];
              } andFailure:^{
                    [self ohNoes];

so I could get at the [self doOtherStuff] parts and test them, I found this stub:withBlock: selector in Kiwi. So, I tried the following:

Auto-execute the blocks!
[[NSOperationQueue mainQueue] stub:@selector(addOperationWithBlock:)
                       withBlock:^id(NSArray *params) {
                              void(^block)(void) = params[0];
                              return nil;

and it worked perfectly! Woot! In my particular case, I was actually using a kiwi spy to capture that success block sent to the service (though maybe I’ll use this new trick instead), so after calling block() in that stub, I was able to immediately get the argument from the spy, whereas all other attempts at trickery were giving me “argument not captured” issues.


It’s OK to Cheat Sometimes!

Lots of people have strong opinions about what you should and shouldn’t do in testing. For the most part, those rules tend to be right. But deep in the heart of a huge legacy codebase, striving for tdd perfection is often a self-defeating goal. Should you be on a path to refactor and test that codebase towards that perfect tdd goal? Of course! But when you first inherit an enormous untested codebase, or are new to tdd and want to start testing your codebase, it is perfectly ok to take some shortcuts. Here are a couple of sticking points I’ve seen people hit and then give up entirely.

DISCLAIMER: These all assume Kiwi use, because that’s all I’ve used so far. I’m sure there’s an easy translation, so long as your chosen testing framework has a robust mocking/stubbing framework in it.

“I have business logic in viewWillAppear, and it’s heavily tangled with the rest of my controller!”

Spent the last two hours trying to untangle that code so you can extract it to one or more collaborators? It’s ok. That’s a good goal that should be met, but it doesn’t make sense to string out several days and possibly create several bugs in the process of refactoring untested code. It can be worthwhile to “boy scout” that code little by little. What that means is that you leave that code a little better than you found it. Perhaps not sparkling clean, but a little better every time you touch it. A shortcut you can use to start heading in that direction is to extract everything that’s not [super viewWillAppear] into a separate method, or even just the logical block that contains the logic you are touching. In your spec, use a class extension to declare that method in a place where your specs can see them, but the rest of your production code cannot. Now you can write characterization tests around that private method that will help build a foundation for safe future refactoring.

“This controller uses ivars all over the place that I can’t modify!”

This one is not a shortcut, but it is an easy fix. Convert that ivar to a property. If it’s a private ivar, here’s where the same afore mentioned shortcut comes in: declare that property in a class extension in your specs.

“This chunk of code makes a UIAlertView but I’m not actually touching that code so I don’t want to deal with it!”

Stub the alloc/init methods. I know, it’s hard to hear. You might even be wincing right now. But seriously. Factory type methods might be better, but if you’ve already chosen a different spot in that chunk of code to boy scout, it can be helpful to stub so as not to invoke UI code.

Again, I just want to reiterate that these should be used as stop gap measures. You know you’re doing it right (and should feel AWESOME) as soon as you can remove these dirty little workarounds. But iOS code had been around long enough now that legacy codebases not only exist, but have grown into unmaintainable masses.


Code Attack!

One day, we at Craftsman Guild decided we wanted to have a mini code retreat. That is to say, we wanted to swap pairs, delete code, and learn from one another in the two hours that we have for our user group.

So, using the same basic rules as a code retreat, but with an abbreviated format, we managed to make a worthwhile learning experience in our two hours. We cut exercises down to 20 minutes each, with a maximum of 5 minutes of retrospective. At least one half of each pair has to know how to use the pair’s chosen language, as well as have the environment and testing framework already setup to save time. We also stuck with Conway’s game of life as a problem most people are familiar with and have worked through before. It actually worked out spectacularly! We have done it several times since, and every time, everyone involved learns something new and has an amazing time. We even manage to use different code retreat exercises (3-5 lines max, no ifs, no loops, etc), and have done these exercises both with and without the facilitator participating in pairs. As a note, if the group is not made up of people who have been to code retreats in the past, it usually works best to have a facilitator who is walking around and helping/guiding.

Given that a code retreat is something that conforms to a certain set of relatively strict rules and guidelines, much internet sassing back and forth occured, and Tim Wingfield came up with a brilliant idea. If it can’t be a code retreat, we should call it a code attack! So we gave these mini code retreats a better name, and they were born in May of 2011.

Is This Your First Time in Prison?

I got asked that question three to four times, and each time was a bit more perplexed. Was I expected to have been in a prison before? The last time, though, at lunch, someone followed it up with, “you seem pretty comfortable.” That alone seems like a worthwhile story, to me.

BUT WAIT! THERE’S MORE! There’s all of the context, and the actual point, and all the fun bits! Details galore!

So I work with this guy, Dan Wiebe. We both work at Pillar. Dan is an all-around, generally awesome fellow already, but additionally, he works with the LifeLine program to teach guys in prison Java. LifeLine is not just about java, it’s also about tons of other awesome programs, but one of them happens to be programming. ANYway, he has had a few code retreats in prison, and I missed them for one reason or another, but this last one, I actually got to go.

I’ll admit, I was a bit nervous immediately beforehand. I was pretty certain I would say every wrong thing that could ever be said, and offend everyone. To make things worse, Dan had been talking me up to the prisoners, so I was certain I was not going to live up to expectations. And I was wearing these TERRIBLE pants that I bought the night before at T.J. Maxx because you can’t wear denim to prison for some reason. They were man-pants, and the waist bits were just too tight, being the wrong shape and all.

So anyway, we went inside, and were escorted by correctional officers (NOT GUARDS AT ALL) to a computer lab of sorts. Many pairing (or tripling) stations were set up all over the place. We had a quick chat and then dove right in. The problem itself was tennis, a game which I have never played, and am still a little frustrated with. Love? Really? Not zero?

My first triple was with Jason and Adam, and we ping-ponged between the three of us. I got to tell them some neat shortcuts, and they called me a showoff. We had some good discussions about the steps we were taking and decisions we were making throughout. Really cool.

Then we went to lunch, which was in the lunch room (or whatever it’s called in prison) with all the prisoners, not just programming ones. Somehow, I got to the front of the lunch line, which was terrible, because I had no idea what to do. Luckily, a java guy (Lee) was right behind me, and he told me what to do, where to get silverware, and where the milk bags were. That’s right, milk bags!! Lee and I sat with Ron and another fellow whose name I sadly cannot remember, and chatted about hamcrest and guava while we ate lunch. Turns out, they had hamcrest, but were not necessarily sure how to use it just yet (not even sure if I am). Lunch was not as bad as some made it seem like it might be, but I’m not lining up to eat it at any restaurant. The guys did mention that it was probably the best meal they get, but I’m just saying. It wasn’t terrible.

After lunch, I tripled with Ron and Wes. The first thing we did, even though it may not have been necessary, was make a custom hamcrest matcher. There is nothing quite like the joy of showing another programmer how to make a custom hamcrest matcher. There is always the moment where all becomes clear, and everyone involved experiences pure joy for some small amount of milliseconds. Tears almost come out of yours eyes, but then you remember where you are. It’s wonderful. Beyond that, we had more interesting discussions about steps we were taking and decisions we were making. Until almost the end, I found it extremely interesting that we were writing the exact same codebase as we had written in the first triple. And I deleted that code in the beginning, I swear! And REALLY, I was not driving that thing! Ping pong all the way!! At the very end, Wes began working on an enum which would know that love really secretly meant zero, and all the other silliness, but time was up before he could fully relate to us his grand scheme. Sometime just before the end, Dan asked if volunteers would want to stay later if we were allowed, to which I responded, “Yeah, I’m having fun, why not? I’ll stay.” The guys I was tripling with thought that was pretty funny. “You NEVER hear that in here,” they said.

On a personal/social interaction note, I felt ridiculous just in the nick of time about any complaints I had while talking with any of the guys. At one point, one of the guys was talking about having gotten a small amount of sleep the night before. My first thought was, “Yeah, me too, that hotel bed was terrible!” Luckily I caught myself before it came out of my mouth, because that would really just be ridiculous. I instantly felt like a spoiled brat for having thought so poorly of the hotel.

At the very end, another guy, Mark, was showing us all of the animations he had made. They were AMAZING. He had made a few characters for his family and various prison events, and he had everything from short animated episodes to games. Really neat. He made an episode specifically for our code retreat, which was shown after lunch. He said he had all the computers in the lab doing a network rendering of the animation. This is a thing I didn’t even know could happen, and it sounds super-impressive. Lee also showed us some software that he was working on for the prison that looked REALLY nice. I would have liked to see more of that, but our escort arrived, and we had to leave.

After that, we reconvened at a Bob Evans nearby to talk about our day. The best conclusion I could come up with at the time was that I would gladly take any of those guys on my team. Also, it was astounding to see people actually try to discuss and understand. Even when they started to get frustrated, inevitably, without fail, it would change right into something like, “this is the area where I need the most work,” or, “alright, I want to see what you guys are talking about, let’s do that.” Really cool. On the outside, people do a lot of getting upset and acting like children. That was really refreshing/amazing to be a part of.

All in all, I would totally go back. Without question. I hope I’m available next time around, and if given the chance I will gladly teach people about guava. Because it makes java much more reasonable.