jackowayed

I work at Cloudera, and engineering has work from home/no meeting Wednesday. It allows people to work wherever they prefer and are most productive, and to have the whole day to focus with minimal distractions.

That said, we do still communicate as needed for the active work. But we do so in terms of emails, chat messages, and sometimes phone calls between only the necessary parties, without any long scheduled meetings or meetings that provide value in the longer term (eg. interviews or longterm planning meetings) as opposed to helping someone do the right work today.

It works great, we've been doing it for basically the whole life of the company, and I don't see it stopping.

It basically has nothing to do with the JVM. These speedups are entirely a function of how modern processors work. To some extent the platform/language matters because its guarantees determine how easily you can achieve good memory locality.

(For example, one could implement a java compiler that correctly made all Java code work, but gave absolutely no memory locality--different instance variables of an object could be arbitrarily far apart, and you could even implement arrays as linked lists (or at least chunk lists) so that arrays don't guarantee locality either. One couldn't make the optimizations he made under those conditions. But any language where you know what data will be contiguous allows you to make these optimizations.)

I'd guess that you knew this, but your comment suggests that there's something special about the JVM that makes it especially well-suited for these optimizations, which might confuse readers.

How about 256 words (or sets of words) representing each byte value? It's less dense by a factor of ~5, but it would work, be easy to decode, and be very difficult to identify, especially if you used sets of words. You could even cleverly generate in a way that is grammatically correct.

Intelligence is a major part of warfare. It's a lot easier to assassinate people if you have good means of finding the people you want dead.

I think Apache Zookeeper is a Paxos implementation. I've heard very good things about it. Various pieces of Hadoop use it, and I know of people who use it for medium-sized webapps that need a canonical, fault-tolerant configuration system.

No.

You have an adverse selection problem. If you're looking to hire really great contractors, then you're mostly looking to hire people who have continuing work with their extremely happy customers, leads that their extremely happy customers referred to them, etc. They don't need you that badly.

So, you ask them to work for $40 an hour for, say, a week. They could make at least 4x that if they worked for other clients. Why should they, the super awesome coder, take you on as a customer? You're asking them to pay a big opportunity cost for business they don't need that badly, and you're showing that you're price-sensitive, and are likely to try to get a discount off their full rate after the trial too. The people this will most scare away are the very best, the ones who don't need you, the ones you really want to keep.

So yes, do a trial if you're not comfortable committing to a big contract with them. But treat the difference between the rate you want to pay for the trial and their rate as part of the cost of finding great talent. Don't squabble over what's going to end up being a very small percentage of what you pay the person over their whole time with you at the risk of sending the best talent straight out the door. It's too great a cost.

Also, if you want great talent, double your expectation of what contract rates should be. $40 an hour as a contract rate in a 1st world country is not a "decent rate".

Mechanical Turk has a terrible person hours:revenue ratio if you live in a developed country. Not as familiar with the others, but I think Elance tends to pay pretty poorly too.

The packets are routed over the public Internet, but if you're using HTTPS, they'll look like encrypted garbage to anyone who doesn't have Google's SSL private key.

There are notable exceptions. Heroku is still shipping awesome new stuff at a rapid clip under their Salesforce overlords. I don't know directly, but the plan at acquisition time was that they would stay pretty independent. I would guess that that helps a lot.

I think Pivotal could be one of those. Him saying "same services" suggests that EMC isn't planning on absorbing the team into something else. It helps that Pivotal is (presumably) very profitable, so there's value to leaving it alone instead of just viewing it as a source of a ton of great devs.

If it's still really Pivotal, and it just happens to be owned by EMC, they might fade much slower than the "everyone leaves within a year and a half" that we've seen so many times.

Showing up in an image index (generated by crawlers) is different enough from showing up on Pinterest (curated by humans) that allowing one to make the choices independently is totally reasonable.

It's not like every YC startup was a paying customer of Convore. I'm pretty sure he meant that they used Convore instead of/as well as a mailing list to communicate with the rest of the batch. He was making a claim that Convore leads to better communication than a mailing list, and that in the case of that YC batch, it was enough better that he thinks it made the companies noticeably better overall.

But 200 people using it for free (and probably naturally fading out of using it once the summer is over anyway) is not going to keep them afloat.

It's interesting that he didn't include the Financial District. I know of a number of startups there, including some YC startups. He did make this a couple years ago though, and it may be that that's a more recent expansion as it's gotten harder to find reasonable options in SOMA.

I worked at Cloudera's office in FiDi over the summer and liked the area a lot. Super-convenient via BART (less convenient than SOMA via Caltrain, but one could always transfer to BART at Millbrae). Right in the middle of everything. Good food options. Felt pretty safe walking to BART after dark because there's enough people around.

If we get to a point where we can do all the work we want to get done with, say, 1/4 of the workforce, then everyone can work less, or the average amount of one's life that one works can go down, etc.

There isn't necessarily value to "having a job" (especially when you talk about all the unskilled jobs that are going away, which are often jobs that people are doing purely as a means to support their life); there's value to being able to live and have the life that you want. If getting everyone they life they want takes less and less work, cool.

But really, people will likely just keep wanting more and better and we won't run out of work to do

To be accepted into college at 16, you simply need to skip one grade and have your birthday be later in your school year than your acceptance to college.

I skipped a grade, then I got into Stanford "early action", which means I found out in December when I was still 16. I turned 17 fairly soon thereafter, and was 18 for roughly half of my freshman year of college.

So one doesn't have to be that far ahead of schedule to "be 16" (even if that means almost 17) when getting into college.

Being one year young doesn't really inhibit my ability to take advantage of Stanford in a serious way. The fact that there will only be one quarter when I am eligible to take the wine tasting course is about the extent of it.

Palo Alto, CA; San Francisco, CA; remote for some positions

Cloudera is hiring for everything. Lots of cool distributed systems problems to solve, plus some unique opportunities like being a trainer--live anywhere, travel all over for free.

I interned there last summer, and I was totally blown away. Everyone there is brilliant, and they get to work on technical problems that are at their level, not just making another webapp.

And they're completely exploding. They're aggressively establishing themselves as the Hadoop company. They just signed a big deal with Oracle that should help legitimize them even more in the places that matter (ie. with big companies that are willing to pay big money): http://www.cloudera.com/blog/2012/01/oracle-selects-cdh-and-...

The culture is great. Fun people to be around, they really appreciate that taking care of engineers is vital to the company's success, management is deeply technical all the way up to the CEO, and they have regular all-hands meetings where they say just about anything you could want to know about the company.

I was so impressed that I've kept working on-and-off when I have the time, and I convinced my brother to apply and take a job there.

http://www.cloudera.com/company/careers/

Eh. Even if growth slows a lot because more and more new systems are Hadoop/etc, big companies are so tied to their legacy systems that they basically never get rid of what they have, so those companies will have significant recurring revenue from their current customers for the foreseeable future.

I also get the impression that Exadata is a pretty impressive feat of engineering and, if you need to do what it's optimized for and are prepared to pay a few million per rack, it's a very good option.

I agree, it seems crazy to say that it's fair to pay $n now and another people $n in a year or two if we're still around. Maybe he thinks that feels more fair than any solution that compensates with equity, but it doesn't seem like that's objectively fair.

I wonder if issuing convertible debt would be a good solution. So then you are giving equity to reward the founder for taking on the high risk of not being repaid, but you let future investment determine how much they should get.

When Kickstarter started, the types of payment logic they needed (user approves payment now but don't execute it until later; user feels like they're approving one payment, but it is split between multiple recipients (Kickstarter and the project owner)) weren't supported by PayPal, but were supported by Amazon Flexible Payments Service

In 2009, PayPal rolled out a set of very similar API's that would allow them to do these things (see http://x.com). I would guess that the fact that they haven't made the switch is just a matter of inertia, the difficulty the transition might present, and having more important things to work on, but I'm not intimately familiar enough to know if there are other reasons they might be staying.

I do know that a friend of mine had a startup that started on FPS but was very, very eager to switch to PayPal when X came along because FPS presented so many problems. They were a lot smaller and less wedded to the platform, though.

I think they're claiming that it's true for Trello, not necessarily overall. Their other products are a testament to the fact that they're happy to go the other route (lots of money from few customers) with some products.

But since they think they've found a new form of "Data structure that anyone can find helpful", they'd rather try to get everyone using it than try to specialize it for a few verticals that might pay them a lot of money for a form of it that is optimized for their business.

Heroku runs a process for each application (or multiple). The first one for an application is free. But just like with GAE, they'll spin it down if it's idle long enough. So I know that if I go to a site of mine that no one has visited in months, where I'm not paying for extra instances, it'll take a few seconds to load. But having to run those free instances doesn't kill them because all but the first one for an application is paid for at 5 cents/hour, which presumable is enough margin to cover the free instances, and then some.

But they run normal applications. It started out being any Rack (Ruby web standard--Rails, Sinatra, etc) app; they've expanded into other languages now, but it's always some open framework that they're running for you, not something they own and keep proprietary. They give you a normal Postgres database. There are a few restrictions that you might not have on your own hosting (like a read-only filesystem). But you could basically take an app running on Heroku, install a webserver and Rails, install Postgres, make sure any config you had was the same, and run it.

Another huge advantage Heroku has is the ability to give other people access to their datacenters, since they're just running on EC2. So there's lots of Addon services that can add various pieces of functionality, like hosting a different database, many of which are only tractable because they're also hosted on EC2 and thus have very good latency to Heroku servers.

This means that you're not stuck with Postgres. If you think a part of your data, or all of your data, would be better stored in Mongo or Couch or Redis or flat files on S3, there are hosted services for that, and you can even deploy your own solution on EC2 if you'd rather. This leads to nice halfway solutions where you use Heroku to have super-scalable application servers, and maybe to manage your main relational db, but then you can tack on other things where that doesn't fit with your problem. Now, if you're running some of your own EC2 instances, you're losing some of the "never have to worry about hosting again" value of Heroku, but at least it's possible. It could be a temporary solution that keeps you above water while you migrate off of Heroku, or maybe you decide it really is the best long-term solution.

Heroku uses the same model. They're doing quite well.

GAE has problems, but I think the root is just how unique everything is. That manifests itself in people using a datastore that they don't understand, with Google expecting them to know how many writes an action will take and whether that feels like the right number of writes or two orders of magnitude more than if they made a different decision about how to store their data and solve their problems.

It also manifests itself in the lockin that Heroku mostly avoids (which is a huge problem if some subset of users get to a point where they realize "whoops, this would be much easier if I could do things Google won't let me do, time to leave").

I think a good counterexample is Engine Yard and GitHub. Engine Yard had a somewhat limited offering (especially for what GitHub was willing to pay) that didn't really fit with GitHub's heavy direct disk I/O. (Most Rails apps almost entirely read and write from the db, but GitHub does a lot of direct operations on the git repositories.) But GitHub was still just a Rails app, not an app for some specially-designed Engine Yard framework. So it was fairly painless for them to decide to solve the problem in a way that didn't fit with what Engine Yard would offer them and migrate to their own hardware. It wasn't easy, especially since they weren't solving an easy problem, but at least they didn't have to replace their database.

The above clause of the TOS is the reason not to sue. The seller agreed to a TOS that says that if PayPal decides that it is counterfeit, they refund the money and the item is destroyed, without any restriction on what care PayPal has to take to decide that it's counterfeit. So PayPal acted within the terms of their agreement.

This isn't just a matter of girls who actually are kind of ugly having body image problems. That's still bad (they should value it less highly, they often underestimate how attractive they are, etc.)

But a lot of women, especially those around high school age, are just completely irrational in this realm. I know lots of women who are very attractive in conventional ways but aren't happy with their bodies. They think they're too fat because their stomach isn't totally flat, even though they look just as good as if they were that skinny, and they're only 5 or 10 pounds off. They think their breasts are too small. They fixate on small imperfections like a little bit of acne.

This all happens because society puts forward an airbrushed ideal of perfection that they're told to strive for even though it's totally unattainable. They see all of the small ways they could be better without taking a step back and realizing how attractive they really are. The fact that lots of men are interested in them doesn't convince them otherwise. They'll claim those men just like them because they're nice, or that the men are just interested in anyone who they think will put out, or some other mediocre excuse.

I felt worse for these guys until I read to the end of the letter and found out about the "HiGear girls". It's not quite as bad as I thought because they don't seem to "rent out" these models like they do cars; I guess it was just a publicity thing. But still, having revealing pictures and even stats (measurements) of the women is pretty much the definition of objectification.

FOLLOWUP (responding to comments): I'm not concerned about the women in the pictures. They freely chose it, and made enough money to make it worth it to them.

But things that reinforce the societal ideal that women's value comes from being conventionally attractive is much more deeply damaging than most people realize. It leads to the body image issues that the majority of young women grapple with. Anything that makes it seem like numbers define how attractive you are is especially bad, because it makes it harder for people to accept their own non-ideal bodies as beautiful. It encourages young women to spend vast amounts of their free time learning about and working on being attractive rather than, say, tinkering with computers. To some extent, it leads to income inequality between men and women (Girls grow up with the message that pleasing men, by being attractive among other ways, is good, so they tend to up more passive in many situations. This makes them less willing to negotiate for salary, less willing to go out of their way to take credit for their work, etc. It also leads to other bad things like being less willing to say no to sex.)

I like seeing racy pictures of girls as much as the next guy, but displays of women like this, especially right next to and in the same format as rental listings, encourages societal ideals that are at the root of most of the gender-related problems in our society.

It seems like starting work before a contract is in place (save maybe very high-level exploratory work, like a table of contents) is a recipe for disaster. They don't really owe you anything until there's a signed contract in place saying you do.

Now, it's possible that Apress is problematic in that they strongly encourage people to work despite there being no contract in place ("we'll figure it out", "you have our word", "legal is slow", etc), which then puts them in a better negotiating position when it is contract time because people have already done much of the work.

But I wonder what would have happened if he had said, "I'll do high-level planning, but I won't write a single paragraph of actual content until we have a firm, mutually-satisfying contract in place." Maybe it would have gotten him a firm date on when he would get his advance that they would stick to, plus deadlines in the contract that were actually in the future and other good things. Or maybe they would have still said, "no, just write it, we'll figure that out later", which would not look good

You've probably hit the karma threshold where you can set the top bar to any color, and have the default color set (if you go to your profile page there would be a "topcolor" field)

I do this, and I actually have DNS. I think it's because what I did is:

* Sign up for a hosting plan one of the times that it was super-cheap (I paid like $9 for a year of hosting and got a free domain for the year.)

* Cancel hosting after cheap period is over

So all of my DNS stuck around, and I can change it and everything like normal. I think I can even buy domains elsewhere and use Dreamhost as my DNS server for them.

The one complaint I have with them is that their forgot password scheme is "email your password in plaintext", which makes me feel a little bit like my domains aren't safe. So if I were to find my ideal registrar (~$10, not evil, decent interface, free DNS), I'd switch for that reason.

Name.com is pretty bad too http://nathanhammond.com/namedotcom-another-unscrupulous-reg...

Basically: They opt customers in to a "service" where they show ads on any subdomain they haven't setup a DNS record for. Name.com keeps all the money, but the TOS says that you are responsible for making sure that they content that they choose to display on your domain is legal.

> In strict accordance with KISS methodology

Buying a ton of parts, carefully assembling them, and having it be your problem when something breaks is simpler than paying Amazon to solve the problem nearly perfectly?

Of course, if a company is hell-bent on killing startups, there is also no reason to invite them to Demo Day, even if they understand technology well enough to know how to kill startups.