First Opinion - Year One

fortune.jpg
Hoepfully this fortune is accurate

I spent most of my weekend dealing with server issues caused by having too many people chatting with their doctor simultaneously. While I had no desire to spend my Saturday dealing with our growing pains, it makes me happy to see how far First Opinion has come over the last year.

June first marks one year, to the day, that James and I officially joined First Opinion, so I thought I would take a moment to reflect on what a great year it's been. We talk a lot at First Opinion about building the last company any of us will ever work for and so I hope to be writing these each and every year from here on out.

I spent most of 2012 obsessed with disrupting health insurance. I had never worried about health insurance before, being male and single, and I had insurance from Plancast for the entire life of my daughter and most of my marriage, so I hadn't ever had to switch insurance, until we sold Plancast and I finally experienced the reality of a life without company sponsored insurance and the nightmare of getting adequate private insurance. It. Is. A. Pain. So I started researching, quite, a bit, about the healthcare industry, looking for an opportunity in the space.

I eventually decided attacking this industry was outside my current ability. Then I received an email from McKay saying he was leaving Baby.com.br to start another company in the healthcare space. I remember leaving that first meeting with McKay, after he gave me his pitch, thinking holy crap, he's figured out a way to give everyone access to a doctor

McKay and I talked nearly monthly after that while he tested and refined his original idea, bouncing ideas off me as he was shaping the core principles that guide First Opinion to this day. Towards the end of April, he called me late one evening and asked me to join him as co-founder.

McKay and I had been friends for a few years, and I had always told my wife that I would jump at the chance to work with him if the opportunity ever presented itself. So as soon as he made the offer, I knew I was going to take it, and James was the first phone call I made after I had gotten permission from my wife, and officially accepted McKay's offer. I had worked with James previously at Undrip and I was constantly blown away by the speed at which he moved, and the quality of his final product. I couldn't imagine building an app this with anyone else, so I'm incredibly relieved he said yes.

So now you know a bit about how I joined First Opinion, let's take a look at what we've been doing this last year. We officially began development on the First Opinion iPhone app on June 7, 2013. We released our first public beta to the app store in just three months later in September, it was a low key release whose primary purpose was to begin moving our beta testers that had been using MessageMe for the last six months to talk with their doctor.

james-submitting-appstore-9-22-2013
James submitting to the appstore on Sept 22, 2013, a little after 1am

We released our first real public version to the app store right before Thanksgiving, which in retrospect might not have been the best idea since most of us left on vacation immediately after. McKay wanted to be very hands on with the matching in the first release. He had recruited each of our doctors personally and knew them intimately. So when a new user signed up, McKay would get a notification, he would look over their details and decide which doctor would be right for them.

And since I was going to be visiting my wife's family, I wanted to make sure those matching notifications were rock solid, because if McKay wasn't getting notified, the user wasn't getting matched with a doctor. So I rigged the server to send an email, a text message, and a push notification for each new user that signed up.

Over the next couple of days, First Opinion steadily climbed the app store rankings, moving into the top five apps in the medical category, and McKay's phone blew up with notifications, three at a time, to the point where he couldn't get any sleep because his phone was buzzing every few minutes.

McKay, his wife, and Rachel rotated shifts over the next 36 hours matching people to their new doctor while I worked to get an automatic matching algorithm in place so everyone could finally get some sleep. On the flip side, each of our doctors was getting inundated with tons of new users every hour, all with a question or two to ask.

It was a crazy Thanksgiving vacation, but it felt good to have people using, and loving, First Opinion. We blew through our six month goals in about six days, and we parlayed that initial success into a new investment from True Ventures, who joined our other investors to help us continue to grow our vision.

We've spent these last six months moving offices1 and getting better at everything. We've worked tirelessly to make sure the servers are stable, we've released three other internal applications to help our doctors and our quality assurance team manage their growing user loads. We've released our first payment products and we've gotten tons of feedback from our users, sharing incredible stories about how their First Opinion doctors have helped them. We've also learned a ton about what works and what doesn't with virtual doctor consultations.

We've also brought in some adult supervision, in the form of our COO, Vik, who joined Rachel in growing and training our doctor network. With Vik's help we've taken our average response time to a question from hours to minutes.

I'm incredibly proud of the engineering work James, Jarid, and I have done over the last year, I'm not sure there is another team out there that could do as much in one year as we've done. They've blown away my expectations again and again this year and I'm genuinely proud of what they've accomplished individually and what we've accomplished together. I honestly don't think there is a better core engineering team out there at this moment.

I'm also incredibly thankful to be working with McKay, Jarid, James, Rachel, Vik, Ashley, Sarah, and all our incredibly knowledgable and compassionate doctors every day2. I'm also incredibly thankful for our users, each and every one of you3, I love you all, and I hope year two is as fun and exciting as this first year has been.


  1. We have switched offices three times over the last year, and that's not counting the two times McKay and Jarid moved before James and I joined. 

  2. I expect this list to be much larger next year :) 

  3. I also expect this number to be significantly larger next year also :P 

Sure, We can Do That

two-roads.jpg
Two roads diverged in a yellow wood

It was just another day at the office when Mark approached me about implementing a new feature for a project we were working on, before he could finish fully describing it, I interrupted him with, "Absolutely not, that would never work and here's why..."

I then proceeded to rattle off a long list of all the reasons why it would never work. Mark patiently listened to my mini-rant and then, with a heavy sigh, responded with something I've never forgotten, "Jay, you never say yes to anything and I'm getting to the point where I don't even want to approach you with new ideas anymore."

Some programmers might wear a response like that as a badge of honor, they might even relish in it, as this commenter on Hacker News shows:

A designer I worked with had lots of interesting stuff taped to his door

My favorite was probably the following:

“Can you just...”

no.

But I had no desire to be perceived as a Negative Nancy like that, and so Mark's response that day completely transformed my attitude about how I approach new feature requests. Now, my default response to most new feature discussions is that of course the engineering team can implement it, it's just a matter of priority.

Some developers will consider this a dangerous answer, but I think if expectations are agreed to ahead of time, most problems can be avoided. The entire team, or company, needs to understand the tradeoffs of the new feature, its ongoing maintenance, and how it affects the overall product.

IMG_8340.jpg
I snapped this photo at Seeking Alpha's office in October 2017

These tradeoffs are wonderfully summed up in two points of rfc1925:

(2a) No matter how hard you try, you can't make a baby in much less than 9 months. Trying to speed this up might make it slower, but it won't make it happen any quicker.

(7a) Good, Fast, Cheap: Pick any two (you can't have all three).

If everyone understands that anything can be done, as longs as acceptable compromises and sacrifices are made, the conversation can then change from, can we do something? To, should we do something?

I think should we do something is the more important question. If we accept we have the ability to build anything we can imagine, we need to decide if that's how we want to spend our time, because:

Among the most dangerously unconsidered costs is what I've been calling complexity cost. Complexity cost is the debt you accrue by complicating features or technology in order to solve problems. An application that does twenty things is more difficult to refactor than an application that does one thing, so changes to its code will take longer. Sometimes complexity is a necessary cost, but only organizations that fully internalize the concept can hope to prevent runaway spending in this area.

While the author is specifically talking about codebase complexity, I think this also applies to the overall product as a whole, marketing a product that does twenty things is much harder than marketing a product that only does one thing really well, especially if those twenty things span across multiple target markets.

I like to think about product complexity like a magazine subscription. I have packrat-like tendencies that require constant vigilance on my part to keep in check. A few years back I talked my wife into letting me get a magazine subscription, she reluctantly agreed after I told her I would throw the magazine away after I read it.

However, each month I would find one or two things in the magazine that I wanted to remember, so I would mark the pages and put the magazine in the corner so I could reference it later. My three year subscription ended last year, but to this day, there are 36 issues of that magazine sitting in a box in my office.

I can't bring myself to throw them away because I've marked something to remember in each and every one of them, but I also think about how annoying that box of magazines is, and how much space it takes up. That box has even survived a dwelling relocation or two. That's product complexity.

There's a reason why we have platitudes like, KISS, keep it simple stupid! and Good is the enemy of great because we really do need to keep reminding ourselves of what's really important and where we should be spending our time. Complexity in your codebase, and in your product, grows exponentially and can quickly spiral out of control--and paralyze your company--before you even knew there was a problem.

Missing Things

epic-fail-godzilla
Epic Failing

This last week I missed solutions to two different types of problems, and how I reacted to each type was so radically different that I thought I would take a moment to reflect.

The first type involved new feature discussions in the office. Usually, when the team starts discussing a new feature, one of the first questions asked is how much needs to change in order to support that new feature. My preliminary thoughts on a certain feature was that it was going to involve a lot of infrastructure changes, which caused us to rethink adding the feature at all because of the complexity involved. However, on further discussion, James, proposed a solution involving changing just a few things here and there.

After reflecting on James's proposed solution, he was completely right. I had completely overthought the problem and we really could fully support the new feature with just a few minor tweaks to our existing codebase.

My initial response to this first type of miss was all out pride. This is why I work with smart people, because they see things I don't, and their input makes me a better programmer, working with them makes me a better CTO, and their hard work makes First Opinion a better company.

The second type of problem I missed involved failures in our backend systems. We had two significant downtime issues this week. The first happened early in the week, one of our long running cron jobs had been failing for at least a day due to an input change.

The second happened early Saturday morning (or late Friday night if you prefer) and in my sleepy state I failed to fix the problem on my first stab, and so it stayed unresolved until I was awoken a second time a few hours later.

Both of these issues were caused by monitoring failures in our systems, and my initial response to both of them was disappointment in myself for how bad I had screwed up because neither issue should have ever existed for more than a few minutes, at most.

Programmers screw up, code is brittle and it breaks, a lot. But, because epic level screw-ups are so common in programming, you have to be careful in how you handle discussing the error after the fact, I don't know anyone who enjoys their failures being pointed out again, and again, and again. Likewise, I've never known a programmer who didn't feel just awful after an epic screw up.

epic-fail-300
Epic Failing

My focus instead turns to solving the issue that caused the epic failure, and to do that, I like to use the 5 Whys to figure out what went wrong, and to make sure the problem is never repeated again in the future. I also drop every other project on my plate until the solution is fully implemented. My team and I are going to fail spectacularly1 again, it's just the nature of software development, but the goal is to never fail in the same way twice.


  1. but just to be clear here, both these issues were caused by me, no team needed. Despite some big wins this week, overall, it was a tough week for my programming self-esteem. 

Corruption

James Talmage, writing in The Great Apostasy:

There is no institution so pure and excellent which the corruption and folly of man will not in time alter for the worse, and load with additions foreign to its nature and original design

This applies to code also :)

Be Succinct

I have a very roundabout way of getting to my point in a conversation1, and while my folksy style of communicating would be right at home in an episode of The West Wing, it seems to be a real problem for me in the real world. I don't know why I just can't seem to take Xenophon's advice:

Brevity is the soul of command. Too much talking suggests desperation on the part of the leader. Speak shortly, decisively and to the point [...] Then move on.

I also would choose to be considered witty over tedious any day of the week:

Therefore, since brevity is the soul of wit
And tediousness the limbs and outward flourishes,
I will be brief

--Polonius

I first realized this was a problem in my chosen career path when I attended my first meeting with Plancast's investors. During the course of the meeting, one of our investors asked me a question about how I was planning on hiring more engineers. I began answering the question with a wonderful story about engineers with the intention of segueing into my answer about how we would like to allow prospective engineers do a paid side project for us before offering full employment.

In the middle of my story, the investor cut me off and asked me to get to the point. Since then I've mentally noted numerous occasions where people I'm talking with have finished my sentences or cut me off and just moved on. These mental notes have caused a certain amount of paranoia to follow me into any conversation.

This paranoia to be succinct has also infected other areas of my communication, like emails, where my brevity has led to, on numerous occasions, omitting crucial details the recipient actually needed to clearly understand what the heck I was talking about. Alas, I'm just not good enough to paint gorgeous word pictures as succinctly as Hemingway2:

For sale. Baby shoes. Never worn.

And since I'm often so short on time, I feel like my communication tends more toward that of Blaise Pascal's than not:

I have made this longer than usual because I have not had time to make it shorter.

I guess my point is you should be succinct, but not too succinct that you leave out crucial details or waste too much time dialing up the brevity, something I struggle with daily3. I will say though, I think Twitter has really helped me deliberately practice being more succinct, but I've still got a long way to go. And if I ever do get it right, I can finally leave them wanting more.

https//www.youtube.com/embed/O27RzZEOkeA


  1. One of the reasons I decided on a one blog post a week goal for 2014 was to work on this problem, writing allows me to edit and revise my thoughts to get to the point in a way that conversation does not, and I'm hoping improved putting thoughts to words on a page will eventually bubble up to improved thoughts to mouth. 

  2. Or Not 

  3. this sentence is the tl;dr version of this blog post, yet I still added 400+ more words :) 

Google Plus and the Puck at Their Feet

So Google+ may or may not be dead. Either way, Vic Gundotra moving on can't be anything other than a huge blow to the social networking also ran. Now we'll just have to wait patiently to find out if his departure was a fatal blow or not. I really liked this Danny Crichton's piece on the early days of Google+:

"In many key ways, Google+ was ahead of its time. Its internal product focus was on choice and privacy, which Google felt was the competitive advantage needed to beat the incumbents. It was reaching out to a demographic of users who had been turned off by the news about personal information leaking on Facebook, yet who were still interested in engaging socially online.”

His whole piece was a great look at the internal politics of launching Google+, but while Google+ was a lot of things, it was never ahead of its time. Sure, it had some novel video and grouping features, but they felt more like Google's take on similar solutions from other companies, rather than any real envelope pushing innovation in the social networking space. In fact, its launch in 2011, really made me think of this famous quote from Wayne Gretzky:

I skate to where the puck is going to be, not where it has been.

Google+ was, without a doubt, what Mark Suster calls a "puck at your feet" response to Facebook's meteoric rise to prominence. A Facebook clone that wasn't nearly as good or useful as Facebook itself. In many ways, it reminded me of a less successful version of Microsoft's late nineties attack on Netscape Navigator1 with the launch of Internet Explorer. Microsoft correctly identified the future was the internet, and they definitely identified that you got to the internet through a browser, but they incorrectly focused on the puck at their feet (the browser) and missed the direction the puck was moving (the cloud).

What if Microsoft didn't bother with a web browser, but instead moved to own the internet outside of the browser? Imagine if Microsoft focused all its energy on the kind of collaboration the internet makes possible, if multiple Windows computers could easily sync their folders and files together (a la Dropbox) and if multiple people could easily edit shared Microsoft office documents simultaneously (a la Google Docs), all outside of a web browser. It would've been a much different decade for Microsoft if they had started it with easy syncing and collaboration throughout their entire Windows and office products, that would've been skating to where the puck is going to be.


Google reacted in the same way Microsoft did, just less successfully, they both thought they saw the future, but what they really saw was the present. Kudos to Google for recognizing it faster.

The predicted unbundling of Google+'s best features, like Hangouts and photos, follows Facebook's continued unbundling strategy. Both companies are now skating in the same direction to a mobile future of small focused apps that are loosely connected on the backend. It should be fun to watch the rest of this game play out.


  1. And Opera, don't forget about Opera 

Questions About Plancast

worker_penguin.png
Worker Pepper the Penguin

To pile onto my post last week about selling Plancast, I decided to pull out an email exchange I had with a fellow entrepreneur about a year ago. The entrepreneur is in the events space and was curious about some of the things we tried at Plancast and what worked and what didn't.

Which of the "social" tools on Plancast worked? And which didn't?

The number one absolute driver of engagement for us was email, it trumped everything else by a huge margin and was the only thing that would get users to come back on a regular basis. If I remember correctly, we had two types: a daily digest that would go out everyday of all the activity your friends had planned, and then a weekly summary of upcoming events of your friends and general popular upcoming events in your area.

Which ideas would you jettison and which would you keep?

We spent a tremendous amount of time integrating with Facebook and Twitter. Facebook was good for getting events into the system, though a lot of them were either really low quality, or semi-private, and so we spent a fair amount of time fixing titles, removing private and useless events, etc.. We built this elaborate system for Twitter so you could direct message your friend's events and invitations, this turned out to be a huge waste of time and almost no one used it.

f8_penguin2.jpg
Wait, what's that between MTV and ESPN?

If I had to do it all over again, I would focus entirely on email, and focus all my attention on getting access to their email or phone contact lists and not really bother at all with Twitter or Facebook until they wanted to send a tweet or share to their wall. We went the other direction, focusing on the social networks and neglecting their email account and I think that was a mistake. Sure, some people signed up because a friend posted on their Facebook wall, or tweeted at them (this was before Facebook graph, but that ship has sailed already too), but I think the time we spent implementing those features and working with their apis would have been better spent on email.

With mobile phones, their contact list is all that matters. In March or April, Facebook turned off api reading for both Path and MessageMe. That in and of itself is not all that interesting, Facebook turns off their read api for any growing social site, what is interesting is that Facebook thought it mattered. Almost all the growth at Path, and MessageMe, was coming from the phone contact list. Very, very, very, little of it was coming from Facebook or Twitter.

I really do like the idea of creating a mobile site where there's a big database of all events that are searchable. and then you can send any of those events to your friends. but you tell me--did this just suck?

I think this sounds awesome! I enjoyed seeing all the plans in my area at Plancast, there were tons of things we could've done to have a better mobile presence, and a better site. The problem is with relevancy, there are a lot of events out there, and on a page of 25 upcoming events, chances are you don't care about 20+ of them (maybe you have a scheduling conflict, or 20 miles is too far away, or you hate that band). This is an incredibly hard problem to solve, Eventbrite has entire groups of people trying to solve it, at Plancast we had me1 :)

Or should i go for email newsletters?

You most definitely should do email newsletters, get as many email addresses as you possibly can, email them around once a week (Although we sent emails out every day, very few people got an email every day since our daily digests only included activity generated from your Plancast friends, since the average user visited Plancast once a week, most people would get an email 2-4 times a week).

Or some kind of auto event notification, where people sign up for pushed content from their favorite venues/performers?

We started a pilot program in Austin that was similar to this, the idea was the bar would have a Plancast page that had all their upcoming events, and you could follow your favorite bars and find out what was going on. I still think this is an incredibly powerful idea and I still think it would be insanely useful, but it requires a tremendous amount of upfront effort. You have to basically sell the bar on it, and then most likely have someone you pay manually add the upcoming events for the bar, so it takes a large upfront investment of time and money.

The reason why we did the pilot in Austin is we had an awesome girl that volunteered to go to bars and do all that work for us. Sadly, Plancast didn't last for much longer after that so we never got to see the results of all her effort :( I still think it is a great idea though, but it will require a lot of "man on the ground" type work.

Or should we do "click on this event if you're going to this event" and/or "click on this event to see others going to this event?" thoughts here?

Meh, it was cool to see the 1000+ faces on certain events at Plancast, but almost no one ever clicked through to learn more about the people, they only cared about which of their friends were going to the event, it did help make Plancast feel more alive though, which was an overall win.

users.jpg
It was really cool to look at though

A lot of time people were afraid to click the "count me in" button on Plancast because they weren't sure they could make it. Mark wanted to add an "interested" button but I didn't like the idea of having two buttons, because then they had to make a choice on which button to click, I wanted to solve the problem by softening the language of "count me in" to "follow", but in the end we didn't do either.

You said earlier that you actually got decent enough traction to be a lifestyle business. if you had to identify 2 or 3 features on the site that got you to that level, what were they?

Not sure there was any one thing (or 2 to 3 in this case), we had a lot of initial press from sites like TechCrunch that seeded the site with a good amount of users in the beginning (each TC article in those early days was worth about 5000 signups), and then we got a good amount of core users that were bigwigs in the tech space who shared their calendars.

We originally envisioned the site as a lightweight way to plan events with your friends, but much like no one at Foursquare checks into Walmart or McDonald's, no one at Plancast created coffee events, instead focusing on events that made them seem like a special little snowflake (mainly things like concerts and conferences). Read into that what you will.


  1. Admittedly, I'm pretty awesome though. 

On Acquihires and Selling Plancast

secret-acquihire.png
Like getting picked last in Gym class :(

I wanted to take a moment and expand on a tweet I made hinting about our experience selling Plancast. Even though it's now been a few years, I think it's still relevant because not much seems to change in the land of acqui-hires.


I also just wanted any fellow entrepreneurs, who find themselves in a similar situation, to know how wrong this quote from New York Magazine is:

Making offers to four-fifths of a company as part of an acqui-hire, while legal, is nearly unheard of in Silicon Valley, where mergers and acquisitions are still generally governed by a certain type of decorum.

For me, the Carrie Underwood song, You won't find this, nicely sums up the difference between your startup being bought and your startup being sold.

There's once in a lifetime
And there's once in a while
And the difference between the two is about a million miles

When your startup is being bought, The acquiring company wants something you have, so you have leverage. When your startup is being sold, you’re trying to convince the acquiring company that they need you, which completely changes the power dynamic in the favor of the acquirer.

But in an acqui-hire situation, you usually have no leverage and no power because your startup has pretty much already failed, so there isn’t anything the acquiring company wants from you except your talent. And since they only want the people, it’s in the acquirer’s best interest to cut out the investors as much as possible, in order to give more money to the employees they are buying. We had multiple acquirers refer to any money paid to the investors as dead money.

The acquirer usually accomplishes cutting out the investors by trying to basically hire away all the employees of the startup and giving each employee a bonus and retention package, thus making the startup worth nothing, but effectively performing an "acquisition" of the startup. The negotiations of an acqui-hire usually revolve around what the acquirer is willing to do to make the investors and shareholders whole1, with the acquirer wanting to do nothing, and the founders wanting something for them so no bridges get burned.

I remember sitting next to a Google M&A guy at a small dinner, he mentioned it is usually the founders, hoping to start another startup some day and not burn their connections, who would push back to get something for the investors (Coincidently, this is exactly what we did at Plancast). I also know another entrepreneur who gave all the money he received from his acqui-hiring to his investors when the acquirer wouldn't budge on giving the investors anything2.

secret post 2
cannot stop thinking about the secret about Google acquiring a startup except for the woman co-founder

How we started the process

When we made the decision to shop Plancast around, Mark, me, and some of our investors, gathered around a conference room table and worked out a list of companies we would approach, and the order in which we would approach them. Once we had the list made, we worked through who we knew at each potential acquirer and which one of us would make the initial approach.

One of our biggest regrets is we worked through that list serially, contacting each potential acquirer one at a time, instead of working with multiple acquirers simultaneously. This not only took a long time, making Mark’s life hell for about six months, but also meant we had no leverage to get the acquirers to hurry up and make a decision. We did it this way because we were much more bullish on the attractiveness of Plancast at the beginning of the process than at the end, I mean, who wouldn’t want to buy us?

The process

Below, in no particular order, are some thoughts about the overall selling process.

  • Acqui-hires are incredibly hard to pull off and they fall apart all the time, you really, really, really can't count on your acqui-hire going through until you are either at your new desk or the money is in the bank.

  • The less ambitious acquirers basically told us that they would wait for us to fold and then extend employment offers. Their M&A department had drunk so much company kool aid that they believed we would actually choose to work there after hearing something like that.

  • The more ambitious acquirers tried to pick apart the team, extending offers or making overtures to just part of the team. In one of the cases, we shared a common investor with the acquirer, so Mark called him up and he basically said, “That’s the way these things work, what did you expect?”

  • While Mark took the brunt of the extra work of talking to each company, we all had to go through multiple all-day interviews and divvy up the massive amounts of due diligence that caused the whole team to lose days at a time of our actual work. This was incredibly tiring and high stress, with lots of traveling for Mark, Peter, and me. On more than one occasion there were heated arguments in our conference room about how to proceed.

  • It was well known among our investors and advisors that a certain large tech company was incredible picky in acquisitions. One founder told me that this particular company interviewed every single engineer in his startup, and then ultimately passed on the deal. We all went through thorough interviews there also, and they likewise passed.

  • After a while, you just had to shake off the rejections, if we took personally every company that passed on us, we would still be curled on the floor sucking our thumbs and crying out for our moms. You cannot take these things personally, you just can’t. Even knowing this though, it did hurt a little when our 8th choice turned us down, even if we didn’t really want to work for them anyway3.

  • We had multiple acquiring companies hint that they would’ve been much more apt to acquire us if we had more engineers. One even told us we were just flat out too small for the money it would cost to structure the deal. The magic number seems to be around 4-5 engineers with the whole team being under 104.

  • We ended up with multiple offers for Plancast, but passed on all of them, because the numbers just didn't make sense for us or our investors. Mark then published the best startup post mortem I’ve ever read as we were beginning the wind down process. His post prompted a whole new round of acquisition interest and we found Plancast a great home with Active Network a few weeks later.

  • The post mortem also prompted a lot of approaches by other similar startups with a pitch like: "We are in the same space and we would love to merge with you guys and raise a new round of funding from your current investors." Of course they would’ve loved to raise from our investors, our investors were awesome. In regards to all those offers, Jeff Clavier gave one of the best compliments I’ve received in my career, “If Mark and Jay can’t make this work, then I don't think anyone else can either.”5

I'm really grateful to Mark, Peter, Jeff, and McKay for reading drafts of this and making it better.


  1. Being made whole refers to getting at least the money you put into the startup back. 

  2. While I am positive this impressed his investors, this was a huge VC fund, and I’m kind of surprised they took the money, which was nothing to them but a decent amount to him. 

  3. We had lots of little inside jokes about this because every company thought they were the bee's knees and that they were our first choice. 

  4. This is 100% anecdotal. 

  5. Not one of those startups is still around. 

Let's Fight About it

I naturally take a moderate stance on pretty much everything, unless of course, you want to argue about something. What this means is I become more extreme when I’m challenged because I tend to defend the side I identify with most even though my true belief usually sits somewhere near the middle.

where_i_sit_what_i_do.jpeg
where I sit and what I do

I remember walking along the boardwalk in Ocean City, MD a number of years back when I was approached by a PETA representative who wanted to talk about the abhorrent conditions of chickens kept in captivity before they are slaughtered and sold in restaurants and stores.

His proposed solution to the chicken captivity problem, which seemed entirely reasonable to him, was for society as a whole to completely stop eating chickens and he got defensive when I chuckled at that suggestion. I told him that I agreed with him the conditions, which I was able to observe from the large pictures on the signs they had everywhere, did look horrible, and I felt chickens should probably be taken care of better before, you know, they’re slaughtered and eaten.

Where we diverged was I felt it might be unreasonable to expect everyone in the world to stop eating chickens entirely since they are a delicious bird that people love to eat. I also suggested his time would be better spent trying to find ways to improve the living conditions of the chickens rather than trying to set all the chickens free. Soon after we parted ways, ultimately agreeing to disagree on how to solve the chicken problem.

While I think, traditionally, there were lots of inhabitants in the land of moderation at the middle of the line, it seems that people just don’t want to compromise on anything anymore, and it seems to be getting worse and worse with each and every year, people are clustering to their respective side and refusing to venture towards the middle for any reason.

where_people_sit_because_internet.jpeg
where people sit now thanks to the internet

Something Awful, talking about groups like Furries, blamed the internet for this trend:

In the endless expanse of communications the Internet is, probably the greatest and most terrible gift it offers to furries, pedophiles, and others, is the ability to shut themselves off from the mainstream. They huddle in cloisters that are virtually unassailable by the outside world and whisper encouraging things to one another that would be nearly impossible to say in real life. Free from the pressures of society to conform to a boring standard they go in the exact opposite direction, externalizing things that are roughly as far from "normal" as can be expected. Then, within their protected virtual enclaves, they declare these things to be the norm. By declaring their perversions, mores, and general imbecility to be their own status quo they have simultaneously validated their own existence and demonstrated the inferiority of outsiders.

When you can surround yourself with a community that only shares your beliefs, you have a recipe for killing any and all compromise, why should I ever try and see your point of view when all my peeps over here are yelling and screaming that you suck? Add on top of that the ease at which you can hurl insults with relative anonymity and little repercussions means it’s much easier for any discourse to fall victim to Godwin’s law than for anyone to ever change their mind.

duty_calls.png
what, someone is wrong?

No one has ever truly changed their position under force. Publicly shaming someone might get them to quiet down, but I guarantee it won’t get them to change their mind, as observed by this comment on Hacker news by Joel Runyon:

It's ironic that people are intolerant of intolerance.

I get the 'tit for tat' argument, but if you're trying to get rid of an oppressive opinion by being oppressive, you're not really getting anywhere.

You can't really "force" anyone to believe anything. If you have to "make" someone believe something by force, then it doesn't seem like your argument is strong enough to stand on your own (a statement that's applicable to both sides of this debate).

While I don’t have any concrete suggestions for how to persuade someone to your side, I do offer this thought experiment that I’ve noodled on every now and again since the tragic events of September 11th, 2001. What if George Bush, instead of declaring war with these words:

And we will pursue nations that provide aid or safe haven to terrorism. Every nation in every region now has a decision to make: Either you are with us or you are with the terrorists.

From this day forward, any nation that continues to harbor or support terrorism will be regarded by the United States as a hostile regime.

Had instead said something like this:

We don’t condone what you have done, but we forgive you!

Do you think the last 13 years would’ve been any different?

Reinventing The Wheel

Ceazanne still life
Ceazanne still life

The other day I showed a fellow programmer an old blogging engine I had built quite a few years ago. He was shocked by how much work I had put into the code and as we went through one feature after another, he kept asking me why I had added it since it didn’t look like I had ever actually used the feature.

He’s right, of course, it turns out I wasn’t much for using pingbacks or trackbacks, and my infrequent posting1 meant no one ever commented on my blog, so they couldn’t appreciate the time I spent getting the interaction just right. But I learned a ton about how all those things worked during the nights and weekends I spent crafting that code. I also learned how to read and implement specifications during that time. I became a better programmer through reinventing the blogging wheel.

I love reinventing the wheel, I also love iterating on my previous solutions to make them even better. Luckily, I seem to be in good company with this compulsion, here’s Charles Moore, the creator of Forth, on reinvention:

Before you can write your own subroutines, you have to know how. This means, to be practical, that you have written it before; which makes it difficult to get started. But give it a try. After writing the same subroutine a dozen times on as many computers and languages, you'll be pretty good at it .

and here’s a description of Forth’s relentless iteration on his own code:

Moreover, he was never satisfied with his own solutions to problems. Revisiting a computer or an application after a few years, he often re-wrote key code routines. He never re-used his own code without re-examining it for possible improvements.

One of the things I love most about programming is the deliberate practice it entails, and with wonderful things like Github and Stack Overflow I’m not even sure it’s all that difficult to get started anymore. You can look at how better programmers have solved the same or similar problem and use their code as a template to roll your own solution. Joshua Froer, in Moonwalking with Einstein, uses Benjamin Franklin to describe deliberate practice:

Benjamin Franklin was apparently an early practitioner of this technique. In his autobiography, he describes how he used to read essays by the great thinkers and try to reconstruct the author’s arguments according to Franklin’s own logic. He’d then open up the essay and compare his reconstruction to the original words to see how his own chain of thinking stacked up against the master’s.

This is also similar to how chess masters improve their skill, Joshua continues:

“The best chess players follow a similar strategy. They will often spend several hours a day replaying the games of grand masters one move at a time, trying to understand the expert’s thinking at each step. Indeed, the single best predictor of an individual’s chess skill is not the amount of chess he’s played against opponents, but rather the amount of time he’s spent sitting alone working through old games.”

Sadly, even thought this is one of the things I love most about programming, it is also one of the things most frowned upon in programming, which is strange, since tons of things rely on this type of deliberate practice for improvement, no one complains when a musician covers a popular song, or an artist paints a picture of fruit, or a poet writes a poem about love. And yet, lots of programmers seem to relish pointing out how much time you’ve wasted on reinventing the wheel.

The other day, while working on my new blogging engine that powers this very blog, I decided I wasn't going to reinvent the wheel with the RSS feed generation. I spent a few hours trying out a few available libraries, but they all proved frustrating to install and/or use, relying on a ton of complicated xml dependencies and trying to be all things to all people. Throwing my hands up in frustration, I ended up rolling my own solution in about 30 minutes, how was I able to reinvent the RSS wheel so fast? Because I had done it once or twice before, and so I knew how.


  1. I spent way more time coding the blog than I ever spent actually writing posts. Which is really sad considering I last touched the code around 2006 and used it up until a few months ago.