CPlatypus

Literally? Did you literally fall asleep in English class?

Hey, crazy idea: why don't more employers give workers a choice? As a quick read of this thread will show, some people like quiet so they can concentrate, while others like the interaction and "energy" of being with others. That's fine. Live and let live. A startup might have to choose one kind of space, but you don't have to get all that large before it becomes possible to have separate areas/floors for different work styles. It seems like such a no-brainer, but I've only ever seen companies do "one size fits all" or segregation by status. Any employer who let me choose whether to work in a private office or a 2-5 person office or a big open area would definitely get some extra points from me.

Another metaphor I've seen is to the military (specifically the army), and consists of three roles. Don't beat me up about military minutiae, please; I don't claim to be an expert in that area and it's not even my metaphor.

(1) Paratroopers, who jump into unfamiliar territory. In software, researchers and architects.

(2) Infantry, by far the largest component, responsible for the core task of taking and holding territory. In software, most programmers.

(3) MPs (also quartermaster, community liason, etc.) who maintain order in the held territory. In software, debugging specialists and release engineers.

The problem I have with the OP's metaphor is that the "starter" and "architect" roles are both part of (1) and many people actually can do both pretty well. Similarly, the "debugger" and "finisher" roles are both (3) and also combine well. What's really unfortunate is that (2) seems entirely absent even though in real life it consumes most of the time and resources on a project. These are the folks who take mostly-complete designs from a starter/architect, and get most of the code mostly working before the serious integration/stress testing occur and the debugger/finisher come to the fore. In other words, most of your colleagues most of the time. If you hired four people according to these four roles, you'd have nobody to write most of the code and you'd be abusing your four specialists to do it.

I really wish they'd give more information about their methodology. For example, I've used the SoD SSD servers for some of my own testing, and they pull 30K IOPS for small random synchronous writes. How does that translate to "361.62"? WTF are the units here? What workload were they even testing? Yes, I know they list the random grab bag of tools they're using, but most of those are capable of generating many different kinds of I/O and they don't say what arguments they used. "361.62" seems very precise. I'm sure the two digits after the decimal point really impress the pithed snails or MBAs who are the benchmarkers' apparent target market. However, given both the bogosity of combining disparate measurements like this and the well known variability over time of cloud performance, that precision is not justified. Numbers that are more precise than they are accurate or meaningful are just decoration.

P.S. I expect someone will ask for more specifics, so here are a few. First, Bonnie++ sucks. Many of the numbers it produces measure the memory system or the libc implementation more than the actual I/O system. I've seriously gotten more testing value from building it than running it, so its very presence taints the result. Second, fio/hdparm/iozone might be redundant, according to which arguments are used. Or the results might be non-comparable. Either way, the aggregate result could only apply to an application with exactly that (unspecified) balance of read vs. write, sequential vs. random, sync vs. async, file counts and sizes, etc. Did they even run tests over enough data to get past caching effects? That's particularly important since they used different memory sizes on different providers. Similarly, what thread counts did they use on these different numbers of CPUs/cores? Same across all, or best-performing for each component benchmark? With such sloppy methodology anything less than an order-of-magnitude difference doesn't even tell you which platforms to test yourself.

When exactly did "startup" come to mean only "social web-oriented startup that has access to user data in the first place"? I mean, come on, I know that's the kind of startup the YC folks specialize in, but there are other kinds. There's software that doesn't run in a browser, doesn't require a login, and doesn't serve ads . . . but you wouldn't know it from articles like this, which say you shouldn't trust startups because of a phenomenon specific to only one kind of startup. Is it too much to ask that people who write about startups not limit themselves to one kind?

While bequeathing code to the community instead of having it buried with you is a very good thing it comes with a caveat. In most cases, it's not a good idea to pick up the result in its entirety - all of the code, the brand, the users, etc. That's baggage. It's a burden, not a help. In most cases it's better to make an explicit fork, or even just cherry-pick the best ideas and bits of code for use in a clearly separate project. If users think the new thing is better than the old, they'll migrate. If they don't, they won't feel entitled to come bugging you for support - or, if they do, you'll have a good reason to turn them away and concentrate on making the new thing great. Obviously you have to comply with the original licenses if you copy code, but you'd have to do that anyway. This way is likely to be far better for your own sanity and ultimately for users as well.

Fair point about "pragmatism" but the contrary "elegance" often comes across as dogmatic or even elitist. Most languages strive for both pragmatism and elegance, but tend to favor one a little over the other.

And yes, this is relevant since Python and Clojure embody exactly this kind of tension.

I got tired of this and other VC games after my tenth startup a couple of years ago, so I guess it is possible that attitudes have changed. Even if Fred is one of the good guys, though, I'd still bet that he's in a small minority. That's the real point, which of course has been missed by most of the responses. Pick a random startup and go look for patent applications. Most of them clearly are pursuing that strategy, and most of those are likely to be doing so at the behest of their investors. This has been going on for many years, so why is it suddenly evil when Yahoo! does the totally inevitable? Is there seriously any reason to believe that Etsy or Twilio - USV companies for which I've already found applications - wouldn't? This kind of thing won't stop until people like Fred refuse to invest in companies that are pursuing patents without a binding commitment to use them only in defense, and for all their strong words they don't seem to be doing that.

I just looked at all of Fred's comments on that thread, and saw no such thing. Please don't lie just because you find the truth about startups and patents inconvenient.