Andy McLoughlin

#awesome

This is awesome. Finally, something that means I will use my iPad every single day. Thanks @orvet for the tip.

I don't think this ad ever aired in the US (it was made several years ago by the London ad agency Fallon for the European market) but is essential viewing for anyone who has spent time in SF. Still makes me excited every time I watch it.

Groupon has filed its S-1 and hopes to raise $750M in its initial public offering. Given they’re currently losing a staggering $117M per quarter, despite revenues of $644M, they’ll be burning through that cash almost as soon as it hits their account.

At the moment, it’s costing them $1.43 to make $1, and it doesn’t look like it’s getting any cheaper. They’re already projected to make close to three billion dollars in revenues this year. If you can’t figure out how to make money on three billion in revenue, when exactly will the profit magic be found? Ten billion? Fifty billion?

With cash on fire like this, they surely need more. They recently took nearly a billion dollars from investors, but hardly any of it went into the business. Instead, the bulk was used to cash out insiders and early investors. What they’re left with is roughly $208M in cash on hand, which is less than two quarters worth of operating capital at the current burn rate.

The venture capitalists who jumped on board in January with a cool $950M in series G funding were obviously not going to repeat the deed. They’re merely in line to turn a quick buck in the forthcoming IPO pop. Imagine the dialogue: “Okay, here’s a billion dollars, but we fucking want it back this year — a couple times over!”

Since they saw the numbers on the business in January, they surely knew that Groupon was going to need a truckload more cash and soon. And since the round was already a who’s who from Sandhill Road (Greylock Partners, Kleiner Perkins, Andreessen Horowitz), the next step was naturally to dump it on the public.

Boulevard of broken deals
What’s so frustrating is that on paper, Groupon appears to be one of the best business ideas in the world. You convince small merchants to give extreme discounts to get access to more customers, and you get to keep half of the revenue yourself. No need for warehouses, distribution, or inventory. Add a recession-battered, coupon-hungry public and presto, the gold faucet is flowing!

If only. The S-1 tells us the reality is far from that ideal. Groupon had to spend $208M on marketing in the first quarter and another $178M on sales people and the rest. Surprise, surprise — it’s costly to buy enough ads to reach the volume of consumers needed to produce such staggering revenue numbers. Likewise, hiring an army of 7,000-and-counting employees to cold-call every small business owner in the world costs a pretty penny, too.

But, but, but what if they’re the next Amazon?
First, Amazon spent the billions that bled their balance sheet digging an incredible moat. They built warehouses and distribution centers, and had to keep every fucking item in the world in inventory. That turns out to be very expensive too, but repaid at scale.

Where’s Groupon’s moat? Sure, they have a list of 56,000 merchants who might do business with them again and 83 million email addresses of people who might buy another coupon. Do you really think that’s comparable to the infrastructure moat Amazon built?

And if that actually is their moat, why aren’t they bragging about how low their churn rate is? Their investment in cold-calling merchants will only pay off if most merchants stick around to do many more deals. The same goes for coupon shoppers. They need to be loyal enough to keep buying from Groupon without needing to be wooed over and over again with expensive ads.

Update: Analysis from one of Groupon’s oldest markets, Boston, show that there is no moat. Acquisition costs are skyrocketing and revenue per customer is plummeting.

Second, for every Amazon blessed with the good grace of the market to lose billions for years while proving their business model, there are ninety-nine WebVans, Pets.com, and other tombstones in the graveyard of profitless ventures. Losing billions for years is generally not a winning strategy, despite the odd exception.

The market gets what the market wants
Yet none of this is likely to matter. The market has already demonstrated its headless intent to pay silly multiples on the opening day of any new tech IPO, as the recent LinkedIn deal showed. It’s also been willing to pay unprofitable businesses like Salesforce handsomely for creative accounting schemes and blockbuster revenue numbers, profits be damned.

Morgan Stanley, Credit Suisse, and Goldman Sachs are putting their good names behind the Groupon deal and will sell into the all-but-assured bull-opening run. The people who will end up assuming all the extraordinary risk are the pension funds and regular schmucks now eyeing another chance to get in on the ground floor of another bubble.

Groupon is imitating Salesforce’s accounting magic
As if inspired by Mark Benioff’s accounting schenanigans in the latest Salesforce quarterly earnings report, Groupon’s management has come up with their own fantasy accounting metric. In a letter to prospective investors, Andrew Mason explains this wizardry as “Adjusted Consolidated Segment Operating Income” or “Adjusted CSOI.” He explains:

This metric is our consolidated segment operating income before our new subscriber acquisition costs and certain non-cash charges; we think of it as our operating profitability before marketing costs incurred for long-term growth.

I’ll let Eric Savitz from Forbes rip into this one:

The adjusted CSOI measure is the one I find a little disturbing. This measure backs out “online marketing expense, acquisition-related costs and stock-based compensation expense.” Not counting online marketing expense seems, uh, ridiculous. The company writes that “online marketing expense primarily represents the cost to acquire new subscribers and is dictated by the amount of growth we wish to pursue.”

Uh, ok, but look what happens if you don’t count it. In Q1, the company had a loss from operations of $117.15 million; that reflects $179.9 million in marketing expenses; back that out and – voila! – massively positive adjusted CSOI. Likewise, for all of 2010, a loss from operations of $420.3 million includes online marketing expenses of $241.5 million, and acquisition expenses of $203.3 million, plus stock-based compensation expenses of $36.2 million. Back all that out, and – tada! – positive adjusted CSOI.

The bottom line is that considering the profitability of Groupon without online marketing expenses is silly; Groupon without marketing expenses is not Groupon at all.

So I guess the new playbook says that whenever generally accepted accounting principles don’t produce the kind of headline numbers investors want to hear, just come up with your own numbers to fit the growth narrative. Hey, it worked for Mark when he announced Salesforce was switching to non-GAAP numbers that didn’t include stock compensation for sales people (a twist that ensured he and other execs would hit their targets and get their bonuses)…so why wouldn’t it work for Groupon?

You can fool some of the people some of the time, but you can’t fool all of the people all of the time.

Groupon has a great tagline in “the fastest growing company in history,” but don’t underestimate how incredibly risky an investment it still is. There’s a very real chance Groupon will never figure out how to tune the revenue machine enough to produce even a penny of profit. They’re asking the public to value them at an alleged $25 billion (or 1/12th of AAPL, a company that generated $6 billion in real profits last quarter) on a hope, a prayer, a song, and a dance about fantasy metrics.

Buyer beware.

Love the ultra-simple breakdown that it costs Groupon $1.43 to make $1 and this metric isn't improving. And the ensuing back and forth between @owenthomas and @jasonfried regarding Jason's Groupon shareholding is just wonderful (http://twitter.com/#!/owenthomas/statuses/76736669927227392)

Going west, one year in

Posted on 27. May, 2011 by Andy in Huddle comment, Tips

Note: This is update number three to this blog post (recycling FTW!), having originally appeared on this blog last May with an updated version posted on Telegraph.co.uk in February. I also used it as the base for my talk at FOWA London last October. I’ve amended this post with some new ideas and stuff I’ve learnt during my twelve months in San Francisco.

Whatever the reasons – US-based VCs, partners and customers, a large potential market or a desire to take on the Americans at their own game – many European start-ups have considered moving West. Back in May last year, Huddle did exactly that and I found myself in the heart of San Francisco’s SOMA district surrounded by hundreds of other tech start-ups and industry movers and shakers.

This is the place where the cash flows like wine, where you can’t travel to the office or walk into a bar without bumping into a prominent angel investor, and doing business is drop-dead simple. Right? Well, no, actually. Ah, unless of course you’re building a Valley-based location-aware photo-sharing app, in which case it’s apparently a walk in the park. A $48 million park, at that.

Yes, investors brandish larger pots of money, invest in businesses far earlier and you’re likely to live next door to the chief executive of one of their portfolio companies.  However, doing real business – actually selling software, in our case – in the US is far from easy and getting started is, without doubt, damned expensive.

Regardless of how successful you are on the European stage, don’t expect to jump off the plane at San Francisco International and be welcomed with open arms by the local press, find yourself a trendy loft apartment, hire a team and start trading in the space of a few weeks. It’s hard work, and European tech start-ups considering taking the plunge should ask themselves: “Is going to the US really necessary?” Sit down and establish whether it’s honestly worth the time, expense and distraction. I’ve seen a fair few start-ups flirt with U.S. expansion and watched some burn in flames as the founders get tied up with the romance of transatlantic travel and forget to work on their business.

If you do decide that a move across the pond is worth the effort, you need to ensure that the foundations for your US business are in place well before you open your office doors. By the time I relocated to San Francisco, I’d been visiting the West Coast five or six times a year for the previous couple of years. You need to be prepared to spend time familiarising yourself with the geography, immersing yourself in the culture and getting to know the locals.

There are plenty of great events that you can go along to, such as SF Beta, SF New Tech and Startup2startup Dinners in order to build relationships with other start-ups and meet investors. However, not satisfied with the existing rosta of meet-ups, we decided to import DrinkTank and have successfully run four US events in the last six months, with more than 300 attendees at the last one. Lesson learnt – even (specially?) Americans love a free bar.

You’ll also want to figure out location (yes, there’s an app for that) and take a look at what kind of companies are based where and the best ways to get around. Different geographies attract different organizations. For example, Mountain View and Palo Alto are the heart of Silicon Valley proper and home to companies like Oracle, Siebel, Facebook, Apple, HP and Microsoft’s valley campus. These towns remind me of Reading (coincidence that UK branches are located there?) but with bonus sunshine and palm trees. Although they lack soul and non-generic shops, they are the ideal locations to move a 1,000+ person company into.

In contrast, the SOMA and financial districts of downtown San Francisco are fly-paper for start-ups, creatives and social media companies.  As we’ve grown, we’ve moved from a tiny two-person room inside UserVoice’s offices to a suite in a SOMA Regus serviced office and now our permanent home on Bush Street, complete with enough room for plenty of new hires as well as a Champagne fridge and shuffleboard table. It’s not all work, work, work, you know.

One of the areas that you certainly shouldn’t scrimp and save on when heading to the US is lawyers – they will become your best friends as the stacks of paperwork involved in setting your company up as a US entity, obtaining visas and hiring a team will make your eyes bleed. To avoid spending your evenings wading through forms and making errors, rather than getting that all-important actual work done, just get professionals involved.  A few key tips here – firstly, the majority of US companies incorporate in Delaware, regardless of where they are actually based, because of the state’s generous tax benefits and well-defined body of case law. Secondly, working without a visa is extremely naughty and one slight mistake on the application form will completely void your application. Just use an immigration attorney. And if they seem anal, then that probably means they’ll be really good.

Add the list of other legal requirements involved when it comes to hiring a US team – US employment contracts, payroll, healthcare (including vision and dental), social security, IRS etc. – and you start to see why professional legal help is so vital. And be prepared to budget for healthcare – costs can run to USD 750+ per month per employee for good cover.

Our US sales team has been performing so well that we’ve had to grow our US-based Customer Engagement team by 300 per cent in the last month. Having Huddlers on the ground to help new US accounts with deployment and existing accounts with growth and best practise has proven to be extremely popular. So much so, that we’re now offering the Huddle Adoption Guarantee, which you can read about here.

So, clearly moving to the US involves far more than simply jumping on a plane, stocking your start-up snack room with unhealthy treats (although this is very important) and purchasing expensive Aeron chairs.  Be prepared to invest a lot of time and effort into getting it right because when it is a success, a move to the Bay Area is well worth it.

Tags: Collaboration, enterprise content management, going West, Huddle, san francisco, top tips

I blogged this week about our experiences - one year in - of opening a US subsidiary and moving to San Francisco. Actually, I blogged this about six months ago and this is just a brief re-write but, still, have a read and let me know what you think.

(h/t @keaneiscool)

Unsurprisingly, one of Mac peoples' magazines of choice is Macworld. Live the dream (and read it too, apparently).

Having raised a number of VC rounds personally and observed many more as an investor or friend, I’ve come to think there are a set of dominant best practices that entrepreneurs should follow.

1. Valuation: Come up with what minimum valuation you’d be happy with but never share that number with any investor.  If the number is too low, you’ve set a low ceiling. If your number is too high, you scare people off. Just like on eBay, you only get to your desired price by starting lower and getting a competitive process going. When people ask about price, simply tell them your last round post-money valuation and talk about the progress you’ve made since then.

2. Never tell VCs the names of other VCs that are interested.  Reasons: 1) if you are overplaying your hand that could send a negative signal.  Most VCs know each other and talk all the time. 2) it is possible they’ll get together and offer a two-handed deal in which case you have less competition.

3. I think the optimal number of VCs to talk to seriously is about 5.  That is usually enough to get a sense of market but not so much that you get overwhelmed.  You should pick these VCs carefully – this is where trusted, experienced advisors are critical.

4. If there is a VC you really like, have a “buy it now price” and if they hit that valuation (and other terms are clean) do the deal.  Otherwise, say you’d like to “run a process” and include them in it.

5. Try to set timelines that are definite enough that investors feel some pressure to move but not so definite that you look dumb if you don’t have a term sheet by then.  (Investors have an incentive to wait – “to flip another card over” as they say – whereas entrepreneurs want to get the financing over with asap). Depending on where you are in the process, say things like “we’d like to wrap this up in the next few weeks.”

6. Once you start pitching, the clock starts ticking on your deal looking “tired.”  I’d say from your first VC meeting you have about a month before this risk kicks in.  You could have a great company but if investors get a sense that other investors have passed, they assume something is wrong with your company and/or they can wait around and invest later at their leisure.

7. The earlier stage your company is the more you should weight quality of investors vs valuation.  For a Series A, you are truly partnering with the VCs.  You should consider taking a lower valuation from a top tier firm over a non top tier firm (but probably any discount over 20% is too much). If you are doing a post-profitable “momentum round” I’d just optimize for valuation and deal terms.

8. Term sheets:  talk about terms in detail over the phone.  Only accept a term sheet once you have decided that if it matches what was described you are prepared to sign it.  After sending a term sheet VCs get worried you’ll shop it and usually want it signed in 24 hours.

9. Get to know the VCs.  Talk to their other portfolio companies, read their blogs, call references, etc.  You will be in business with this person for (hopefully) a long time.

10. Timing.  While it’s ideal to raise money once you hit the milestones you set out initially, you also need to be opportunistic.  Right now, for example, seems to be a really good time to raise a VC round.  You could make a ton of progress over the next 6 months but the market could tank and end up in a worse place than you would be today.

Share:

This is gold, especially point 2 (h/t @jdh)

I fucking love infographics, flowcharts and pretty much anything represented with pictures. And it's even better when the information contained is solid gold. If only i'd had this to hand four years ago...

Useful! (via @jgport via @laughingsquid via @reddit et al)

"I like it" (h/t @spencerchen)

"And that, Jasper, is more or less the way it is in the hood." Brilliant. (h/t @markofmac)

And you thought your city was growing quickly? (via someone on Twitter)

"He was an electric Jesus..." Brilliant. Watch the whole liver-damaging series at http://www.youtube.com/user/DrunkHistory

I’m fascinated by the way Facebook operates.  It’s a very unique environment, not easily replicated (nor would their system work for all companies, even if they tried).  These are notes gathered from talking with many friends at Facebook about how the company develops and releases software.

Seems like others are also interested in Facebook…   The company’s developer-driven culture is coming under greater public scrutiny and other companies are grappling with if/how to implement developer-driven culture.   The company is pretty secretive about its internal processes, though.  Facebook’s Engineering team releases public Notes on new features and some internal systems, but these are mostly “what” kinds of articles, not “how”…  So it’s not easy for outsiders to see how Facebook is able to innovate and optimize their service so much more effectively than other companies.  In my own attempt as an outsider to understand more about how Facebook operates, I assembled these observations over a period of months.  Out of respect for the privacy of my sources, I’ve removed all names and mention of specific features/products.  And I’ve also waited for over six months to publish these notes, so they’re surely a bit out-of-date.   I hope that releasing these notes will help shed some light on how Facebook has managed to push decision-making “down” in its organization without descending into chaos…  It’s hard to argue with Facebook’s results or the coherence of Facebook’s product offerings.  I think and hope that many consumer internet companies can learn from Facebook’s example.

HUGE thanks to the many folks who helped put together this view inside of Facebook.   Thanks are also due to folks like epriest and fryfrog who have written up corrections and edits.

Notes:

• as of June 2010, the company has nearly 2000 employees, up from roughly 1100 employees 10 months ago.  Nearly doubling staff in under a year!
• the two largest teams are Engineering and Ops, with roughly 400-500 team members each.  Between the two they make up about 50% of the company.
• product manager to engineer ratio is roughly 1-to-7 or 1-to-10
• all engineers go through 4 to 6 week “Boot Camp” training where they learn the Facebook system by fixing bugs and listening to lectures given by more senior/tenured engineers.  estimate 10% of each boot camp’s trainee class don’t make it and are counseled out of the organization.
• after boot camp, all engineers get access to live DB (comes with standard lecture about “with great power comes great responsibility” and a clear list of “fire-able offenses”, e.g., sharing private user data)
• [EDIT thx fryfrog] “There are also very good safe guards in place to prevent anyone at the company from doing the horrible sorts of things you can imagine people have the power to do being on the inside. If you have to “become” someone who is asking for support, this is logged along with a reason and closely reviewed. Straying here is not tolerated, period.”

• any engineer can modify any part of FB’s code base and check-in at-will
• very engineering driven culture.  ”product managers are essentially useless here.” is a quote from an engineer.  engineers can modify specs mid-process, re-order work projects, and inject new feature ideas anytime.  [EDITORIAL] The author of this blog post is a product manager, so this sentiment really caught my attention.  As you’ll see in the rest of these notes, though, it’s apparent that Facebook’s culture has really embraced product management practices so it’s not as though the role of product management is somehow ignored or omitted.  Rather, the culture of the company seems to be set so that *everyone* feels responsibility for the product.
• during monthly cross-team meetings, the engineers are the ones who present progress reports.  product marketing and product management attend these meetings, but if they are particularly outspoken, there is actually feedback to the leadership that “product spoke too much at the last meeting.”  they really want engineers to publicly own products and be the main point of contact for the things they built.
• resourcing for projects is purely voluntary.
  • a PM lobbies group of engineers, tries to get them excited about their ideas.
  • Engineers decide which ones sound interesting to work on.
  • Engineer talks to their manager, says “I’d like to work on these 5 things this week.”
  • Engineering Manager mostly leaves engineers’ preferences alone, may sometimes ask that certain tasks get done first.
  • Engineers handle entire feature themselves — front end javascript, backend database code, and everything in between.  If they want help from a Designer (there are a limited staff of dedicated designers available), they need to get a Designer interested enough in their project to take it on.  Same for Architect help.  But in general, expectation is that engineers will handle everything they need themselves.
• arguments about whether or not a feature idea is worth doing or not generally get resolved by just spending a week implementing it and then testing it on a sample of users, e.g., 1% of Nevada users.
• engineers generally want to work on infrastructure, scalability and “hard problems” — that’s where all the prestige is.  can be hard to get engineers excited about working on front-end projects and user interfaces.  this is the opposite of what you find in some consumer businesses where everyone wants to work on stuff that customers touch so you can point to a particular user experience and say “I built that.”  At facebook, the back-end stuff like news feed algorithms, ad-targeting algorithms, memcache optimizations, etc. are the juicy projects that engineers want.

• commits that affect certain high-priority features (e.g., news feed) get code reviewed before merge. News Feed is important enough that Zuckerberg reviews any changes to it, but that’s an exceptional case.
• [CORRECTION -- thx epriest] “There is mandatory code review for all changes (i.e., by one or more engineers). I think the article is just saying that Zuck doesn’t look at every change personally.”
• [CORRECTION thx fryfrog] “All changes are reviewed by at least one person, and the system is easy for anyone else to look at and review your code even if you don’t invite them to. It would take intentionally malicious behavior to get un-reviewed code in.”
• no QA at all, zero.  engineers responsible for testing, bug fixes, and post-launch maintenance of their own work.  there are some unit-testing and integration-testing frameworks available, but only sporadically used.
• [CORRECTION thx fryfrog] “I would also add that we do have QA, just not an official QA group. Every employee at an office or connected via VPN is using a version of the site that includes all the changes that are next in line to go out. This version is updated frequently and is usually 1-12 hours ahead of what the world sees. All employees are strongly encouraged to report any bugs they see and these are very quickly actioned upon.”
• re: surprise at lack of QA or automated unit tests — “most engineers are capable of writing bug-free code.  it’s just that they don’t have an incentive to do so at most companies.  when there’s a QA department, it’s easy to just throw it over to them to find the errors.”  [EDIT: please note that this was subjective opinion, I chose to include it in this post because of the stark contrast that this draws with standard development practice at other companies]
• [CORRECTION thx epriest] “We have automated testing, including “push-blocking” tests which must pass before the release goes out. We absolutely do not believe “most engineers are capable of writing bug-free code”, much less that this is a reasonable notion to base a business upon.”

• re: surprise at lack of PM influence/control — product managers have a lot of independence and freedom.  The key to being influential is to have really good relationships with engineering managers.  Need to be technical enough not to suggest stupid ideas.  Aside from that, there’s no need to ask for any permission or pass any reviews when establishing roadmaps/backlogs.  There are relatively few PMs, but they all feel like they have responsibility for a really important and personally-interesting area of the company.
• by default all code commits get packaged into weekly releases (tuesdays)
• with extra effort, changes can go out same day
• tuesday code releases require all engineers who committed code in that week’s release candidate to be on-site
• engineers must be present in a specific IRC channel for “roll call” before the release begins or else suffer a public “shaming”
• ops team runs code releases by gradually rolling code out
  • facebook has around 60,000 servers
  • there are 9 concentric levels for rolling out new code
  • [CORRECTION thx epriest] “The nine push phases are not concentric. There are three concentric phases (p1 = internal release, p2 = small external release, p3 = full external release). The other six phases are auxiliary tiers like our internal tools, video upload hosts, etc.”
  • the smallest level is only 6 servers
  • e.g., new tuesday release is rolled out to 6 servers (level 1), ops team then observes those 6 servers and make sure that they are behaving correctly before rolling forward to the next level.
  • if a release is causing any issues (e.g., throwing errors, etc.) then push is halted.  the engineer who committed the offending changeset is paged to fix the problem.  and then the release starts over again at level 1.
  • so a release may go thru levels repeatedly:  1-2-3-fix. back to 1. 1-2-3-4-5-fix.  back to 1.  1-2-3-4-5-6-7-8-9.
• ops team is really well-trained, well-respected, and very business-aware.  their server metrics go beyond the usual error logs, load & memory utilization stats — also include user behavior.  E.g., if a new release changes the percentage of users who engage with Facebook features, the ops team will see that in their metrics and may stop a release for that reason so they can investigate.
• during the release process, ops team uses an IRC-based paging system that can ping individual engineers via Facebook, email, IRC, IM, and SMS if needed to get their attention.  not responding to ops team results in public shaming.
• once code has rolled out to level 9 and is stable, then done with weekly push.
• if a feature doesn’t get coded in time for a particular weekly push, it’s not that big a deal (unless there are hard external dependencies) — features will just generally get shipped whenever they’re completed.
• getting svn-blamed, publicly shamed, or slipping projects too often will result in an engineer getting fired.  ”it’s a very high performance culture”.  people that aren’t productive or aren’t super talented really stick out.  Managers will literally take poor performers aside within 6 months of hiring and say “this just isn’t working out, you’re not a good culture fit”.  this actually applies at every level of the company, even C-level and VP-level hires have been quickly dismissed if they aren’t super productive.
• [CORRECTION, thx epriest]  “People do not get called out for introducing bugs. They only get called out if they ask for changes to go out with the release but aren’t around to support them in case something goes wrong (and haven’t found someone to cover for you).”
• [CORRECTION, thx epriest] “Getting blamed will NOT get you fired. We are extremely forgiving in this respect, and most of the senior engineers have pushed at least one horrible thing, myself included. As far as I know, no one has ever been fired for making mistakes of this nature.”
• [CORRECTION, thx fryfrog] “I also don’t know of anyone who has been fired for making mistakes like are mentioned in the article. I know of people who have inadvertently taken down the site. They work hard to fix what ever caused the problem and everyone learns from it. The public shaming is far more effective than fear of being fired, in my opinion.”

It’ll be super interesting to see how Facebook’s development culture evolves over time — and especially to see if the culture can continue scaling as the company grows into the thousands-of-employees.

What do you think?  Would “developer-driven culture” work at your company?

After reading this, a development manager friend said:

'I am seriously considering deleting my Facebook account. Lowlight: “after boot camp, all engineers get access to live DB”. I am also astonished that they don’t have more outages, if the article is to be believed.'

Regardless, a fascinating look into the inner workings of a hugely successful technology company.

I actually opened the FIFA 2010 app a couple of times. Then I discovered the Vuvuzela app - that was all the football (sorry, soccer) themed appiness I could deal with.

Read the whole blog at http://tpdsaa.tumblr.com/ - it's generally amusing.

(h/t @spencerchen)