I really like what you are doing, but after seeing what happened to RailsCasts I am a worried what will happen to this business model once it hits 400+ episodes. Hopefully your "other plans" have this part worked out?
I assume the screencast has a limited shelf life, so yes, my "other plans" are about that. Although at this point, I think the problem is more about organizing the content so it's not overwhelming. I'm not worried about running out of material or burning out, at least not for a while.
At this stage it cannot "fail" in the traditional sense. Even if it enters a downward spiral, at any point in time it could be sold for the user base alone (and the price would still likely to be bigger than Heroku)
Blockbuster has nothing to do with this. That was a failure in the traditional sense. I never argued that somebody is "too big to fail". The parent poster argued that if Dropbox failed, it would not be a big homerun. What I argued is that even if Dropbox valuation failed by say, 90% and it got sold, it would still net around 500MM. That would be a failure for the latest investors, but definitely still a heck of a success for YC (I am disregarding purposedly here liquidation preferences, etc, but you get the idea)
iCloud is basically just for syncing your contacts that you manually created. We actually use iCloud to make syncing everywhere possible.
For example, if a person changes their phone number, that gets pushed to Everyme, which then is pushed to iCloud. As such, all of your devices now have the up-to-date info.
You'll be doing all the work up front and then all the work maintaining and improving.
You're also not a flight risk as it sounds like you're in it for the long haul.
They also sound like they're not convinced, which means they either haven't though it through or they're not worth the risk.
Good luck with the decision. I would vote a no for them as it sounds like you deserve better and if you keep looking, you'll find some cofounders worth taking the startup risk with.
The following are some of the main misconceptions of what's floating around between the blog, TC comments and HN comments.
Misconception 1: answering programming questions tells if the developer is awesome
No it doesn't. When an interviewer asks you a programming language-specific question, they are wanting to know how awesome you are at the language to see if you can hit the ground running on your first day. These sorts of questions only tell you one thing though, that the person you are interviewing has spent a lot of hours in front of the one programming language. I personally do not rate these types of questions for an interview because anyone can learn syntax, data structures and best ways to implement language-dependent code.
Misconception 2: brain-teasers don't tell you anything
This couldn't be more wrong... The reasons why an interviewer throws you a brain teaser or design question is to understand your thought logic and problem solving skills. While you talk through how you would solve your problem, they are assessing your communication skills, your process in solving a problem and also what knowledge you have as part of your experience.
Misconception 3: degrees don't tell anything
There is a lot of "show us your projects" being thrown around. While this is a fair call, one should not dismiss the degree. Simply being, that the degree is a project. It means that the candidate has had to spend three to five years juggling multiple subjects (read as 'projects'), while working part-time (read as 'projects') and managing their social life (read as 'drinking beer' and 'tuning hot people'). A degree is a testament of the students ability to see something through from start to finish... it's an example of their dedication.
Misconception 4: degrees aren't teaching students how to
code, so how are they expected to code
Again, this is a fallacy. The degree is teaching students how to collaborate through group projects. How to work unsupervised and be resourceful while working unsupervised. It teaches the fundamentals so they can pick up any programming language (just another tool) and apply the fundamentals they have been taught.
I strongly agree with @marcamillion's statement about "developers being better over time". This is why I disagree with Misconception 1, as all this is doing is showing how much experience the interviewer has with the language they are quizzing someone on.
Overall, give the new coder a break. They most likely got hired because they:
- fit into the work culture
- possess strong problem solving abilities
- can work unsupervised
- can work within a team environment
- have imagination
And if the new guy is asking you a question, it's because they're wanting to learn, so respect that as they're trying to be awesome like you.
Disclaimer: Sometimes people make mistakes though, and a dud ends up being 'that' coder that can't code ;)
Misconception 2: brain-teasers don't tell you anything
This couldn't be more wrong... The reasons why an interviewer throws you
a brain teaser or design question is to understand your thought logic
and problem solving skills. While you talk through how you would solve
your problem, they are assessing your communication skills, your process
in solving a problem and also what knowledge you have as part of your
experience.
The problem here is that a lot of the brain-teasers I've seen bandied about for interviews are the kind of problems where you either get them via an a-ha insight, or you don't get them at all. That's kind of what makes them good brain-teasers.
Yeah, I've never really understood how you can "talk through your thought process" for a question like "Why is a man-hole cover round?" It seems like you'd either come up with a reason or you wouldn't be able to come up with anything at all.
Perhaps you can say things like "Well, let's see...you need to be able to pick the man-hole cover up out of it's hole, then put it down somewhere, then maybe move it, ..." but I really think these types of ramblings are just stalling for time rather than an actual English narration of what I believe is an inexplicable thought process that would go into coming up with an actual answer to such a question.
1: I want to see if someone knows language foo, and I want to know that they can implement algorithms and data structures. In short I want to see that they've spent a lot of hours on this platform.
Of course anyone with the hacker nature can learn any language, but that doesn't mean I want them to learn it on the clock. When I want an electrician I call an electrician, not a smart friend who I think can learn it.
2: I don't ask brain teasers because someone who has heard the question before has a tremendous advantage over someone who has not. That's not what I want to test for.
RE: 3 and 4, I don't much care as long as they pass #1.
At my first professional job, the director of the company was a pathologist for 20 years. It then occurred to him that his industry could be run more efficiently so he embarked on developing his own pathology system. With no previous software background, he had his wife bootstrap his development of the system for a few years before he was able to implement it for production use. He ended up running his new software company for 12 years before he sold it for millions!
He is a prime example of someone with no software experience moving into the industry. However, I believe it worked wonderfully for him because he didn't shift from his primary industry where he held all of his domain knowledge.
Congrats if you're wanting to shift professions and industries as it is a brave move. I would suggest surrounding yourself with talented and experienced people in the software industry. There should be Ruby on Rails and web meetups in your area where you will be able to network and learn from approachable people.
Thanks for the encouragement! I have a few friends in web development and they're huge inspirations and great mentors. I feels incredibly lucky to be entering the field when I am because the communities and tools are absolutely amazing.
Like the pathologist the big thing is to feel the pain well enough to know how to fix the problem that causes the pain. Don't go too far away from what you know at first.
How is heroku doing these days:
Recently acquired by Salesforce and expanding their add-on range means that they will be around for a long time and it is promising that they are catering to a larger variety of developers.
Reliability:
They run off Amazon web services which are continually expanding their regions. So they are highly reliable (especially after the EC2 outage in 2010).
Cost:
In my experience, heroku has saved me a lot of time and my clients a lot of money. Yes, I can setup and manage my own servers and it can be for as little at $10/month. heroku on the other hand costs up to $100/month for my production servers. Why am I willing to pay this much? Because I put a higher price on my time than $100/month. I don't have to worry about infrastructure or redundancy issues. Furthermore, my clients can afford these hosting costs as I explain to them that $100/month is cheaper than my hourly rate if I have to troubleshoot network/server issues and also perform server maintenance... which none of these I have to do on heroku.
Limitations & hiccups:
I've found that I've needed to employ alternative ways of doing things due to some minor heroku limitations. Overall, everything is achievable with some resourcefulness and some extra money.
Overall, heroku is easy to get started with, especially if you've got sys admin experience! Hope this helps and good luck with your job interview!
