I've been developing software for a long time. I'm saying this as a someone who has been a technical cofounder and watched the CEO judge me without being a coder himself. I was very surprised at how effective he was at doing that.
Btw, there is a giant flaw in your logic. You assumed I couldn't judge a programmer, but you then assumed I would successfully judge a technical cofounder.
I have also been developing software for a long time. What I learned at digg is that technical debt matters more, and becomes more of an immediate problem, if you grow insanely. If you have a 100 sympathetic people using your app, it doesn't really matter if there's a few rough edges in it. If you go from 100 sympathetic people to a million or so in six months, you go from "work on it as you can" to "we will be screwed if its not fixed immediately."
Even more so, if you end up being an acquisition target for companies like Google and Yahoo (who want to read your code), then it becomes "this will cost us hundreds of millions of dollars this week if its not fixed now."
This is a bit of a tangent from the original issue which was about the ability of a non programmer to judge programmers. I still hold that the good ones can, and if they cant then how do you propose they pick their technical cofounder?
Regarding technical debt, I think we're conflating a few things under this umbrella. There can be code that is easy to read and maintain, but won't scale to millions of users. Then there is spaghetti code which is brittle, hard to read and modify, but may or may not scale. I think it's ok to have the first before you know if you need to scale.
When you guys got to the point that you realized it needed to scale was it fixed immediately? If not, would it have been that hard to fix it then.
Btw, thank you for talking about this stuff. It's great to hear insights from someone that's been through such things.
One of the things I learned is that readability is a key part of scalability. One or two programmers can figure it out, but when you get to 20 or 30, if the code isn't clear, it costs time and money. Clever hacks need to go by the wayside, in favor of clear code.
As the saying goes "Always assume that the next guy to maintain your code is a psychopath who knows your address."
That is not something I knew in the early days of digg. I know it now.
What I find objectionable about the video is not his identification of team quality being the problem. It's his total abandonment of responsibility for it as a founder. That he'd say he just woke up one day surrounded by B and C players he hadn't interviewed makes it seem like everyone else was running amok and he is not to blame. Trashing the reputations of his ex-employees in order to save face on a tech show is irresponsible at best, and at worst a demonstration that he is unfit to lead a team of any size.
Amen. Note that the reason Kevin was too busy to interview everyone is that he was busy doing side projects. In my opinion if you want to know what was wrong with digg, I'd start with
Especially since in the period he talks about digg was somewhere between 30 - 75 employees. He speaks as if they had hundreds or thousands of employees, but having only ~50 employees and claiming that you don't know half of them is either completely not credible, or if you accept it as true, a huge abrogation of responsibility and personal indictment of his own behavior.
My completely uninformed assumption is that for an attention seeker like Rose, running around and doing things that get you more attention is probably a lot more fun and rewarding than the nitty, gritty details of managing a business.
The most telling part is he doesn't even have enough sense to recognize that blaming "them" only makes him look bad. I'll bet though there are plenty of "Bubble Boys" who just can't wait to lose money on his next venture.
