Why Google Reader Really Got the Axe

When Google announced its plans to shutter Google Reader in March, the Internet freaked out. Twitter users raised their virtual pitchforks in outrage. Bloggers wept, scrambling to find a suitable replacement by the service’s July 1 death date.

Wired runs a take on why Google Reader is almost no more.  I do agree with most of the points on how the news consumption changed:

But there’s another reason Google decided to put its RSS reader to death. According to Mountain View, most of us simply consume news differently now than when Reader was launched.

“As a culture we have moved into a realm where the consumption of news is a near-constant process,” says Richard Gringras, Senior Director, News & Social Products at Google. “Users with smartphones and tablets are consuming news in bits and bites throughout the course of the day — replacing the old standard behaviors of news consumption over breakfast along with a leisurely read at the end of the day.”

Google Reader, and other RSS readers, subscribe to this “old” model. You sit, you pore through the day’s news link by link. Yes, some people are glued to their readers constantly. (Guilty!) And yes, you can use an app like Feedly to get your RSS fix on the go, but it’s a passive news-getting experience. With its updates to Now and Plus, Google wants its readers to take this more active approach to news consumption.

But I don’t like this narrow view of the Google Reader (or other RSS readers).  RSS is not just for news.  Sure, news are an important part of Really Simple Syndication, but it’s not the only one.  There are many others – Wiki updates, mailing lists, commit messages, shopping updates for deals and stock clearances, etc.  Even if Google considers supporting those with Google+, the support is not there yet.  Heck, there isn’t even a publishing API for Google+.  As a blogger, I have built up a small audience of subscribers, but there is currently no way for me to transfer them all to Google+.  Unless I really push them, and then manually publish every post into Google+.  It even sounds ridiculous.

We’ll see how it plays out …

Scaling Teams and the Fight Against Human Nature

Scaling Teams and the Fight Against Human Nature

Human nature dictates that we:

  • Form tribes to build identity and camraderie – yet in a scaling startup, this causes untenable, painful, progress-stopping inter-team rivalries.
  • Invent a common enemy upon which we can heap blame and against which we can fight – sadly, inside the tribes that naturally form, there’s often a tendency to create that common enemy internally (it could be marketing vs. engineering or testing vs. production or sales vs. execs, or any number of others).
  • Minimize the positives and focus on the negatives – that could be feedback from customers, internal critiques, manager reviews, product imperfections, or weaknesses in process. It’s so easy to forget that we somehow beat the formidable odds against building something that worked, something that attracted customers, something that scaled, and a company where hundreds of people really do want to work.
  • Resist change at all costs – yet in a scaling startup, change is the only constant, and processes, procedures, formats, teams, and everything else has to change to be successful.
  • Act emotionally, yet believe our decisions to be driven solely by logic – we tell ourselves we act rationally, but can easily prove that irrational biases rule our minds. This wouldn’t be nearly as dangerous if we could recognize these biases, but in another failing of human nature, we cannot – we cling to the notion that our decisions, unlike the rest of our species, are uniquely logical.
  • Lose empathy as our numbers grow – tragically, when we need empathy the most (as an organization gets bigger and there are more people to consider and more complexities between them), our nature is to rescind it. It’s easy to empathize with a small group you see everyday, but much harder to extend that empathy to everyone in a larger group (especially those you may not know well).
  • Create rules and process to prevent against repeats of singular abuses – the old adage of one bad apple ruining the whole bunch becomes more and more likely the larger a startup grows. Process can be wonderful, but sometimes we create a process just to ward against some bad behavior from a former employeee and, by doing so, ruin the company a little more for everyone. Use process to free and enable, not to punish and restrict.
  • Irrationally romanticize the past – “Remember how things used to be? It was so much better three years ago when I first started here and…” -everyone at any organization, ever. But I remember three years ago. It sucked compared to today. Our ability to delight customers paled in comparison. Our ability to attract talent was in the toilet. Fear about our budget and our bottom line was a daily occurrence. 2013 is superior in so many ways and I know it, but even still find myself fondly remembering (or, rather, misremembering) back in 2010 when (in my human-addled mind) it all seemed so much easier.

From 15 hours to 15 seconds: reducing a crushing build time

From 15 hours to 15 seconds: reducing a crushing build time

In summary:

  • Bad Practice #1: We favoured integration tests over unit tests.
  • Bad Practice #2: We had many, many features that were relatively unimportant.
  • Bad Practice #3: Our integration tests were actually acceptance tests.
  • Bonus tip: run the build entirely on the tmpfs in-memory file system.