Metacog

• 2012-06-02

  L’expérience est une lanterne qui n’éclaire que celui qui la porte.

  —  Céline. Translated: Experience is a lantern that lights only the bearer. (I’ve always taken that to mean that experience is a terrible way to learn things).

• 2012-05-30

  Leaky Data Code Smell

  Another code smell I learnt today: when you have a function that pulls in a lot of variables/data from an object, to process it within that function and spit it back out - that’s bad. It’s bad for your code base, it’s slightly messier in your objects layout, and it doesn’t make sense, given how all your data’s already hidden inside another object. Better to create a method on the object itself, and use that to do the processing. 

  Encapsulation extends itself to the way you use data inside objects, too.

• 2012-05-27

  

  Viki music launch party at Clarke Quay. Filled, incidentally, with Korean boy bands. 

• →

  When I was first at Facebook, a woman named Lori Goler, a 1997 graduate of HBS, was working in marketing at eBay and I knew her kind of socially. And she called me and said, ‘I want to talk with you about coming to work with you at Facebook. So I thought about calling you, she said, and telling you all the things I’m good at and all the things I like to do. But I figured that everyone is doing that. So instead I want to know what’s your biggest problem and how can I solve it.’ […] My jaw hit the floor. I’d hired thousands of people up to that point in my career, but no one had ever said anything like that. I had never said anything like that. Job searches are always about the job searcher, but not in Lori’s case. I said, you’re hired. My biggest problem is recruiting and you can solve it.

  — 

  Sheryl Sandberg’s Inspiring Speech At Harvard Business School | Poets and Quants

  There are a few other good ideas from her speech.

  1) That ‘careers are not a ladder — they’re a jungle gym’:

  The traditional metaphor for careers is a ladder, but I no longer think that metaphor holds. It doesn’t make sense in a less hierarchical world … Lori has a great metaphor for careers. She says they’re not a ladder; they’re a jungle gym. As you start your post-HBS career, look for opportunities, look for growth, look for impact, look for mission. Move sideways, move down, move on, move off. Build your skills, not your resume. Evaluate what you can do, not the title they’re going to give you. Do real work. Take a sales quota, a line role, an ops job, don’t plan too much, and don’t expect a direct climb. If I had mapped out my career when I was sitting where you are, I would have missed my career.

  2) ‘When you’re a leader, it’s really hard to get good and honest feedback’. Sheryl gets feedback by being very open and honest about her flaws, so people can bring it up with her when she’s acting up

  3) Politics matter less when a company is growing quickly.

  Get on a rocket ship. When companies are growing quickly and they are having a lot of impact, careers take care of themselves. And when companies aren’t growing quickly or their missions don’t matter as much, that’s when stagnation and politics come in. If you’re offered a seat on a rocket ship, don’t ask what seat. Just get on.

  Sidenote: I wonder if this is why some organizations lend themselves more readily to politics than others. Churches tend to be more political than average; prefectorial boards and large bureaucratic student societies (like NES) even more so. Whereas — and this has always puzzled me — NUS Hackers, despite having a mix of very talented and in some cases difficult group of coreteam members, tend not to have much politics. It could be due to our size. But it could also be due to the fact that we’re rapidly growing. Either way, growth seems like a useful barometer to keep in mind.

• 2012-05-23

  Code Smell

  Here’s a code smell I found out about today:

  If your functions have lots of parameters that are constantly being passed around, then you have too much state that you’re not putting in the right places. It’s probably a good idea to stuff all that state into an object and refactor those functions into object methods.

  Basically, whenever you’re looking at a piece of code, you should be asking yourself: “why shouldn’t I refactor this into a separate object?”

• 2012-05-22

  Dave Goldberg at Viki

  

  Dave Goldberg dropped by the Viki offices today. Dave is the CEO of SurveyMonkey, husband to Sheryl Sandberg (yes, that Sheryl Sandberg — Zuckerberg’s COO, amongst other things) and one of the early investors in Viki. 

  I took some notes throughout the session, and I’ll just post them here, with minor editing (I need to get back to reading the OAuth specs).

  On SurveyMonkey

  Ryan Finley started SurveyMonkey in 1999, and built the entire service with his brother for the first few years. Dave: “He had a relentless focus on making things simple … mostly because he didn’t want to support emails.”

  Dave and his team bought control from Ryan in 2009. When they bought it, it was very profitable because they had nearly no costs.

  Sidenote: I wonder if there’s more to that story, but looking at how they’ve done since: you can’t argue against the fact that they’ve been good for the company. For instance, Wikipedia: 

  SurveyMonkey’s mission is to set research free. Everyone deserves easy access to the information they need to make better decisions, and budgets, timelines and logistics should not get in the way. SurveyMonkey was created as a cost-effective and modern alternative to traditional market research.

  Interestingly enough, SurveyMonkey has primary ops in Portugal, originally for tax reasons. Their engineering team is very focused on user experience. And they have some crazy legacy problems: e.g., they are pretty much the only people running on a .NET and Python stack, with a Microsoft SQL database as the datastore. Mostly because .NET was what they started out with.

  They found a lot of uses for the product that they never expected. Even to this day there are too many verticals to focus on. e.g.: SurveyMonkey is used for quizzes, as a compliance test tool, and as a way to collect responses. Which is why they bought Wufoo, for their form building capabilities.

  On Investment

  He thinks Viki has done a great job of scaling so far. He’s really happy that he had the opportunity to invest. “It’s really hard to balance between scale and building up product … when Mark was building up his company, there was a time when all their energy had to go into keeping the site up. They had very little new features during that period. It was difficult.”

  (Sidenote: he missed Zuckerberg’s wedding. Thought it was a little house party, didn’t know until it was too late. Quite funny :) 

  But generally speaking Goldberg says that he doesn’t invest in startups for the money. He’d be happy if most of his startups were break-even. (He has other investments for money. Those he makes sure are good). The startup thing he does to give back to the community, because other people did that for him when he was young.

  On America’s economy

  “The Bay Area is really different from the rest of America. Lots of money, restaurant reservations are crazy, housing prices are booming, it’s hard to hire engineers, and it’s all very weird.”

  This discussion segues into how he thinks the Social Network was a really good thing for a lot of high school kids, who now want to learn to code and be like Mark, and build something. (Sidetrack into how Sheryl now isn’t so against video games, because all the female engineers in Facebook play video games).

  “Learning to code is something that’s probably going to be a lot more mainstream.” Dave is optimistic.

  On Measurement

  This was the bit that interested me the most. Nerses asked about metrics via Skype, from San Francisco, and Goldberg’s answers gave me a lot to think about.

  

  For instance, he has a testing meeting every week. This is significant because he does not believe in meetings; he only has 3 every week at SurveyMonkey. Testing is so important it’s one of those.

  At the meeting, they review what worked the last week, what results they can act on, and other data points. Goldberg says he’s still sometimes surprised by the data. “Things you think are a done deal sometimes turn out not to be, and vice versa.”

  They use usertesting.com, splunk for site pathing, and they have a bigger business analytics team than they do a marketing team. Dave gets a generated metrics report every morning at 11am.

  Summarized, in a sentence: “Always be testing.”

• 2012-05-21

  Darcy Laycock’s API Talk

  Darcy Laycock (@sutto) gave a very nice talk about API driven development at Red Dot last Saturday, and he dropped by the Viki offices today to talk to us about APIs. Here are some notes from that discussion, rapidly typed and then edited from an iPad:

  Speed

  • The expected response time for an API should be lower than 100ms. If it takes longer than that, you should probably worry.
  • Caveat: search APIs can take longer, so no worries, that is expected
  • See: this presentation by Instagram on how to work around slow parts of API
  • Darcy and his team have found 50ms to be the sweet spot

  Documentation

  • The best API documentation is handwritten (i.e.: not auto-generated from code). Be sure to present your documentation in an easily navigable format.
  • Consider including a console to explore the API. Consider using or following the example of Apigee.
  • Like Echonest, provide a test auth key that developers can use to test with, but with low limits.
  • Stripe, Twitter and Github APIs generally good examples to follow.

  Internal protection

  • For protection of internal APIs from outsiders, you may use an API key approach.
  • However, Darcy’s team has found AWS firewalls to be a good alternative approach.
  • Essentially, they only allow internal apps to access their internal endpoints.
  • This approach is simple, and  has the same benefits with the key approach, for less complexity.

  API architecture design

  • One approach is to separate out APIs - e.g. have the Graph resource separate from the People resource, and combine those resources at another API service in front.
  • Benefits of this approach: it’s easier to understand, and easier to test. Also, if you want to change the implementation of an API resource, for instance: switch the graph resource to a graph database, you can do that and know the API will continue to work.
  • If speed is an issue here, use HTTP caching in front of each resource, because most of the time will be spent on IO-blocking operations.
  • Also use threading at the combination stage, by requesting multiple resources at the same time. This is beneficial even with Ruby’s Global Interpreter Lock. And use Fibers in Ruby 1.9. There may still be some logic problems, but this is worth the speed benefit from taking a concurrent approach.

  Design of APIs

  • On API design, it does appear that Foursquare does something that Darcy has not seen in any other API: they display compact and full representations of objects. ‘Compact’ is the bare minimum to show in a list, e.g. a list of users; and a ‘full’ object is, say, a full profile of user.
  • Each object returns a flag saying compact or full.

  Hypermedia APIs

  • ‘Hypermedia is the term people use to describe Roy Fielding’s original REST thesis. Rails doesn’t actually implement real REST.
  • A distinctive feature of a Hypermedia API is that it is self-describing, parts links to other parts from within the API responses, just like on the web.

  Security

  • iOS-only apps can choose to not implement OAuth.
  • In general, Darcy recommends OAuth, and 2.0 over 1.0. Because the standard will cover all use cases.
  • OAuth 2 has something called ‘bearer’ tokens, that can be used for 2-legged authentication. This approach skips the typical OAuth dance.

  Caching

  • Use rack-middle in front of rack-cache to validate access token.
  • Make access token part of the cache-key.
  • Also you may use rack-middleware to set arbitrary HTTP “vary” header to cache based on other keys (e.g. country of the request)

• 2012-05-17

  Greg Wilson - What We Actually Know About Software Development, and Why We Believe It’s True (by CUSEC)

  Takeaways:

  Hour for hour, reading code is the best way to improve code. Not writing more unit tests; not running it. And the biggest benefit is from the first reader, for only the first hour. (Fagan, 1975 (from IBM), verified by Cohen 2006)

  Implication: work with small batches of code. Ones that can be read in one hour. (Also: maybe this is why OSS works; or Agile works). 

  Conway’s Law: A system reflects the organizational structure that built it. (Herbsleb et al 1999)

  (He jokes: so that explains Perl).

  If you increase the problem description by 25%, you increase solution complexity by 100%. (Woodfield, 1979)

  How you can use this: if you throw out 25% of the requirements, you halve the complexity of your program.

  The two biggest causes of project failure are poor estimation and unstable requirements (van Genuchten 1991, and replicated by others).

  Agile does not care about the requirements. But it works - meaning that agile’s attitude towards requirements isn’t what’s causing it to work.

  If more than 20-25% of a component has to be revised, better to write it from scratch. (Thomas et al, 1997)

  This is from Boeing, which writes mission critical software. Study has not been replicated, Wilson doesn’t know if this applies to, say, Facebook.

  Also: studies show that people write the same number of lines of code per hour, regardless of language. This implies that it’s more worthy to use an expressive language than a non-expressive language. But tradeoff with performance.

  This is really, really good stuff. Watch it.

• 2012-05-15

  Secrets in Publishing

  Peter Thiel’s latest CS183 class is about secrets. A 0-to-1 startup exists to find secrets (even one is enough) and execute on them. The best secrets are the ones that are both big and true. This is obvious, but worth saying: we sometimes limit ourselves to looking for small or false secrets.

  Peter posits that there are two methods to finding secrets: the first way is to work things out for yourself, which is what scientists do. The second way is to look at what people are not talking about. The second way is slightly more applicable to ‘people secrets’ (economics; business opportunities), as opposed to ‘nature secrets’ (chemistry, physics). The second way is usually easier.

  The rest of the argument he makes is long and well-constructed; you should probably read it for yourself.  

  But I want to examine his idea that the best secrets are the ones people don’t want to talk about. If this is true, what secrets exist in publishing?

  I can think of one: that books are going to die.

  Not true death, of course. I would probably be more accurate if I’d phrased the sentence as ‘books are going the way of the record player and radio’. People in publishing — myself included — shy away from the topic whenever it comes up (which is rarely) in publishing talks or conferences. Even on the Reading2.0 mailing list, nobody talks much about the slow, long decline of books. We talk about the issues surrounding that instead.

  What are the replacements for books going to look like? Well, we do have some idea as to what they could look like. Some people thought that multimedian books were the future - companies like Vook, for instance, started making video-books with that premise. They and many others have failed, and I think we can use their experience as an analog for the book future: multimedian books are currently unlikely to cause the death of the book. We already have TV shows and video games for that.

  Rather, I suspect that books are going to become shorter. Not novella-shorter, but radically short: short story or essay-length shorter. Seth Godin pointed out a few years back that business blogs have made business books obsolete. There is nothing that you cannot express as a business book that you can also express as a business blog.

  I think this will be true for novels. Sure, there will always be a subsection of the population who will read books. But as it is today, this subsection will be a minority of the population. Books are no longer the cultural drivers of our world. Young people do read, but they spend most of their reading online: blog posts, news articles and long-form essays. And other things like music, movies, and video games have overtaken books as cultural landmarks.

  I have three hypotheses that I would like to test: that 1) people are going to want shorter pieces to read 2) on-the-go, and 3) these habits will shape the books of the future.

• 2012-05-14

  So you’re right, I think. Measuring things in a startup may not be 100% good; it’s certainly no replacement for vision, and too much leaves no space for intuition. But then the converse is true: not measuring things in a startup is 100% bad.

  — from a conversation with Meng Wong, on Lean Startups.