joeemison

I would challenge your assertion that you need a core competency in bare metal. AWS and GCE are performant enough--you're just not using them correctly. Invest in IaaS expertise and be successful; invest in bare metal at this day and age and live to regret it forever.

For evolutionary features, you're right. But I think the point in the article is that if you're trying to get to product-market fit, your customers' feature suggestions are rarely the ways to get there; you generally have to watch, think, synthesize, hypothesize, and iterate again and again to get to the solution that actually does what you need done.

The proof is in your hostile attitude toward her.

Her post is about how she felt profoundly unwelcome in the FreeBSD community. Your response is not a counter-argument to her feeling unwelcome. As far as I can tell, your response is, "Randi did bad things." That's a non-sequitur. It's not a response to her feelings of being made to feel unwelcome.

If you had a germane response, I am guessing it would be, "Randi should feel unwelcome, because she is not a good person." If that's your response, you're not actually disagreeing with her. She said she felt unwelcome, you're basically saying, "Good. Yes. That's a good result."

I never said that it "gave her the right" to do anything. I said that it did not negate the bad things that happened to her. I said that we should not ignore the very serious and legitimate issues she raises because she's gotten very angry at people.

And here's the fundamental issue I see in all of these debates: the majority (here, young white males) tries to invalidate completely legitimate concerns because the person raising those legitimate concerns has done things that one can criticize.

You can see this rampantly in links that are provided to somehow negate her claim. "She's not a real contributor to FreeBSD, so her claims are invalid." "She gets angry at people, so her claims are invalid."

Look, Rodney King was not innocent of all crimes when he was badly beaten by the LAPD. Does that excuse those cops? Of course not. The only germane "counter-evidence" to Randi's post would be evidence that the FreeBSD has actually be incredibly and consistently welcoming to her. Because fundamentally her claim is that the FreeBSD community has been decidedly unwelcome to her. And yet all the "counter-arguments" here are repeated and painful reminders of how nasty and awful the "counter-arguers" are to her. It's mind-boggling.

Thanks for the more specific links. She's definitely a strong activist for what she believes, and can certainly dish it out. I don't think any of that necessarily negates bad things that have happened to her, nor does it validate the long list of bad behavior directed toward her after her post.

For me, I think it comes down to who's outnumbered. I'm willing to give her the overall benefit of the doubt because I've seen the misogyny consistently over the past fifteen years I've been in the industry. I can't judge how much PTSD I would have after dealing with the harassment I've read just around this post she's made.

I just spent far too long reading both of those links, and I don't see anything there that contradicts anything Randi said in her post.

If someone is regularly and routinely attacked (and all the bullshit about "Randi can't code" / "Randi hasn't contributed" is just obnoxious), it's reasonable for them to be pissed off and get angry. That doesn't somehow negate the fact that they were badly mistreated.

In hindsight, it's telling that people making the above comments are posting links to longreads and not citing anything specific--just seems like more of the misogynistic campaign.

It's the difference between having great documentation and full sample applications and just having a skeletal description of bare API calls. The review of API Gateway does a pretty nice job of laying out how the latter can be a pretty awful DX.

What's worth reporting back is whether Rackspace is worth using in a world where AWS exists. A year ago, the answer was "No". OnMetal looks very interesting, though.

I'm signing up. Will report back.

Great point--unless you need your core competency to be "innovator in HR policies", why spend any time there?

I agree that there's nothing wrong with being motivated by money as an employee, but there's lot of strong research that, as an employer, you keep more employees based upon non-monetary aspects of the job. If, as an employer, you start focusing on money, it better be because you (a) want that as your culture, and (b) can pay a whole lot.

In my experience, those who have made it to Series A have had enough humbling experiences to have learned how to hide obvious arrogance. I would agree with your assessment of brand-new CEOs, though.

I don't think that the mediocrity of other tech organizations implies that functioning ones are "badass". It's a sad state of the world that "actually shipping products that work" qualifies for awesome/genius.

I think it does apply to non-startups as well, because the "outsourcing" I'm talking about with software development is really just using existing tools and frameworks, not bringing new developers into the fold.

For example, I think it makes more sense for the NSA to use existing databases than writing their own...

You miss the point--you're talking about outsourcing development. The point of the article is to use libraries whereever you can, not to oursource all development to non-in-house developers. (The other reply to this gets it).

Of note, the company I most recently founded absolutely fits into the "finding a problem that large companies have, build a solution, and sell it to them". I can also name a bunch of highly-profitable B2B companies in the insurance and lending spaces that fit into those same categories (Global DMS, Guidewire, and Eagleview, to name three).

So it's definitely not true that those opportunities don't exist.

There was a courier service that had an office next to mine about 15 years back that took all sorts of precautions that they weren't shipping drugs. Here's an article that shows that those guys (Asheville Courier) weren't an isolated case: http://network.yardbarker.com/college_basketball/article_ext...

keychainlogistics looks like uShip--using existing professionals on the road. I totally buy that business model. I don't buy Alice and Bob transporting packages on their way to work.

As I said, though--definitely happy to be proven wrong. It would be pretty amazing.

I actually never argued (or at least didn't mean to argue) that one needed to have worked in a particular industry--rather, I was arguing that one needs experience with the particular industry. Experience can certainly mean (a) customer of the industry and (b) having researched the industry extensively. As you point out, receiving packages in the mail gives you little insight into the industry.

I agree with everything you've said here, and it's possible that one could pivot the idea of ride-sharing for packages to something viable.

I think I could have made it clearer in the article, but my point was not that The People's Parcel was "the worst startup idea", but that "the worst startup idea" is that doing Startup Weekends and Y Combinator are the best ways for you to create a company that will help you climb the entrepreneur ladder.

What were your reasons why it would fail?

If your customers pay you before you ship, and they trust the shipper, it's definitely going to happen. Happens every day now already.

I tried to make it clear in the piece that I think Startup Weekends are a really good and useful event. I think that everyone who participates in one, no matter what experience they have had to date, will learn something from one. I definitely did.

My complaint is more that our "startup society" pushes us far more toward the Startup Weekends of the world, and away from "boring" jobs at large organizations--and that's really silly, since (as I argue) a great case can be made that the most viable, most fund-able startup ideas will come from working at large organizations (mo' money, mo' problems, mo' moving-the-needle-a-little-means-big-returns).

I would submit to you that there are bad ideas that we know are bad without having to throw money at them and watch them fail. (And, look--even if we do throw money at them and watch them fail, that's not a definitive disposition, since it could have been execution errors that caused the failure). I think I made a strong enough case as to why this particular idea was bad, even in lieu of having an actual case study of someone trying it and failing.

But I would be happy to be proven wrong, and I'd bet some cold hard cash on failure...

Right. The People's Parcel was essentially ride-sharing for packages (but packages can't move themselves to locations for pickups or deal with transfers or travel the last mile after getting dropped off close-to-but-not-quite-at their final destination).

Nothing in the piece argues that one shouldn't try new technology. Under this 85%-rule-of-thumb, we went with Amazon Web Services for 100% of our infrastructure in 2008. It was clearly the right choice, and worth learning. My point was more that developers have a gravitational pull toward new and interesting that needs to be tempered by a focus on what's best for the business--and too often, it is not.

The idea of the 85% rule is more a rule of thumb than some kind of rigid metric--I mean, I'm not sure how you would even quantify that.

But I would argue that "as long as business features are being implemented regularly" is too vague to be useful. You could be regularly implementing business features and still have half of development time building some framework that is unnecessary.

It's really not that hard to switch from Recurly, since they will send your stores credit cards (if they have recovered them) to another provider.

About a year ago we had a problem with Recurly and were dissatisfied with their attitude toward the problem (they seemed to have a "crap happens and we fix things fast" attitude instead of a "that should never have happened with good engineering" attitude). We switched to Braintree over the course of about 5 weeks, and Recurly was very helpful in getting the credit card numbers over (which took about 10 days total, as there was some kind of communications issue at the beginning, but we got everything straight).

I would not recommend Recurly, but it isn't true that they "have you by the shorts"--they'll help you leave their service.