Also really shitty programmers, when confronted with better ones, often do lots of crappy shit to sabotage the process and cause infighting. I did little if any of that (probably because I had significant equity). I stayed in the background, learned as much as I could, and contributed as much as I could.
I don't think Kevin learned anything there.
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.
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.
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.
[1] http://www.deserettechnology.com/journal/reddit-the-open-sou...
There is a diagram explaining this in the mythical man month, but I don't have my copy handy to give a reference.
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.
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)
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.
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.
However, consider the reverse, is there anybody who is consistently good at picking good developers? Is there any interview process that consistently works? If so, I am not aware of it. Hence I don't consider the hiring process to be 'solved'.
I can see the reasons behind Joel Spolsky's "make sure they write code during the interview" mantra, but you look at some of the other stuff he wants and it's all pointless pointer twiddling. Then he went and broke all the rules anyway by working with Jeff Atwood who by his own admission wouldn't know a C pointer if it bit him in the face.
It makes me wonder, how do they do it in other professions? E.g. is there a process by which you can weed out the good Civil Engineers from the bad ones? Or good Lawyers (leaving aside the obvious and droll joke), or good Doctors? What about a people oriented profession like Priest? Surely they would be able to weed out the good from the bad.
But no, it turns out that for Doctors and Priests we're always getting bad ones in the news (Doctor's lying about their qualifications, practicising without a licence etc).
Okay then, the 'fluffy' professions haven't got this sussed, what about the technical ones?
Yes, this the process of licensing. In those professions you mentioned, all people who (legally) work in the field must undergo a process of training and subsequent certification. This includes both work experience and exam requirements over the course of several years prior to certification. Yes, there are people that cheat the system, but the licensing exists to weed them out and protect the consumer.
Software "engineers" undergo no such process or requirements. I can learn ruby in my basement in a year, call myself a software engineer, and get hired building any number of apps. Is my work critical enough that someone may die if I am not certified? Usually not, so the need for certification isn't as strong. Nor have we had the time to develop such continuously relevant certifications in a field that changes several times a year.
I recall a story about a flight instructor who said to a freshly licensed pilot something like, "Now you've got your license to go out and really learn how to fly".
The point is that true competence and most certainly brilliance requires individually driven effort and expertise that is unlikely ever to be measured by government or professional organization administered exams.
Put it another way: Do you feel that licensing assures us that all drivers on the road are "good"?
(Sorry if my argument sounds abrasive; the subject's a pet peeve of mine.)
And getting a pilot's license is a little bit different from being licensed to practice medicine. It also depends on whether you're referring to a private or commercial pilot. Private pilots only need 40 hours[1] of time in the air. And even once a commercial pilot is licensed, there are other regulations in place. And a driver's license is an even lower bar, of course.
So no, licensing (in any form) does not ensure that the licensee is "good" or "brilliant," but it does allow us to ensure a minimum bar that does not currently exist in the software industry today.
(And no worries, it's a pet peeve of mine as well. At least at it relates to the software industry.)
1. http://en.wikipedia.org/wiki/Pilot_certification_in_the_Unit...
The historical pattern in the US seems to be that professional licensing, introduced as protection from incompetency, inevitably evolves into a way of limiting competition in a field by restricting the number of practitioners. At least on architectural exams, to the best of my knowledge, the maximum number of those who "pass" each year is set in advance.
It's a slippery slope once you start regulating entry into a field. The regulating body comes under political pressure from anyone with a financial stake, especially practitioners, educators, and major consumers. I'd wager that soon after you need a license to call yourself a software engineer, you'll need an accredited degree and years of internships before you can sit for the licensing exam. It's played out in similar fashion in the other professions.
There are other ways of ensuring competency without the use of government or quasi-government institutions. In software development, incompetency generally wastes time and money, not lives. With stakes this low, perhaps something as simple as a standardized testing service that could be used by HR departments to screen applicants would be viable... (Please pardon my designer's ignorance if something like this already exists in the development world :)
The only people who know who are the good devs are the other devs who have worked with those devs. Reputation outside of the dev circle is largely orthogonal to dev ability, and rather closely tied to social skills e.g. schmoosing the managers.
I was talking to an older guy the other week, he didn't seem particularly "switched on". Turns out he makes well over twice what I do, because he predates COBOL, the people that he works for a terrified he'll leave/get hit by a bus etc and nobody will have the skills and knowledge to maintain the systems their business runs on, because all his compatriots got wiped out by an asteroid.
I wouldn't say he was bad at his job. If I was to guess I'd say he was 'okay' at his job, but he didn't seem to have that spark that I associate with greatness. But as his take home packet proves, sometimes 'good enough' is great too :D
I know people who themselves cannot program but know what the hell loops are and stuff that you learn when you open a basic programming books. The stuff that tells you what the hell complexity of a program. If I were to tell them write a simple for loop they would not end up doing it, but when the programmers tell them that some task is taking time, they break down each task so logically that they would make a damn great programmer themselves.
Every reason is analysed and possible directions put infront of the developers. If they say the servers we are using are not fast enough, they are quick to ask back, if it is the code or the servers themselves, since they know of people who are doing just fine using the same servers.
Another great thing in a company is that there will always be smarter developers who will do the same task effectively and faster. Then of course it becomes quite evident if the other guy was at fault or had a genuine issue.
Why then is it so hard to view managing people in the same light?
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.
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."
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.
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.