1. Skip the call for proposals entirely.
2. Advise those interested in speaking to prepare a video of the first three minutes of their talk.
3. Conference organizers do a first pass on the videos to weed out the weakest submissions.
4. All registered attendees are asked to vote on the remaining videos.
5. After votes are tabulated, the top N speakers are offered the chance to present their full talk at the conference.
6. Speakers that didn’t make the cut can choose to run small breakout groups after the main event.

I think this approach is superior to the standard CFP process for the following reasons:

1. It allows for the evaluation of speakers on their speaking, rather than their ability to write a proposal. Imagine your results if you hired someone based solely on the writing quality of their cover letter. You’d end up with a strong writer, but would likely discover that writing skills and day-to-day job performance are only somewhat correlated. So it goes with talk proposals. Conference organizers sometimes accept intriguing proposals only to discover that the speaker does not have the ability to present a compelling talk on that topic.
2. It lets the audience choose the topics that will be covered at the conference. Each year, conference organizers must guess which subjects will be most useful to their attendees. Why guess when you can collect just-in-time data?
3. It is relatively unbiased against new speakers. In the normal CFP process, inexperienced presenters are often edged out by their better-known peers (particularly if they are friends of the organizers). It requires a leap of faith to accept a rookie’s talk without any proof that they’ll do it justice. Under my system, new and experienced speakers alike must both prove they’re prepared to do a great job.
4. It leverages the wisdom of the crowd. It seems likely that 300 attendees in aggregate will make more informed decisions than a small handful of already overworked organizers.
5. It’s easier on those running the conference. Organizationally, certainly; but also socially. If the talks at a conference are of poor quality, it’s natural to blame the organizers. But if the attendees as a group selected the speakers, they are more likely to empathize with the difficulty of predicting speaking success. Moreover, the attendees would likely be biased to consider the speakers to be better quality than they were, rather than face the cognitive dissonance of having chosen bad speakers.

Possible drawbacks of this approach include the following:

1. It may be harder to market a conference with no pre-announced speakers. LessConf can sell out without telling anyone who will speak, but this seems to be an exception. Perhaps my approach would pair well with choosing a few anchor speakers who are guaranteed slots. This retains most of the advantages above while ensuring that organizers have some big names to announce.
2. It’s unlikely to address a lack of diversity amongst speakers. Organizers must often work to ensure that minority groups are sufficiently represented in the final list of selected speakers. Like the first issue, this could be addressed by having a small group of (diverse) pre-selected speakers.

What say you, conference organizers? Any interest in giving this a shot? Have I missed any potential drawbacks?

Note: I made some significant changes to my proposed process based on feedback from the commenters below. Thanks to all of you for the ideas!

Through much trial and error, I’ve learned that every programming concept has advantages and disadvantages; nothing is purely good or bad. Global data can be good. Reducing duplication can add the cost indirection. To present anything as purely one or the other tends to be the realm of novices who haven’t yet grasped the subtleties involved. Worthwhile discussion of programming ideas takes a fairly neutral view, and focuses on tradeoffs.

The problem with David’s post is that it does the opposite. Here’s his coverage of the benefits of dependency injection:

“As has unfortunately happened with a variety of patterns that originate from rigid languages like Java, Dependency Injection has spread and been advocated as a cross-language best practice on trumped up benefits of flexibility and malleability. If your code never knows exactly who it’s talking to, it can talk to anyone! Testing stubs, mocks, and future collaborators. Hogwash.”

This is not analysis, it’s wholesale dismissal of the points that don’t match his opinion. This would get you a D in a freshman analytical writing class.

Later:

“Of course, this runs counter to another Java-derived principle to only mock types you own. Combine that with an affinity of dependency injection and the simplest thing that could possibly work is no longer not just good enough, it’s disgusting. It violates the doctrine that has been so carefully assembled.”

Ah, the ol’ switcheroo. The OTHER side has been indoctrinated and refuses to examine the tradeoffs it’s making. Unlike us, the enlightened, who know that the other guys are wrong, and need not discuss their arguments.

There’s plenty of bad writing on the internet, and I don’t usually consider it worth the time to call it out. But David is a tremendously influential character in the Ruby world, and I’m concerned that this dysfunctional approach to discussion will prove contagious. It’s particularly dangerous for newcomers, for whom a rule they can always follow seems like a life raft in a sea of uncertainty. Sadly, it will do them more harm than good.

I hope David continues to share his thoughts about Ruby. When an experienced and successful programmer speaks, I’ll always listen. But I’d love to see this faulty means of discussion deprecated, extracted to a gem, and then removed entirely.

This is the idea behind the extract class refactoring. You package up some set of data and functionality, and only allow clients to interact with it through a public API. The class’s internal workings are intentionally hidden.

This tends to lead to flexible designs because implementation details can be changed without affecting any of the calling code. Changes are kept to just one file, which makes them easier, and ease of change is the best test for good design.

Most programmers are at least somewhat familiar with this idea. However, it’s easy to forget it when you start working with outside libraries or services.

Here’s a paraphrased example from a Rails app I reviewed recently. This app uses the braintree gem to charge users, create subscriptions, and refund money.

Just because we’re calling methods in another class does not mean we’re programming against an abstraction. It’s certainly better than making raw HTTP calls to Braintree, but our choice of vendor and gem used are implementation details that have leaked into our business logic.

With calls to Braintree littered throughout, switching to another vendor will require the editing and re-testing of many files. We’ve fallen short of the ideal we described above, where one change requires edits only in one place.

Fortunately, the fix is quite easy: a simple wrapper.

Another good name for the new class would be PaymentGatewayAdapter, as it’s an example of the adapter pattern.

This code is only subtley different, but yields significant benefits:

1. Switching from Braintree to another vendor now requires edits to only one file. If this change is somewhat likely, this benefit alone probably justifies the refactoring.
2. If Braintree changes its public API, we again have only one class to edit.
3. Testing has become easier. PaymentGateway gives us what some people call ‘seams’: a place where components join together where we can easily stub behavior. Before, unit tests required stubbing Braintree’s code. Upgrading the gem could potentially break many tests. Now, we can stub our own methods, which is safer.
4. We can use method names that better match our problem domain. A small win, but a pleasant one.
5. We can change the parameters that PaymentGateway’s methods expect, such as we did in PaymentGateway#refund.
6. We have a better home for constants like SUBSCRIPTION_AMOUNT and similar data.

The only downside I can think of for this code is that it adds a bit of indirection. You’ll have to jump through one additional file to found out how customer charging is implemented. However, the wrapper is very thin, so I don’t think this cost is large.

It’s easy to accidentally find yourself depending on implementation details. External libraries and services are frequently sources of this, and warrant extra suspicion. Implementations that have a decent likelikhood of change should always be wrapped in sanitary fashion.

If you’ve decided to attend a conference talk, here’s a piece of etiquette that seems to have been left out of programmer finishing school: when the speaker approaches the podium, you have an important job: close your fucking laptop and listen.

I can’t count the number of times I’ve seen people writing code during a talk. Writing code! You are not a badass multi-tasking motherfucker. You are a rude, not-paying-attention, asshole. You are disrespecting the speaker’s effort and distracting those around you. If you’re just looking for a place to get work done, go sit outside, or even in your hotel room.

The exception to this rule is when you find yourself stuck in terrible talks. I always, always close my laptop when a speaker begins. I give them my full attention and hope to be entertained and informed. Unfortunately, most speakers quickly reveal that they are not prepared to do either. Their talk is obviously underprepared or presented without energy and passion.

In these cases, I unabashedly open my laptop and turn my attention to something more useful. An underprepared speaker disrespects his audience, and looking out on a sea of glowing white apples is his just reward.

UPDATE: The wiser voices of commenters below have swayed me. Being rude in response to rudeness is still wrong. In the future, I’ll vote with my feet and simply leave bad talks.

The company hasn’t figured out how to pay its bills

At the end of the day, a company exists to make money. Every round of funding (past, maybe, a seed round) is an admission that you still haven’t figured out a business model that will keep the damn lights on. Every startup should want each round of funding to be its last.

The founders have ceded control

Companies in very strong positions are sometimes able to take funding without losing much control of the company, but this is rare. In general, founders are turning over substantial control to professional gamblers with horrible succes rates. A VC will never love your company like you do; he’s there only to get paid. This will forever taint your relationship.

Part of the company was sold prematurely

People seem to forget that “getting funded” really means “selling part of the store”. If you think your company is going to be worth more in the future, why are you selling part of it now?

Here’s an announcement I’d love to congratulate: “we’ve recently reached profitability and know we can keep the lights on. We think we can make even more money in the future, so we’re going to hang on to as much precious equity as we can. Offers for outside funding are flattering but unnecessary.”

Blocked is a crappy place to be. It means you’re trying to get something done but can’t. Current velocity: zero.

I’ve noticed something about programmers I admire: they’re extremely good at not getting blocked.

Some time ago I spent three days trying to get a feature working. I was blocked, and bad. Finally, I took a break and went to work on something else. The next day at standup, a colleague mentioned implementing that same feature, and then then going on to do two more tasks with the other half of his day. Incredulous, I asked him how he solved the problem I’d run into. He happily admitted he hadn’t. He’d run into that problem, spent a half hour on it, and then changed direction.

Me: got blocked, pounded on the barrier. Great programmer: got blocked, tried something else that worked and moved on.

Like most programmers, I have an strong desire to solve problems. Put some broken code in front of me and I’ll wrestle with it ’til it works. There’s lots to do but I’ve got to start by fixing this problem.

The best programmers I know have a different mantra: don’t get blocked. They’re focused on moving things forward, not getting bogged down making everything perfect. They’ll duck and weave, leaping over obstacles or tunneling beneath them. They like problems too, but they like something else even more: shipping.

Don’t get blocked.

The interviews themselves will make great fodder for future posts, but I realized a startling fact the other day: I never once sent anyone at thoughtbot a resume.

Moreover, I was never asked about schools, degrees, nor much about my past experience. My “resume” took the form of links to this blog, some open source contributions, and access to a couple private github repos of Rails apps I’d built.

This experience confirms an idea that I’m glad to see gaining ground lately: resumes are deprecated. Code is king. Oh, and connections help a lot too.

A year ago I wrote that it was possible to land a Rails job with no experience, provided you had a portfolio application, some code on Github, and attended Ruby meetups to network. Some people were skeptical, but it was exactly those things that got me my first Rails job. Now, years later, the same set of things got me in the door at thoughtbot: code, more code, and the recommendation of thoughtbotter Dan Croak, who I got to know during the ’09 Rails Rumble (yet more coding!)

I’m starting to think this really is the secret sauce for professional programming success, regardless of experience level. Get some code out there for people to see, and get yourself out there to meet awesome programmers you might want to work with someday. Leave the bullshitty bullet points to the MBAs.

into this?

The with_options method is a really cool chunk of code that lets you DRY up duplication that sometimes appear when passing the same options to a series of methods.

But the point of this post is how it works behind the scenes, so check out this 11-minute code walkthrough:

By the way, this is an excerpt of a longer screencast I’m working on about ActiveSupport internals. If you’d like to be notified when the full screencast is released, drop your email in this form. (One email, ever.)

You can also check out the other Rails-related screencasts I’ve already done.

I’d volunteered to give it as a test-run before delivering the same talk at RailsConf a month later.

Little did I know, someone recorded the Boston.rb talk and it recently surfaced on the presentations page.

If the title sounds interesting, go watch the talk!

By the way, this is an excerpt of a longer screencast I’m creating of guided tour through the best parts of the Rails source. If you’d like to be notified when the full screencast is released, drop your email in this form. (One email, ever.)

UPDATE: Youtube’s compression isn’t looking so hot, so if you prefer, you can download the high quality version here. (43MB)