At most tech events, the audience and the producers expect you to have some slides to show alongside your presentation. I recently gave a talk without any slides at all and I think I made the audience uncomfortable.

Creating great slides for a presentation is a subject that others have covered in great detail elsewhere. It’s the subject of entire blogs and books. Presentation Zen is probably the best known of these.

I’m not going to try and provide you an exhaustive list of what to do and not to do with your slides. Instead, I’m going to give a few tips that help me, and call out some of the most obvious common errors I see tech presenters repeating.

See if you can find out what aspect ratio the projector or screen you’ll be using is in. If you create 16:9 wide format slides but end up projecting on an ancient 600x800 projector, most of your content will be squished, off the screen, or otherwise unusable. If you can’t find out the format, use a standard 4:3 aspect ratio. It’s easier to display a 4:3 image on a 16:9 screen than vice versa.

Find out how big the room will be and what sort of lighting is in there, if possible. A brightly lit room that’s super deep requires a much higher contrast color scheme to be visible in the back of the room than a dark, small room. If in doubt, go high contrast: white on black or black on white.

Avoid words on your slides. Your slides are not content. They’re supporting your content. They don’t need to stand alone. No one needs to read them without you around. By putting lots of words on the screen, you’re losing your audience. They start reading the text, and since they can read faster than you can talk, they reach the end of the slide before you do. Then they go off and read their email, or daydream, or start their expense report. You’ve lost them and good luck getting them back.

If you have 10 words on your slide, you probably have too many. Regardless of how many words you have on a slide, don’t read them verbatim to your audience. We can read, thank you. We don’t need you to do it for us. And we can read faster than your verbalizing. One way to make this easier is to just not put text on your slides at all.

If you’re in a situation where someone really does need to read your slides without you around, consider creating two versions of the slides. One that you present, and one that you leave behind. When I advise startups on pitching for investment, I recommend this approach. Have the “pitch deck” that investors expect full of details, but present from a “presentation deck” that just has supporting information like charts and diagrams.

Your slides should illustrate your point. They’re a visual to anchor the audience’s eyes and keep them from wandering to something else, like their email. Think about when you watch TV news. The anchorwoman is talking to you. Behind her is a graphic that explains what you’re hearing about. The graphic doesn’t try and convey all the information the anchorwoman is giving you, it’s just there to tell you what she’s talking about. When it changes, you know she’s moving to a different topic.

Don’t put animations in your slides. “Transitions” or “animations” are one of the worst things that PowerPoint and other presentation software ever gave us. Flying, fading, spinning, zooming objects all over the place distract the audience. They have no substance.

A more practical reason to avoid animation is that it often breaks when moving from one environment to another. You’re expecting your content to come sliding in, but when it’s viewed on the laptop the conference is showing all presentations from, it doesn’t show up.

Unless you’re a designer or you have a designer helping with your presentation, use a pre-existing template for your slides. Both PowerPoint and Keynote come with a bunch of them. You can also buy templates from a variety of sources for reasonable rates. The simpler the better, at least until you have some experience under your belt.

Presenters that try and design their own templates often end up with things that are unreadable when shown on a big screen in a large room.

Don’t put things on your slides that don’t need to be there. The page number on every screen isn’t needed. No one’s going to later ask you to pull up page 6 of your talk. Assuming you’re presenting to a public audience, leave off the ubiquitous “proprietary and confidential” footer. If it were confidential, you wouldn’t be showing to a room full of people.

Conversely, I DO like to put a logo and my contact info—either email or Twitter — on every slide. This makes sure that if someone takes a picture of your side and posts it somewhere, people can tell where it came from.

Don’t try and copy someone else’s style. When Lawrence Lessig’s culture remix and Dick Hardt’s Identity talk came out, I spent years sitting through bad clones of the rapid fire style of those talks. 300 slides in 30 minutes is hard to do well, and no one did it well.

Have your contact information on a slide early in the talk. Repeat that slide at the end of your deck. I leave that up while I answer questions and wrap up.

In most presentation software, when you’re in presentation mode and you advance past the last slide, the software exits presentation mode. To keep from accidentally doing this, I put a single blank black slide as my last slide. Then if I accidentally go past my contact slide, I can go back one.

I often give a talk on the subject of Public Speaking for Geeks. Here’s the slides from that talk, so you can see some of the principles here in action.

Once you’ve settled on what you’re going to speak about and have had your talk accepted by an event, it’s time to write your talk.

Step one: don’t wait until the night before the talk to write it. Crazy, I know, but it doesn’t yield great results. You’d be surprised how often at conferences I hear “Can’t go out tonight, I have to write my talk for tomorrow.” Your audience has taken time out of their lives to be here. They’re giving you their time. Perhaps they’ve even spent a lot of money to come. You owe them the courtesy of being prepared.

You should start preparing at least a month before your talk. Even longer is better. I find that additional ideas and thoughts percolate after I’ve written the initial draft. You’ll also want time to rehearse your presentation at least 10 times (more on that later).

Writing your talk does not mean you open up PowerPoint or Keynote. While you might create slides to use during your presentation, presentation software isn’t very good for writing. When you try and write your talk in Powerpoint, you tend to focus on the style and design instead of the content.

You’ll use the story framework to guide your talk, but you don’t need to start thinking about the story yet. You just want to get all your thoughts on the subject down.

Sit down and think about what you want to say. What message you want to get across, what do you want people to know or do when you’re done. Write down all the concepts and ideas that come to you as you think about your talk. Don’t edit, try and decide if it’s good, or organize your ideas yet. This will come later. I like to use a mind-mapping tool for this. The key is to just dump all your thoughts on the page and be able to organize them later.

My initial brainstorm is always a disorganized mess. I’m just dumping thoughts out in a stream of consciousness. Once I’m done, I decide the purpose of my talk. Am I trying to teach, persuade, or inform, as I’ll need a different level of detail in the presentation for each of these. I think of central themes or topics I wish to cover. To keep your talk from being a disorganized mess, you want to have one Big Purpose and a series of themes that support the Big Purpose.

Having a single Big Purpose helps you keep your talk focused. It prevents you from wandering from subject to subject and losing your audience. Everything you say in your talk should go toward advancing the Big Purpose, and if it doesn’t cut it from the talk entirely.

For my talk on Public speaking, the Big Purpose is “Make you a better speaker” and the supporting themes match the subjects of each of these blog posts: why you should be speaking, session submission, where to speak, writing your talk, and so forth. The items from my brainstorm are then organized under each of those topics. Items that don’t fit a topic go in an “everything else” topic. Those might get refined to better fit a topic, they might become the basis for a new topic, or they might just get left out of the talk.

Now it’s time to go through all your topics and see if you find more information that you’d like to cover for that topic. You have the bones of the skeleton, start making sure they’re all fleshed out.

You’re planning on making your talk into a story, right? Now’s when you can start mapping that out. Making a storyboard or a roadmap that shows one topic leading to the next can help you visualize this and organize it better.

Once I’ve mapped out the story and decided on the beginning, middle, and end, It’s time to start writing the content. My mind-map gets converted into an outline (most mind mapping packages will do this for you) and I’ll start filling in the outline. Writing shot blocks of text - not enough to make a paragraph, but enough that if I read one of the independently a year later, I’ll know what I meant by it. I’ll usually write it just how I wrote it out here: starting, stopping, skipping around as I come up dry on one line of thought, and picking up on another.

It’s a lot like writing anything else. Create your major themes, hang supporting bits off those. If you spend too much time on one theme, either prune it back or consider if you have two themes. Incidentally, the “Tell a Story” theme was originally part of “Writing your talk” one, but it grew so large, it became it’s own.

If you want, you could start writing in PowerPoint now. Don’t worry about the design or how much you have one one slide. These slides are going to get stripped back later anyway. But by putting things in PowerPoint now, you can start seeing how your talk will break up and flow. It becomes easy to re-arrange the order of your content to find the most logical format. Basically, you’re treating PowerPoint as a big outlining package.

Now read it, critically. You are your own editor. Are you making the same point twice where doing it once would do? Do all your points tie to the central Big Purpose? Are you rambling or providing irrelevant details? Keep asking yourself, “what’s in it for me?” from the standpoint of your audience, and if you find things that don’t answer that question, change or remove them.

If you’re trying to inform, are you getting too detailed and turning it into a training class? If you’re trying to train, are you glossing over important parts? If you’re trying to persuade, do you have any arguments with weak or no supporting statements?

Once you’ve got it all down, rehearse it out loud. This isn’t your finished content, and certainly not your finished slides, but reading them out loud like you’re giving the talk will point out places where your talk doesn’t flow well. Think of each slide in terms of prerequisites: what does the audience need to know before they’ll understand this slide, and have you already given it to them?

Now you know what you’re going to say. Most tech presentations use slides as some supporting material. Next up, I’ll talk about the process of creating those.

This is part of a series on becoming a better public speaker. Read the rest of the series.

Your talk should tell a story. It’s easier for an audience to follow if the transitions flow from topic to topic in a logical manner.

A story sets up a situation, creates a conflict, then resolves that conflict. Stories have a beginning, middle, and end. Stories are easy to tell and easy to remember. A good story keeps your audience engaged, keeps them from looking at their email. Once they look at their email, you’ve lost them for good.

Stories are better than a recitation of facts and a bunch of code samples and demos throw up in random order. Stories make your audience want to hear what’s coming next. They provide structure. They draw the audience in.

Everyone knows how to tell a story. You don’t find yourself grasping for information when you’re telling a great story. The next facts come to you as you’re telling the previous ones, because the topics flow logically from one thing to the next. The sequence is clear in your head and you remember the details as you move through the sequence.

How do you start a story?

Surely you’ve had someone tell you a story where they spend so much time explaining the backstory and including unimportant details that you’re practically begging for them to get to the point? Don’t do that. Thinking of a presentation as a story will help you stay focused and get to the point quickly. Introduce the topic, the setting, and the main characters, then get on with the story.

If you’re talking about improving monitoring on your operations team by implementing Ganglia, the characters are your operations staff. The setting is your web site. Use the first words of your talk to get these out of the way as quickly as possible and to hook your audience. Opening right up with an anecdote can be a great start. I like to get the punchy opening in even before I introduce myself. You take the stage and say “At 2:31 AM on Sunday May 5th, we were hit by a DDoS attack that lasted 16 hours. Our monitoring system sent no alerts. We didn’t know it until 8am on Monday when a we opened our email and saw a flood of customer complaints.”

The audience is hooked. They want to know what happened. They want to know why you were so incompetent you didn’t know about it until Monday. They want to know how to make sure they don’t end up being right there with you. Then you introduce yourself.

Another opening gambit is to start with a statistic. “62% of web sites experience a failure without knowing exactly when it happened or what was going on when it occurred."

A classic bit of presentation advice is to start with a joke. Don’t. You’re probably not that funny. You certainly aren’t that funny when you’re nervous, talking to a room of people you don’t know, and half of them didn’t learn English as their first language. Unless you’re experienced with comedy, leave the jokes out of our presentation. I used to be a professional clown (no, seriously), and I never start a presentation with a joke. When your joke falls flat it makes you more nervous and your audience uncomfortable.

The middle part of the presentation sets up the conflict. What’s the problem that the characters are experiencing? In the Implementing Ganglia story, the conflict is the problems that your team has run into and the solutions they’ve tried to solve them. Here’s what we saw, here’s what we tried, here’s how it almost worked, but here’s the big downside to that. Now here’s another thing.

The end is the climax of the story, followed by detail supporting that climax, followed by a call to action. We implemented Ganglia. It solved problem A like so, and problem B like so. Here’s the specific steps we took to solve this one hairy issue, and here’s the things we still need to learn more about. You can read about Ganglia at these fine URLs.

A great way to see lots of other speakers weave storytelling into their talks is to watch TED talks online. The TED format is almost all about a story. Joshua Foer’s Feats of memory anyone can do is a great example. Throughout the talk, he interweaves elements of storytelling and facts. There’s stories within stories, stories about different memory techniques embedded in his larger story about improving his own memory.

Telling a story keeps your presentation focused, keeps your audience interested, and makes it easier for you to remember your talk.

This is part of a series on becoming a better public speaker. Read the rest of the series.

You want to speak at a conference. You’ve figured out what to talk about. You have a session abstract written up. Where do you submit it?

First, figure out if you’re able to travel to a conference. This costs money, but there’s some ways you can get that covered.

Some events pay for speaker travel. The conference would be nothing without the speakers, and they make all this sponsorship and ticket money because of the speakers, so it’s great when they do this. It’s pretty rare in the tech conference world for non-keynote speakers to have their travel covered, however. If the conference doesn’t pay for speaker travel, ask them if they will, or if they can provide a travel stipend. Sometimes they say yes.

If you’re an independent developer or consultant, you can probably claim travel costs to speak at a conference as a business expense. Talk to your tax advisor about this.

If you work for a company, talk to your boss to see if they’ll pay your travel. Some companies have a policy that you can attend any conference you earn a speaking slot at. Always wanted to go to OSCON? Get a speaking slot, and you’re in.

Having you speak at a conference is great marketing for your company. If potential customers are there, they’ll see you, they’ll see the name of your company, they’ll hear what you have to say. It’s almost like sponsoring the event, but cheaper. Even if your prospective customers aren’t at the event, your company can start saying that their developers are leaders because they speak at events.

You’ll also meet people at the event, which can be good for recruiting, finding new vendors, finding new partners, and finding new ways of doing things. It’s easier to meet people at a conference if you’ve spoken there because people will want to come talk to you. Finally, having you speak at a conference is great training for you, making you a better employee.

These are all reasons your company should want to pay for you to speak at a conference.

Local events like meetup groups, users groups, and unconferences are a great avenue for speaking. They’re smaller groups, so less intimidating. It’s an informal setting so talks tend to be more interactive. The attendees are friendlier and more forgiving of mistakes, because they don’t feel like they’ve paid to see you. And your hometown groups don’t require you to travel.

Local events are often more desperate for content, since they have a smaller pool of speakers to draw from. It’s easier to get a talk accepted at a smaller, local event than a large, national one.

When trying out a big talk that I plan to give for a while at lots of events around the world, I like to test it out at a local meetup first. Sort of like a comedian touring some small local comedy clubs to try some new material before they take the show on the road.

Once you’ve decided if you’re staying at home or taking your show on the road, there are some tools that can help you find an event to submit your talk to.

For local meetings, Meetup.com is a great place to start. Lots of groups use this site to organize, and you can filter be location and keyword. Search for programming languages like PHP, Ruby, or Java, or search for broader terms like startup, internet, and programming. You’ll probably find some groups in your town you didn’t know about. They usually have their event calendar on the site, so you can see when they have an opening coming up and what their past talks have been about.

Check with your local co-working facilities and maker spaces. They tend to host a lot of user groups and other tech talks, so they can put you in touch with the organizers of local events. You might be able to get on an email list of social media page to keep updated on what events they’re hosting in the future.

If there’s a Startup Digest or similar email newsletter in your city, subscribe to it. They list tons of events. By the time they list it, it’s too late to submit a talk to it, but you can use this to learn about recurring events that you didn’t know about.

Talk to your co-workers and people at other local groups you attend. Chances are they attend or at least know about some groups you don’t.

If you’re looking at events you will travel to, the “talk to people you know” approach works as well.

Lanyrd is a site that lists conferences all over the world. They’re focused more on conference attendees than speakers, so sometimes get the event listed too late to participate in. But by looking at what events have happened in the past, you can start to build a list of what events you’d like to speak at in the future. Lynyrd will give you the event details so you can track future ones on your own.

The CFP Report is an email subscription service that sends you notices when conferences open up their session submissions. It has a smaller list of events than Lanyrd does, but they’re more focused on developer events.

Now go find some events!

This is part of a series on becoming a better public speaker. Read the rest of the series.

Proposing a session to a conference can be daunting, and many people who try come away frustrated. They’ll propose dozens of talks and get none of them accepted. They’ll decide that they don’t have the name recognition to be accepted. After all, it’s the same group of people who are always speaking, so you must be part of the group to get accepted, right?

The truth is, your sessions don’t get accepted because your proposals are bad. Sure, the organizers of a conference want a few “names” that can draw attendees, but they’re more interested in great content. Larry Garfield looked at data from PHP conferences and found that half of the speakers had never spoken at a PHP conference before. Not exactly a clique of speakers.

When I say your proposals are bad, I don’t mean there was anything wrong with the subject. It might be bad because it was pitched to the wrong conference. A beginner JavaScript session at an event aimed at experts probably won’t be accepted. A more subtle example is a talk about how to manage APIs at an API industry conference — if most of the attendees are consuming APIs instead of creating them, your talk wouldn’t add anything to their lives.

The first thing to do is to make sure the content of your proposal is appropriate to the audience. Take a look at the past year’s sessions and see what talks were given there. Try and videos or slides of those talks online to see what they said. See who is sponsoring the conference. You can learn a lot about the audience and their expectations by looking at previously delivered content, or at the list of companies who are trying to reach that audience. Your proposal is to your audience, not to the conference organizers.

Most conferences ask for a proposal in the form of a title and an abstract. Many speakers try and describe the exact contents of their talk in these, but what you really should be doing is advertising your talk. The abstracts often are what goes on the conference’s web site and in the program guide. These are what the conference is using to sell their tickets. Give them an ad that sells their tickets, they’ll give you a speaking slot.

Your proposal is the advertisement for your talk. Make sure it sells.

A well written session abstract answers three questions for me as the attendee:

• Who is the talk for?
• Why should I come to it?
• What am I going to see?

“Who is the talk for” helps the audience self-select. It helps them know if attending this session would be a worthwhile use of their time, or if the content will be too simple or two advanced for them. If I were presenting this blog post series as a talk, my “who is this talk for” would be:

Whether you’ve presented at a conference before, or think you have no chance of ever getting a talk accepted

This “who is it for” also helps the conference organizers match your talk to their audience. It shows them that you’ve thought about who their audience is and made sure your talk will be relevant to them.

“Why should I come to it” tells the audience what’s in it for them. People are selfish. They’re not going to come to your talk to make you feel good. They’re not going to come so your company can become more well-known. They’re going to come because they’re going to get something out of it that they can use in their personal or professional lives. You’ll see this theme in future blog posts on the subject. At every stage of public speaking, you should put yourself in the audience’s place and ask “what’s in it for me?"

The “what’s in it for me” for my Public Speaking session would be:

start giving awesome technical presentations, both at conferences and to your customers and co-workers.

What you’re after here is to describe the outcome of your talk, in terms of the audience. What will they know or be able to do after leaving your session that they didn’t know before coming.

“What am I going to see” gives specific, concrete examples of what’s in the talk. This reinforces the “what’s in it for me” by showing them how you intend on making good on that promise. It also further helps clarify “who’s it for” by allowing people to think about the specific examples and see if they’d be useful to them.

The “what am I going to see” for this Public Speaking session could be:

we’ll talk about how to deliver a session that will get your point across, wow the audience, and come off flawlessly every time. Topics covered will include “The SDLC (session development life cycle)”, “Giving Good Demo (aka Watching You Use Software is Painful)”, and “How I Learned to Stop Worrying and Love the Audience."

You’ll notice two things about this part of the description. First, It’s not a dry, boring list of topics. I made the attendee feel like she’ll be a superhero after the session. I punched it up a little with some humor. If you think of your session abstract as an advertisement for your talk, you’ll want to make sure it’s a good ad that attracts people. Second, it’s not an exhaustive list of everything covered in the talk. It’s a high-level sampling of topics. Long lists are hard and boring to read. No one will bother. And if you don’t list every single subject, that leaves some mystery and gives you some flexibility in what you actually talk about. This is especially good if you’re giving the same talk at multiple conferences and intend to keep it fresh by changing the details here and there.

Now that you’ve advertised your session, it’s incredibly important to live up to that ad. We’ve all been to conference sessions where the description in the show guide didn’t match up with the content of the talk. No matter how good the actual talk was, you left feeling frustrated and confused.

In a multi-track conference, this is an even greater sin, as the attendees had to choose between several sessions to attend, and may have skipped another talk to see yours, only to find that you didn’t talk about what you promised.

The final session abstract for this talk is:

Whether you’ve presented at a conference before, or think you have no chance of ever getting a talk accepted, you’ll come away from this session ready and able to start giving awesome technical presentations, both at conferences and to your customers and coworkers.

We’ve all been there, in the audience struggling to follow the conference session that meanders around aimlessly. Or that spends so much time on setup, time runs out before anyone gets to the point. Or that consists of some guy reading his slides to us. You can do better, and I’ll show you how.

Starting with how to propose a conference topic in a way that will help it get accepted, we’ll talk about how to deliver a session that will get your point across, wow the audience, and come off flawlessly every time. Topics covered will include "The SDLC (session development lifecycle)", "Giving Good Demo (aka Watching You Use Software is Painful)", and "How I Learned to Stop Worrying and Love the Audience."

Once you’ve written your conference abstract, pass it around some friends for review. Good candidates for reviewing are people who attend lots of conferences, speak at lots of conferences, or have ever organized a conference. Cal Evans has a service where he reviews session submissions periodically. He’s organized numerous conferences, large and small, including Day Camp 4 Developers. Their next (virtual) camp is on Speaking for Developers, even.

This is part of a series on becoming a better public speaker. Read the rest of the series.

You’ve decided to give a talk. You’ve found an interesting place to speak, perhaps a local tech meetup group. What you need now is a topic. The call for papers closes tomorrow, and you have no idea what to speak on.

Panic.

Coming up with a talk idea can be nerve wracking. You want to propose something good, which means something creative and well thought-out, but doing that on a deadline is tough. Here’s some ideas based on what I do.

Dust off an old talk. The best talks I’ve given are ones I’ve given before. I’ve had the chance to see, in front of a real audience, what works and what doesn’t. I’ve polished my examples, I’ve found better ways of making it flow, and I’ve probably improved my slides and my talk abstract.

This only works for conferences that have a different audience than the ones you’ve give the talk to before. If you gave the talk to last year’s industry conference, you probably don’t want to give it again at this year’s. Or if you gave the talk last month at a Javascript conference in one city, this month’s web developer event might have a lot of audience overlap.

Don’t just recycle the same talk, though. It’s hard to have any energy as a speaker if you’re repeating the same thing all the time. I like to add new information, remove stale things, and generally tweak the talk each time I give it.

Maintain a list of ideas. Every time I think of something interesting, I add it to a list of ideas. I have a notebook in Evernote called Talk Ideas. The title of each note is the subject of my idea. In the body, I throw a few notes. What made me think of this idea, possible angles for the talk, the types of conferences I might want to give it at. Not all of these ideas will turn into talks. Some might become a blog post. Some might become both. Some might die when I realize my 2am insight is really half-baked.

This takes a lot of the pressure off. Now when I have a conference coming up that I want to speak at, I can look at my past talks and see if something fits. Or I can look at my talk ideas and see if there’s a great fit.

Some of the talks I have in my ideas notebook right now are:

• Everything I need to know about startups I learned from watching baseball
• What language X can teach us about better language Y development
• Big data for non-nerds
• How the early days of blogging parallel the emerging API economy

Break the mold. Don’t be afraid to give a talk that doesn’t exactly match the conference. At a tech conference, generally geeky things can be interesting, and organizers are often looking out for things that aren’t yet another survey about how to use continuous integration/test driven development/containers/whatever.

At three different barcamps, I’ve given demos on home coffee roasting. I brought in some equipment, took everyone outside, and cooked some beans. Talked through the process along the way, explained how to get started yourself, and ended with a coffee cupping. One of those was 9 years ago, and Cal Evans still brings it up from time to time (photo here by Cal).

I once gave a talk at a Ruby conference about how to avoid lock-in when using cloud services. Although I didn’t mention Ruby once, the talk went over well because the Ruby community tends to use a lot of cloud services and APIs.

I spoke at OSCON a few years ago about how to make sure the user interface of your application is ready for IPv6. This wasn’t specific to open source, but was useful to the audience because they are creating interfaces.

The key is to make sure your talk fits the audience. Put yourself in their shoes and ask if you would find the subject interesting.

Don’t wait for that conference to come calling before you start planning for it.

This is part of a series on becoming a better public speaker. Read the rest of the series.

This can’t be good: http://t.co/vJCJ3D2g Jun 21, 2012 10 :07 via Twitter

Am I the only one wondering what would happen if I unplugged that Ethernet cable? Jun 19, 2012 11 :03 via Twitter

Now I know why my hotel wifi signal is so good: http://t.co/ADAKVtPK Jun 19, 2012 11 :01 via Twitter

The Oakland A’s are selling root beer floats to raise money to fight diabetes. Next month, how about beer proceeds donated to AA? Jun 18, 2012 12 :17 via Twitter

Dear gmail, please sort autocomplete contacts by frequency of use. I email my wife Christina way more than I do @ChrisPirillo. Put her 1st. Jun 17, 2012 7 :42 via Twitter

My son’s school is selling or giving my contact info to local businesses. Lovely. Jun 16, 2012 9 :25 via Twitter

Two iPhones in the house took a swim this week. Opened them up, cleaned them out, they’re both working again. Jun 15, 2012 7 :38 via Twitter

If your pitch deck is more about the animations than the company, you’ve already lost. Jun 15, 2012 3 :36 via Twitter

The ER is always filled with interesting people. Jun 14, 2012 10 :04 via Twitter

Proof reading is gud. Jun 14, 2012 6 :31 via Twitter