socratic

Was the intent ever not to get talent acquired?

I'm very confused by all of the anger at Google and Facebook for acquiring these companies. The companies look like they were designed to get talent acquired in the first place! They both have very small teams (2--5), Sparrow at least appears to have taken very small amounts of funding (just seed a year or two ago), and I can't name a consumer desktop application (especially a really generic one like mail with tons of free competitors) that has become a major $1bn+ (or even $100m+) business in the last several years. There probably aren't enough eyeballs for ads, and App Stores have made consumer software cost expectations too cheap. What's more, Sparrow is pretty much designed to make Google's offering better.

Is this interpretation wrong? Could these small teams have built independent companies (rather than attractive teams for talent acquisition) on Mac desktop software in 2012?

Are there any good books (or other resources) on modern PHP?

I last used PHP back with PHP3 (and then went C++ => Java => Python => Python/JavaScript => Ruby => Python/R), but a bunch of code I want to read at work uses PHP (with Zend). I no longer remember most of what I learned about PHP3, though obviously the PHP syntax seems to be at least somewhat readable as a sort of amalgam of Perl and C++ syntax and idioms. What does, e.g., Facebook use to get engineers who don't know PHP (but might know C++ or Python) up and running?

Does anyone know if namespace packages actually work?

I've been wanting to put up a few utility libraries on Github. I don't think they're good enough for PyPI, and I mostly just want to be able to pip install them and have access to a few minor functions that I use periodically. However, I don't think they deserve their own top level library name, ideally, they'd all be under "socratic.*" or similar. However, there seems to be some sort of mess with init in the top level of the package, some pkgutil fix, some sort of incomplete PEP (maybe 402?), etc. Should I just give up and name my internal libraries "socratic_{name}" and be done with it? Or does having multiple packages with the same namespace work?

Does Python have a BPEL/BPM-style workflow engine like Ruby's ruote?

This doesn't seem to be it, but I would love to have a workflow engine which is designed for long running tasks, with periodic human interruption, conditional flows, and so on.

If this post wasn't on Hacker News, how would someone reach this page without knowing what R is? Would you expect a JavaScript tutorial page to explain what JavaScript is? Or a statistics tutorial page to explain what statistics is?

More broadly, your suggestion makes a lot of sense for websites about software projects. For example, the R software project page (the first hit if you Google for "r") says that R is "a free software environment for statistical computing and graphics." However, when would anyone seek out a set of tutorials about something without knowing (at least at the one sentence summary level) what that thing is in the first place?

Is that what Blank is arguing though?

I remember listening to your office hours at TC Disrupt, when you were talking to the guy from Omniplaces. You said: "This is commercialized research? Ouch. It’s often a solution in search of a problem..." (Of course, that was part of a broader commentary about how the startup shouldn't be competing with Google in search, which I don't necessarily disagree with.)

But I think that's what he's talking about. Sun, Google, Cisco, Akamai, VMWare, and a variety of other technology companies came fairly directly out of commercialized university research in systems, databases, networking, virtualization. Are there YC companies that are commercialized university research? Such companies at the very least seem very different from companies like Airbnb which seem like they evolved from a consumer problem rather than innovative technology. What's more, it seems like basing investing decisions on current consumer behavior and problems seems much more sensible than doing so based on technology, which is what Blank seems to be arguing and what you seemed to be arguing at Disrupt.

http://techcrunch.com/2011/09/12/tc-disrupt-office-hours-wit...

Is there a better signal than high-pay for choosing a technical internship? Looking at Alexey's list, with the exception of hedge funds, Google, Facebook, Twitter, Dropbox would be my top choices for where to do a technical internship, and they're also the highest paying. I suspect this is because a good engineering culture leads to engineers that cost more and get better equipment which eventually filters down to interns. (Obviously, there are exceptions, though.)

More broadly, is interning at a startup a good place to learn technical skills (rather than marketing, networking, funding, etc.)? Most of the information on running common web stacks, for example (nginx, rails, django, node.js, varnish, postgres, mysql, redis, etc.), is either freely available on the web or even can be bought as a service (heroku, app engine, aws). By contrast, the only way to find out how engineers have solved problems (web serving, analytics, etc.) at truly huge scale (e.g., 10+% of the human population) is to actually see the solutions at a big company (though sometimes companies will publish details of 3+ year old infrastructure). Big companies also tend to have stricter code review cultures, while small companies tend to just need code written now. All of this seems to point to learning significantly more at a (technically excellent) big company, even though the "output" of the intern might appear to be less.

In fact, doing a startup seems like it might be more like resume stuffing than working at Google or Facebook these days. Working at a small startup, you get to talk about your impact, how you built a mission critical piece of infrastructure, whereas at a big company you're probably only trusted to write some small features that are not in the critical path of full time engineers. What's more, you get to say that you worked at a startup, which everyone pretty much respects around California, even if the startup dies or wasn't very technically interesting. But the potential for learning quality engineering through code review and understanding the existing infrastructure seems a lot higher at the big company.

If I'm reading you correctly, you definitely made money on the App Store. But it sounds like you are still tens of thousands of dollars underwater in opportunity cost. Is it wrong to think about it that way?

You get "more than half" $3400/month, let's call that $1700/month over the last two years, for $40,800. The two of you spent two man-months developing the app originally, and maybe a month or two since then. Let's call that 3.5 man-months. In some sense, your only cost was about $4,100 (cost of living + failed designer + $500). However, you could also have just worked for someone else. Two years ago (when you developed the app), it looks like iOS development was getting billed at about $150/hr (in Austin, SF, and elsewhere, though one guy in Ann Arbor quoted $75/hr) [1]. 3.5 work months is about 595 work hours which is about $89,250. (Put another way, if your contracting hourly rate would have been $70/hour, you would have just broken even now.) If that math is correct (and I've made all sorts of assumptions), you would have done financially better to work for someone else (especially someone at the top of the charts), no? In a sense, did you "spend $100,000 on an app" in opportunity cost? How long do you estimate your app will continue paying out a "dividend"?

It sounds like you are saying: apps don't make that much money, so don't spend lots of money developing them. But apps seem to take at least a few months to develop, so it seems inevitable that apps will cost a lot of money if the developer/designer time is market price. (A <$10,000 app in 3.5 months would be an hourly rate of <$17/hr, for example.) Is that true, and if so, do you think aspects of that will change over time?

[1] http://news.ycombinator.com/item?id=1251155

Is there a standard set of tools that are being advocated here, in addition to the repository structure?

I've been mostly working with Rails lately, and I'd like to continue using tests, mocks/stubs, and sensible build rules, but I'm not sure what the preferred Python tools are. What's the best test::unit equivalent? What's the best way to mock an object? Do people really use Makefiles rather than something else (like SCons)? Is there some way to use virtualenvwrapper without bash (e.g., M-x eshell)?

Has anyone made a comprehensive comparison of the top web frameworks and how mature the libraries/plug-ins/services around them are?

Frankly, Rails and Node.js seem to have much more in common than apart. Both are based around relatively inconsistent languages (though conforming to some BDD or Good Parts style can help), both have deeply flawed runtimes in terms of performance and especially parallelism, and they seem to have extremely high overlap in the people who program in both frameworks.

What I care about is libraries, plug-ins, and services. Specifically, if I have some new web task, what I care about is that there is some library/plug-in/service that exists to perform that task (e.g., user auth, Facebook API, exception logging, Heroku, resque, state machines), that the library/plug-in/service is mature enough that I can pretend it works, and that it has enough of a community around it that it won't break in the future.

Is there some comprehensive list of use cases, plug-ins/libraries/services, and relative maturity of those plug-ins/libraries/services across web frameworks? For example, the maturity of the various ORMs across frameworks, or the various testing tools, or the various Facebook libraries. It would be great to see it change over time, and to know when to jump ship to the next flawed language/runtime that has good plug-ins/libraries/services.

This is actually a good answer, in that it suggests that norms might be important in answering the question. However, this [1] paper by some of the authorities on P3P suggests that the answer might be less clear than you are suggesting.

Specifically, these are the headline stats:

1. 34% of websites have errors in their P3P compact header in that they contain invalid, missing, or conflicting tokens.

2. 79% of websites with P3P compact headers are missing full policy files, which is required to be compliant.

3. Among the top 100 websites, only 48 have P3P compact policies, and of those, 41 have no full policy file, and 21 have errors making the header invalid.

4. 97% of invalid compact policies bypass Internet Explorer's default filters.

5. Vast numbers (thousands) of the valid compact policies are duplicates. In fact, a little under 5000 of the approximately 20,000 compact policies that are valid are the same policy (NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM) which coincidentally is listed all over the web as a bug fix for IE's cookie handling.

Reading between the lines, the norm here seems to be to either (a) not include P3P (52% of top websites) or (b) include it as a bug fix in an invalid, non-compliant way (21--41% of top websites). Is an invalid P3P header likely to be legally binding if the overwhelming majority of websites of all sizes implement it incorrectly, both intentionally and unintentionally? Is it worth the time, expense, and potential legal risk for a small startup to try to use it correctly?

[1] http://repository.cmu.edu/cylab/73/

What is the preferred way to handle P3P for a young startup or a small (possibly academic) project?

As I see it, there are seven relevant facts:

1. The intent of P3P is to make it so that you are personally, legally bound to enforce particular privacy guarantees.

2. The attempt to make a P3P standard has been abandoned for half a decade, and only one browser maker supports it, largely for historical reasons. Documentation and tooling for P3P is by-and-large about a decade old, and advocacy seems to have dwindled down to a few people at CMU.

3. Unless you send a P3P header with the right string of (potentially legally binding) guarantees, it is not possible to use third party cookies with Internet Explorer.

4. P3P was intended for exactly the case of tracking cookies.

5. Using a third party tracking cookie is often the best design decision for a particular problem, even though other mechanisms could completely avoid the need to handle P3P.

6. Almost no one has actually changed their P3P settings from the default set by their browser vendor.

7. Users only care if functionality they want exists, whether or not there is some esoteric "standards" reason why it does not exist.

So let's say you've got a new compelling piece of functionality you want to offer. You're a startup or small project. You want to make it as easy as possible for people to include your functionality with a single javascript include. (Maybe you're Disqus? Maybe you're a new advertising platform? Maybe you're a +1 button?)

Do you ask all of your users to include a piece of PHP code on their site so that you can send data while having it appear to be first-party? Do you put up a P3P policy that matches your intentions for the data? What are your intentions for the data? If your intentions change, do you change your data model to include what P3P policy the data was captured under? What is personally identifiable information? Isn't pretty much everything personally identifiable once you have enough experience with the user? If you even have lawyers, do they have any experience with P3P, or do they just want you to point to their extremely precisely written English document instead?

So I guess the six options are:

A. Implement your functionality in a way that is inconvenient for your users, but completely avoids P3P. For example, ask them to install a PHP script where you set first-party cookies for them.

B. Use third-party cookies and set a bogus P3P policy in your headers. Maybe you copy it from the Internet.

C. Use third-party cookies and set an intentionally, obviously broken P3P policy (just a link, as Google and Facebook do) pretending that you don't understand P3P or linking to your real, English language policy.

D. Do the same as C, but actually include privacy controls on your site for users who are willing to state them and log in.

E. Have an engineer spend a day guessing what P3P policy is most similar to what you want to do at the moment and in the future, and then write the P3P policy header files and XML and forget about it.

F. Get a lawyer and engineer to team up to implement P3P throughout your site. Determine what each of the P3P options legally means in your context, figure out which ones apply, and then ensure that every part of your infrastructure handles the policy correctly.

Is there a particular type of startup that would be appropriate for Boston versus other locations? My instinct is that outside of Biotech and Enterprise software, it is still a huge disadvantage to start a startup in Boston, but I would love to be proven wrong (ideally by some sensible statistics).

Is Boston the kind of place where you can locally raise a seed round with ten or twenty angels for your consumer web startup with great traction but no revenue? Is Boston the kind of place where you can find engineers whose former job was to scale a database or web server or cache to hundreds of millions of active users? Are there deep pocketed companies locally who can afford to and regularly do acquisitions? Are MIT/Harvard (or BC, BU, NE, Tufts, WPI, Olin) grads going to Boston startups, or are they going to banking, Dropbox, or Facebook? Are there enough senior people around?

Vertica, ITA, and Basho are all great companies for example, but are they succeeding because they are in Boston, or in spite of it? How often are these companies flying out to the SF Bay Area to handle core parts of their business (customers, investment, business development)?

This story lacks a summary, so here goes...

Flailing Fast is an underground classic chronicaling the story of two young entrepreneurs. I got an earlier version a few months ago, though it may have been floating around the startup scene for longer. The entrepreneurs meet at a networking event, happen upon accidental success with an iPhone fart app, and finally are undone by a combination of ambition (a fart app platform!), investors, and group psychology. Written in business case style, it could only have been written by an MBA, a bitter entrepreneur, or both.

Though optimistic in the end, Flailing Fast seems to ask, are we really so different from these young accidental entrepreneurs?

(Also, the whole thing is free to read online.)

Apple, Google, and Facebook all make around $1m revenue/employee and employ around 100,000 people. (Profit/employee is about $300-400k, incidentally.) While the average SV engineer isn't working at one of these companies, doesn't this mean that there are perhaps tens of thousands of engineers who are on average producing $1m/year in revenue?

(If not, it seems like you need to argue for an extremely skewed distribution of the value that individual engineers are adding based on quality or area of expertise.)

If one of these $1m revenue/year ("1MRPY") engineers starts a company with n 1MRPY engineer friends, is it so crazy to suggest that they might produce $x * n million worth of value over x years? (Even if they just build infrastructure and never turn a profit?) Or that they might be worth $4 * n million in revenue over a four year earn-out to an acquiring company?

Is there anywhere to read more about Geoff's Rocketmail experience?

In Founders at Work, Sabeer Bhatia (who co-founded Hotmail) paints a pretty awkward picture of Four11. According to the interview, Rocketmail started out as a directory service (I guess, hence "Four11"). They were Hotmail's partner, providing them with a searchable directory of other users. But then through the partnership Four11 found out how many users Hotmail was getting and decided to compete directly by making Rocketmail. Things were apparently especially awkward because both Hotmail and Four11 were funded by DFJ!

Anyway, it would be really interesting to hear the other version of events. (Hotmail and Rocketmail were competitors after all.) Obviously, being in webmail rather than directory services was the right call, but how did Four11 decide to switch and what were the interpersonal and business dynamics really like?

How do people actually test multiple client-side browsers?

In terms of testing, Jasmine and QUnit both seem to have reasonable APIs, and I'd be totally happy to use either. I'm sure there are other reasonable options, too.

But how are people checking all of the client-side browsers? Are people using Sauce Labs? Testling? Custom internal Selenium setups? Just loading up each browser in a VM locally and manually?

I agree that Hollywood is evil, however, is the argument that it has peaked really accurate? ("Hollywood is dying.")

This RFS doesn't really give any statistics (perhaps because it will be up for longer than those statistics will be current). That said, based on a few minutes of Google searching, the average American apparently watches 150 hours of TV per month, and every few years there is a new "biggest grossing film of all time." That doesn't necessarily constitute growth, but it hardly seems like the type of upheaval occurring in the recording industry.

Is this analysis incorrect?

Is hiring software developers an evaluation problem or a supply/demand problem?

GitHub provides a great signal for evaluating whether someone is one of the top 100 or top 1000 developers in the world. Just check how many follows or forks they have! But Linus and DHH can work wherever they want, and they're probably unlikely to work in SF for $60--100k plus options in your SaaS startup.

Because of supply and demand, the people who are going to work long hours in that price range seem to be recent graduates. As a result, all of the hiring processes I've seen are geared toward trying to get a vaguely passable evaluation of how good a recent graduate is, using the minimum possible developer time. This leads to the coding interview as we know it: 30--45 minutes long and usually involving a trite programming problem utilizing the most advanced class most undergraduates will have taken, introduction to algorithms.

Personally, I would love if tech companies switched to evaluating based on work samples (e.g., code), but I don't think it makes sense given the demographics that they're targeting as new employees and the amount of time to have a developer genuinely evaluate a coding sample (rather than count followers, etc.).

Is it likely that GitHire and similar will increase the supply of good candidates in the right price range, rather than periodically e-mailing the top developers on GitHub and possibly polluting the ecosystem?

Would you argue that students should not study for standardized tests (e.g., SAT, GRE, ACT) as well, because they should have learned the (restricted set of) material on the test in their classes?

This presentation brings up a tangential point that has always confused me: how error-prone is starting a subprocess, really?

I agree with the author's goals of making common tasks easier and more obvious. urllib2 is an easy target, as it was added to the standard library over a decade ago, long before REST was something people talked about. The best tools for packaging, versioning, and testing have always been a bit ambiguous in any language, including Python.

However, the author points out something that has always bothered me about Python: it is way harder to start a subprocess with an external command in Python than almost any other language. This has been true whether using sys or os or even subprocess, which is quite recent.

I always felt that this had something to do with the constant warnings in the documentation about how a pipe between the subprocess and the Python process might fill and cause the subprocess to block. Or how running the program through shell rather than exec or something might cause some sort of security issue. Are these real issues that other languages ignore in the name of user convenience, or has Python just never been able to make the right API (as the author seems to argue)?

Is there a list anywhere of which Computer Science (and related) textbooks are worth reading? (Perhaps based on which universities are actually using them?)

Personally, I find that the research literature is usually (intentionally or unintentionally) opaque and that most ideas worth learning are at least 5 years old, so textbooks are the best place to actually learn things from a source intended to teach you the material.

The list I could actually vouch for would be:

  CLRS
  Russell and Norvig
  Introduction to IR (Manning et al)
  Database Systems: The Complete Book

  Dragon Book
  Convex Optimization (Boyd)
  Probabilistic Robotics
  Foundations of Statistical NLP

Would it be wrong to think of Scala and Clojure as the F# of the JVM?

I had been thinking of Scala as though it was Java++ (in analogy to C vs C++): a language that adds a few features on top of Java for better abstractions, but regular Java programmers can basically program Java in it (and read it as though it was Java). However, it seems like truly idiomatic Scala code involves heavy use of advanced functional and type system concepts that cannot simply be glossed over.

Will Scala and/or Clojure end up as languages in the JVM used by a small number of senior developers to be more efficient on particular problems (like F# on the CLR) rather than the next big language used by everyone (like C++ superseding C for most problems)? And, is that an accurate portrayal of how F# is currently being used?

My understanding is that 0% of MIT admissions is non-academic admits (legacy, recruited athletes, development, under-represented minorities).

Is that incorrect?

Have these two follow-up posts changed anyone's mind about the first?

Yammer's productivity gains from Scala were apparently not greater than the losses due to poor tooling and the impedance mismatch between Java/JVM and Scala. Therefore, the engineers all thought it was better to just go back to Java.

That seems like a useful data point, but certainly others' experiences might vary. Have these other posts added any extra information?

Do people think the hiring and talent argument holds water?

The more I hear this argument (e.g., from the "Python Paradox"), the less I buy it.

Is the theory that true "hackers" care more about the programming language syntax and semantics than whether it has the right libraries for the subject domain of the startup?

Is the theory that true "hackers" care more about whether the startup uses a new and un-tested programming language than traction, likelihood of success, money, or the actual problems being solved?

Do the best "hackers" come in by searching job sites for niche programming languages, rather than referrals?

Even ignoring the huge disadvantages in library support, tooling, community sizes, and so on, are the hiring and talent advantages believable? Are the sort of people who learn Haskell also the sort of people who would be 99th percentile C++ systems engineers for some reason?

My question is: what has led current hiring practices, and specifically interviews, to be the way they are? I've been doing a job search recently, and to me at least, the process seems almost as arbitrary as management consulting interviews.

The common case is: (a) a (very nice) recruiter who largely doesn't understand your background calls to ask about which part of the company you should work in, then (b) you have a few phone interviews where you are asked what might as well be trick coding questions ("with some fancy bit manipulation this could be O(n)!") that are mostly collected in a few books or online anyway, and then (c) you do an on-site where you get another three to six of these questions, with maybe a simple "system design" question thrown in.

My hypothesis has been that the hiring process is largely aimed at Computer Science undergraduates with no significant prior work experience, and that the best way to distinguish just graduated CS undergrads is by testing them on the hardest class they are likely to have all taken: Introduction to Algorithms. Or maybe interviewing is just rarely rewarded and thus the lowest priority for engineers? In any case, insight into the design and implementation of this process would be really interesting.

Could someone experienced breakdown what a transaction like this looks like for everyone involved? I'm super curious. I've never been acquired, so I really have no insight into the process other than what I've read.

Here's the facts as I see them: Crunchbase says Hunch started in September of 2007 and had 23 employees on LinkedIn when they exited. (TechCrunch calls it a 20-person team, so I'm presuming that's all the employees.) They've gotten $19.2m in funding, let's just say $20m. TechCrunch claims the sale was "around" $80m.

So what does the breakdown look like? Who gets what? What are the likely investor terms?

My totally naive guess would be that the investors got at least a 1x liquidation preference, maybe more. I mean, did Hunch have any revenue? So there was at most $40m to go around to the people at the company. Of course, most of that probably went to the founders. Would maybe 20% of that have gone to the 20-ish employees? So naively pretending that each of the 20-ish employees got 1% for four years, did they each end up with an extra $100k/year? What's the likely distribution of shares among employees?

What are the transaction costs (lawyers, taxes, etc.) for this sort of acquisition? How long will the employees have to be at eBay to get their earn-out, and will that earn-out be in addition to their common stock in Hunch? Will they end up being paid less to work for eBay during their earn-out than if they were on the open market?

Of course, their are many other reasons to do a deal like this (passion for improving eBay's recommendations, for example), but let's ignore that for now.

This seems like an odd analysis if you mean that MongoDB is hitting the trough of disillusionment. MongoDB, Cassandra, HBase, and Redis all came out at roughly the same time (2008, 2009) according to Wikipedia and their project pages. Is there a reason they would be on totally different hype cycles?

As far as I can tell, no one has hated on Redis or HBase (except for the brief period when antirez tried to add VM to Redis) because they both (a) work and (b) solve real use cases. Has there been any suggestion that Redis or HBase lose data?

However, maybe you are right in a more general sense. Do you think that the idea of NOSQL itself is reaching the trough of disillusionment? Are we seeing a shake out of which of these data stores are actually designed by people who know what they are doing, both in (database) theory and in (systems coding) practice?

This may be what you mean, but a common approach seems to be to create extra tables to create sort-of-implicit-schema-less-indexes, e.g.,:

http://news.ycombinator.com/item?id=496946

A PostgreSQL-specific alternative might be to write triggers in one of the provided procedural languages to turn your JSON into something indexed or materialized elsewhere.

Do either of those work for you?

Also, purely out of curiosity, do you have a design reason for only wanting to store schema-less JSON, or have you just been burned by slow database migrations in the past?

There seems to be a big community of people who really want to reject schema and use JSON for everything, and I'm really curious if they (a) don't understand relational databases, (b) are getting some surprising productivity gains somehow, (c) have been burned by slow database migrations in the past, or (d) some other reason.