Seems this video came off the wrong way - I didn't mean to throw anyone under the bus, but rather highlight mistakes I wish not to repeat. As the founder I am accountable.
A few things I've learned over the years:
- Realize you're only as good as the people you hire.
- As a non-coding founder, it's important you perform deep reference checks and have a trusted senior developer review code samples prior to hiring. (We rewrote ALL of our early code base because we didn't take this step)
- Make time to interview every potential hire and vet them with proven experts.
- Ensure employees are a good cultural fit.
- If someone is doing a poor job, step-up and fire them.
- Look for employees that are up for the technical challenges. I remember several occasions when the answer was "MySQL can't do that" vs "we can do that, just not in MySQL".
Sometimes, Kevin, a technical master will realise the limitations of the tool, and not always suggest it as a solution for a problem that clearly calls for something else.
Of course, that's over-simplifying things. Sometimes you asked for things that were physically impossible. When you need 1Bn operations to complete a task, you can't do that with 1M worth of resources, no matter if you try to use MySQL, Cassandra, or text files to get that result. You see, some of us at Digg actually had real computer science degrees, where we learned algorithm worst-case complexity, and we understood you were asking too much of too few computers. And if you think back hard enough, you'll remember the answer was actually: "MySQL can't do that unless you get 10x more computers."
Thanks for talking about your dissatisfaction with the theoretical limits of computing here, in this forum, where I had to find out about it third-hand, instead of actually talking to me face-to-face back when it could have made a difference.
Can you explain why Digg decided to switch from a known good backend (e.g. MySQL) to an unproven NoSQL solution? What was the thinking behind that? Was it a unanimous decision?
If you're a non-coding founder your #2 should be your CTO. No one else is more important to getting your business up and running. Trust them with what you yourself don't know.
A few things I've learned over the years:
- Realize you're only as good as the people you hire.
- As a non-coding founder, it's important you perform deep reference checks and have a trusted senior developer review code samples prior to hiring. (We rewrote ALL of our early code base because we didn't take this step)
- Make time to interview every potential hire and vet them with proven experts.
- Ensure employees are a good cultural fit.
- If someone is doing a poor job, step-up and fire them.
- Look for employees that are up for the technical challenges. I remember several occasions when the answer was "MySQL can't do that" vs "we can do that, just not in MySQL".