Well, you obviously have more insight in to the early days of digg than I do, but you're basically proving his point. You say you had significant equity but wrote bad code. That's not a very good formula.

I disagree. Every programmer I know thinks the code they wrote 5 years ago is bad because they've learned a lot in the years since writing it. The site worked and and worked well, even if the underlying code wasn't as elegant as it could have been. So many sites go through this pain, just look at twitter with their rewrites of job queues and what not.

Agreed. Look at reddit's current codebase. It's such a mess that the OSS platform is all but worthless. [1] Nevertheless, it's handled the incredible demands placed upon it with something approximating success. When your team is too strapped for time to refactor the code that's causing problems, and instead builds hacks upon hacks in an effort to keep the site up, it's a testament to their ingenuity if it's still running years later with millions more customers.

[1] http://www.deserettechnology.com/journal/reddit-the-open-sou...

Reddit is a weird example. Making a code base a platform requires time and effort to be spent on ... Well making it ready to be a platform. There are a lot of things you don't need to do if your code is limited to your team and it's internal processes.

There is a diagram explaining this in the mythical man month, but I don't have my copy handy to give a reference.

Except that reddit's in the odd position of having released their codebase as a platform, without having been able to put the requisite time into making it suitable as such.

I watched a documentary a few weeks ago (damned if I can remember what it's called) about Netscape's transition to Mozilla. The amount of effort that went into that transition was staggering. For his part, Jedberg said [1] that preparing and maintaing redditOSS will likely be one of the first projects for their new hires, as it will make development and maintenance on their current codebase that much easier.

[1] http://news.ycombinator.com/item?id=2345247

Code rush perhaps?

That documentry also reaffirmed my commitment to not do pure sitting-at-desk software development. Because my god netscape looked like a horrible place to be, no matter how many smart people you had around you. (These days facebook looks similar, but worse not even cubicles for privacy)

Yup, that was the one, thanks. I'm a bit torn as to the work environment: On the one hand, I'd hate to be a cubicle jockey for a large corporation. On the other, the engineers at netscape seemed to be buoyed by being surrounded by many capable nerds. It's that dichotomy that makes me, on the one hand, want to work for Google, and fear doing so on the other.

You've either stopped learning or stopped advancing professionally if you don't hate the code you wrote 5 years ago.

I dunno...I think the code I wrote even 10 years ago was pretty good - for the problem it was solving. The thing is, I can solve much harder problems now. The code I wrote 3 months ago, solving the problem I have now, is the real shitty stuff.

You can expand inwards and look at how to improve your solutions to existing problems, or you can expand outwards and solve new and harder problems. I highly recommend the former when you're just starting out, because it builds your basic skills and gives you a solid foundation. But eventually you have to stop polishing turds and start hunting for gemstones. There's a limit to what you can accomplish if you solve the same problems over and over again.

Everyone makes mistakes in the early days of startups and digg was no exception.

If you're here, you've probably heard that Ycombinator favors determination over talent. I kept the site up and made things work with extremely limited resources.

I'll second this. Owen's code was bad, because it was a large hack. It was a hack that worked. It was a hack because he had limited resources. He was ONE GUY coding, administering, doing everything up until something like 8 million users. That's not easy. The code was bad. So fucking what. It worked.

So with that, I say Owen is a good coder.

Kevin never understood tech. As Owen says, he's just a guy who looks good on TV. Now he's throwing all his good coders under the bus because he fucked Digg up with his grand V4 vision, and he's trying to point the blame at others besides himself.

"It's a low move, Kevin. Low move. We supported you. We took the blame when we fucked up. We never pointed the finger at you. So take the blame when you fuck up. Asshole."

Sincerely, The guy who kept DBs running for Digg for 4 years.

I'm not sure if you've done so already, but an AMA on reddit would be really neat if you're interested in talking about the early digg days.

>an AMA on reddit would be really neat

Sadly I can't see this going well. Reddit generally makes a big joke of how much Digg [supposedly] sucks. I don't think it would be generally a fulfilling experience for the AMA subject or most onlookers. YMMV.

Some of the best programmers I've worked with will say that the code they wrote a few years ago is bad code... I don't think it's a sign that ojbyrne is a bad developer or that he actually wrote bad code, on the contrary the worse developers are often the ones who are convinced that they are good.

See the http://en.wikipedia.org/wiki/Dunning–Kruger_effect

Thanks. Now that you mention it, digg spy circa 2005 was a thing of beauty. Concept by Kevin, Design by Daniel Burka, making it all work by me.

I think that statement is upon reflection. Everyone looks back at previous code and thinks they could have written it better. That is just the progression of a developer.

I'd be interested in hearing how the C & D developers were managed more than the fact that some developers had less skill/experience than others. On a project to build a platform like digg, it seems like some extremely significant foresight in software engineering would be needed to give all developers tasks which are both suited to their talent and will be appreciated as important work.

I wouldn't dare make excuses for a developer sabotaging work, but there are some bad situations many developers can be put into which are more likely to produce lazy and shoddy output.