michaelq

Look what I found: Slack's free tier pricing page explicitly states "There's no limit on how many people you can add to your team on Slack." https://twitter.com/FreeCodeCamp/status/612758062214950912

I authored this blog post. There is a lot of merit to your criticisms of my decision making.

I want to point out that communities are increasingly using Slack, and many of them are also in the thousands of users. Slack does nothing to discourage this, aside from posting warnings about archiving messages.

The real problem is that they have an undocumented user limit. Like I said, I'm pretty sure we're the first community to hit this limit.

Big online courses, for example, routinely draw 100,000s of students, and might make the same mistake we did (Harvard's CS50 class did).

Slack may be able to fix its sluggishness for these other communities, and someone might build integrations that routinely export then delete messages so as to stay below the 10,000 message limit and remove the warnings. But it's too late for us. We can't pause our community growth while we wait for Slack to engineer around their undisclosed user limit. So we have no alternative but to switch.

The main reason I wrote this post is to provide a cautionary tale to other open-membership organizations who are considering using Slack. Slack doesn't seem to be intended to do this! Please don't do this!

This looks like a great value. We were considering using Campaign.js, but actually getting it up and running on a server to fire out campaigns seemed like a pain (as does using sendy). Combining the affordability of SES with some symbolance of the UX of mailchimp seems like a killer value proposition.

Hackathons are awesome. I try to do like 6 or 7 a year. And I'm married and in my mid 30s.

To take the OP's points one-by-one:

- Hackathons are worth the commitment. They're a fast, efficient way to try out 1) new frameworks and APIs, 2) new employees/cofounders, 3) new ideas.

- Hackathons only exclude people with "lives" who don't choose to make the event a priority. Hackathons filter out timid and less motivated people (and those two attributes are related) and you're generally left with pragmatic people who will make it through the weekend.

- The OP is right. The inconvenience isn't evenly distributed. Life isn't fair.

- Hackathons are only as unhealthy as you make them. Gardening can also be quite unhealthy if you don't wear sunscreen.

- Competition is a positive force, and the extrinsic motivation of judgement and a deadline are real, and good for the hack you produce.

- Since this is a competition, you can't work on a preexisting product any more than you could start a marathon a kilometers up the road.

- They're not just toys. Take a look at POWr.io and Zaarly, both of which came out of hackathons. There are many others, and if anyone knows of some of the top of their head, please reply with them.

I think it's great that people are coming together to help code on your gardening project. Hackathons may not be right for you, but they are definitely right for me and the dozens of ambitious people I've coded with at hackathons over the years.

The college experience for most Millenials can fit into 14 lines of JavaScript: https://twitter.com/freecodecamp/status/531824655573602304

I'm excited to hear about it. http://fourbeansoup.com/ has some cool-looking apps!

Down in San Francisco. http://www.downforeveryoneorjustme.com/facebook.com

This is an interesting approach. So the idea is basically amassing a bunch of people's subjective opinions about causality? Most of the ideas here are really high-level. Also, I tried to submit a "situation" without creating an account and got a 403 js error. You might want to hide that button for unauthenticated users.

This article is PR at its most effective. An established founder snaps up a fancy domain name and his PR team convinces a reporter that Quora has somehow failed. I've found no such consensus of Quora having failed as a business (http://www.quora.com/Has-Quora-as-a-business-failed), nor as an expert question and answer site.

Anyway, the problem with Fountain is you still have to ask a question. And if you can formulate a good question to begin with, Google (which is fast and free) might very well provide a better answer than some random domain expert willing to answer random questions for small amounts of money.

First of all, congratulations on the job!

We have a project-oriented full-stack JS curriculum at FreeCodeCamp, but if you're looking for a Rails curriculum, check out OdinProject. Erik's curated the best rails resources. And I agree 100% with what Malcolm Diggs said. Build, build, build!

I couldn't agree more. All we need is Craigslist style verticals (categories of work) and horizontals (cities) + identity verification + a reputation system. The overhead for that could be really low.

The $35k/year/worker support staff would seem to be the only capital-intensive aspect of the business.

O'Reilly is a specialized technical book publisher. Hatchette, on the other hand, is an undifferentiated conglomerate (one of the big 5 publishing companies). The types of people who would start their book search at O'Reilly are fairly well defined. That isn't the case with Hatchette. People on HatchetteStore.com are less likely to browse and more likely to search, and the second they fail to find a book they were looking for, they'd probably bounce back to Amazon.

I completely agree. I commute by running, and it's unsafe to look at a screen. So I frequently issue commands into my headphone mic like "read my texts" and "text <name> I'll be there in five" or "shuffle playlist 180 BPM". Many people dismiss Siri on account of mediocre answers to open ended questions, but it's quite effective at carrying out precise instructions.

Vision was one of the last senses to evolve in animals. And yet it's the most useful sense, significantly reducing our reliance on other senses. As a result, if I were to lose my vision, I might well be at a much larger disadvantage than if I'd never been able to see in the first place.

Instead of intentionally walking around blindfolded in preparation for a loss of vision that will hopefully never occur, I could thank my lucky stars that my eyes work and focus on using them to the fullest.

Other than Vim or Emacs (which I do mention in my post), which tools do you use? And which tools would you recommend for beginners?

Thanks for your feedback. I have no quantitative evidence to back up this statement so I will amend it. There are many reasons most developers (certainly in the Bay Area) prefer OSX to Windows or desktop Linux.

How would you feel about: "Macs combine the user-friendliness of Windows with the Unix environment necessary to run most tools and frameworks."

Do you do embedded/native development? Which tools do you use for that that aren't mentioned in the blog post?

Chinese is an international language, and an official language of several East and Southeast Asian countries, most of which use Mandarin syntax in their written form.

Probably because he outsourced it. He mentioned this as one of his takeaways - have developers in the same room with you.

My humble advice for this slide deck is: get to the demo. In this case, it's phonetically encoded coordinates. It's a cool idea, but requires adoption of a "majors system" like system for converting numbers into sounds. That's asking a lot!

The visual documentation is a nice touch (http://www.mealdays.com/howto/) and couldn't have taken too long to create. Just in case my mother-in-law doesn't know what drag and drop means.

According to my wife, she woke me up and kept shouting "earthquake!" I was rolling around on the bed. I just grabbed her pillow, covered my head and muttered, "OK. Let's go back to sleep".

How did you build the product that your first business sold without a technical person onboard? You coded it yourself. Thus, you have technical skills.

9 years later, when you were looking for a cofounder, you decided to go with a technical cofounder.

You can talk all you want, but at the end of the day, you chose to bring on a second technical cofounder (the first being yourself) over the business cofounder that you are recommending the OP seek out.

N.b. by technical cofounder, I don't necessarily mean someone with a PhD in Computer Vision. I mean someone who can productively write API integrations and use whatever tools are needed (e.g. Rails, Meteor, Xcode) to build the product.

Rather than dismissing my cofounder as terrible, I encourage you to consider the possibility that advice like yours, which we followed in cofounding the company, set him up for failure.

Having specialization early on was a mistake. It was a difficult situation, and it wasn't entirely his fault that there was, for long stretches of time, little for him to do.

A startup cycle goes something like this: initial theory -> MVP -> validation of theory using MVP -> iterating to product-market fit -> scale

Even in that highly oversimplified flow, there are a lot of shifts from "product mode" to "development mode". Most of these steps must happen sequentially. If only half of the team is fully engaged in any given step, you get a lot of slack.

There's a joke that first startups should hire a bunch of developers to build the product. Then they should fire the developers and hire a bunch of salespeople to sell the product.

Which begs the question - why not just hire developers who can sell, and avoid paying all that unemployment?

Larger organizations can get away with having specialists onboard. Smaller organizations (2-3 people) can't afford this luxury.

Your advice would hold for a later stage startup, but it is unreasonable advice for an early stage startup.

As an aside, the best co-founder relationships are formed on complimentary skill sets. You can do what they can't (or struggle with), and vice versa. As such, I would encourage you to find a sales person/designer/hustler, as opposed to another developer.

On the face of it, this advice seems reasonable. But this advice will result in precisely the asymmetry to OP is worried about. If you have a technology product, I strongly discourage you from taking on a non-technical cofounder.

I made a huge mistake co-founding a company with someone whom I thought had a skill set that would compliment mine. He was, of course, a non-technical. While I coded for 90 hours a week trying to build an MVP, he did thought experiments, worried about competitors, and fretted about the color of our logo. In short, he did very little to move the product forward other than arbitrarily tweaking design specifications (before we had MVP and were even able to A/B test or validate with users). It was an extremely counterproductive and demoralizing experience.

This may sound like an edge case, but I meet people all the time whose startups failed because the team couldn't get along. This is usually caused by one person feeling like they're doing all the work. And that's usually because one person IS doing all the work - the other person is a non-technical cofounder, and can't do much meaningful work, only look busy by trying to get twitter followers, having lunch meetings with reporters, and doing competitor analysis - all work that is meaningless if you don't have an MVP you can use to validate and iterate toward product-market fit.

My advice is simple: find a technical cofounder who also has the confidence to pitch. Find a technical cofounder who can help validate an MVP and iterate it to product-market fit. Find a technical cofounder who isn't daunted by needing to pick up new skills. This is a startup. You're looking for generalists, not specialists. Whether someone can code is a good litmus test for whether they are serious about doing tech startups, or merely dabbling.

This is awesome. Less than a minute to create this: https://www.gifyoutube.com/gif/kWm

It's one thing to hyperlink words to affiliate links in their text, but it's completely different to force all their readers to read over "Buy it now" while they're trying to read the article. Talk about interrupting the flow of the article!

Also, how would you feel as a journalist if the investigative piece you'd spent the last three weeks on was ultimately riddled with "buy it now"s?

I imagine the costs of trials, and who paid them, are well documented. In the event of a dispute about which company discovered which drug, could a company not point to its investment in research or funding of a specific trial as evidence of its discovery, rather than trying to spam system with provisional patent applications? (By the way, there's no such thing as a "provisional patent" http://en.wikipedia.org/wiki/Provisional_patent#cite_note-1)

The simplest solution would be to significantly shorten the patent duration for pharmaceuticals, and start it the day a drug gets FDA approval. This would uncouple two things that should have never been coupled in the first place: development time and window of exclusivity in the market.

Based on the criteria you mention (infrastructure, capital markets, regulation and market size), there most certainly isn't one. The other large countries have more onerous regulations and worse infrastructure than the US does.

But it's clearly not enough to say "the US isn't as bad as everywhere else" if everywhere else is merely drifting toward consolidation more slowly.