Seems pretty reasonable to me. It might not have been what everyone wanted to hear, but the truth of the matter is that there are a lot more mediocre developers out there than outstanding ones, and if you're not careful with your hiring, you'll wind up with a lot more of the former than the latter.
It seems Kevin wasn't blaming any problems on his team, but rather on their lack of attention in selecting that team. Whether he's able to select better will soon be seen, but I take his comment as more of a mea culpa than anything.
I've got a fairly extensive background in software development and management and the most striking thing at digg was there was no attempt at what's colloquially known as "management," at least up until 2007 when I left.
There was no such thing as a performance evaluation.
The founder and CEO mostly worked on side projects or spent time "taking money off the table."
There were lots of parties and social events.
They could have evaluated mediocre developers, put them on performance improvement plans, and if they failed to improve, fire them. They were too busy.
In the podcast, I didn't hear any mention of what I'm talking about. I heard "we hired too many B and C people."
I'm doubtful of the idea that performance evaluations and performance improvement plans are the answer to lack of management, but only because the way I've seen them implemented so far. They seem to be used mainly as threats from management or as a CYA step to firing someone rather than serving the needs of the people subjected to them.
I interviewed with Digg in the early days (not sure you remember me but with you Owen)
I think while finding big successes can be hard, dealing with them once you have them can be even harder.
Kevin was pretty quick to realize that Twitter/Facebook were going to eat Digg's chances of become a huge company, but it wasn't trivial to figure a response to that. It's a valid question: should Digg have even tried to grow grow grow or just been happy owning their area?
Engineering gripes I think were mostly focused on acquisition and investment attractiveness. There probably is also some elitism in the Valley: if you don't have the right pedigree and look the way that fits what people expect you don't deserve success
No offense, but Kevin wouldn't know a good coder from a bad coder if his life depended on it. He can't read code, is essentially innumerate, and mostly just plays a techie on TV. To be blunt, he's blaming just about everybody else but himself. A college dropout who couldn't write a line of code to save his life talking about "B and C" players is offensive.
I should add, though, that I know the original code I wrote for digg was not very good. But I learned a lot there, especially from the first 2 developers and the dba we hired at digg after me, and I think its a mark of a decent programmer that they're humble and willing to learn. I think the code I write now is better because of the lessons I learned there.
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.
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.  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.
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  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)
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.
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.
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."
The guy who kept DBs running for Digg for 4 years.
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.
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.
I had that same though pop into my head. Right after claiming that Digg hired a lot of "B" and "C" coders, he says that he's handpicking everyone who is working on his new project. I don't see how that will prevent the same issue from occurring.
I agree. And massive raspberries in Mr Rose's general direction.
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?
"is there a process by which you can weed out the good Civil Engineers from the bad 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.
Au contraire, licensing does nothing of the sort. It's most always a system that both guarantees a certain minimal level of competence, and by design limits the number of professionals in a field for various political reasons. There are plenty of licensed but only marginally competent (i.e. bad) architects, engineers, doctors, lawyers, and other professionals.
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.)
But it does ensure a minimum bar for those licensed to practice professionally. So, theoretically (heh), even the worst licensed MD/architect/etc has met the minimum requirements for practicing. I'm not saying they can build an 80-story skyscraper, but in software we have no such means by which to measure potential practitioners.
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 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.)
Right. What all these different examples of licensing do is provide some level of protection from complete technical incompetence. Which of course is a worthy pursuit, I just don't agree that the best way to do it is necessarily by licensing. (And unfortunately I'm not going to be able to precisely articulate some alternatives at 3am :)
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 :)
I'd guess most software "engineers" do actually pass such a process. Its called a BSCS. The problem is that the state of the art evolves so rapidly, and the difference between state of the art and good enough 10 years ago isn't that costly in most cases, so there is no real test for that difference.
"most" being the key qualifier there. And there's no requirement that they do, so no means by which to qualify them. Some of the best never do go through that process simply because the state of the art is advancing so fast. I'm not sure any regulatory body could develop a standard and keep it adequately up to date.
I've been a hiring manager or principle interviewer for a number of companies. I've found that, unfortunately, certifications (at least in the java/enterprisy world) are almost always negatively correlated with competence.
I completely agree with this statement. In the software industry (and other tech industries like InfoSec), these type of certifications are fluff that anybody willing to spend a few hours studying a book can pass.
I don't know what dropping out of college has to do with it. Inside a company, the developers know who's amazing and who isn't. In my experience you can know varying skill levels based on what everyone else thinks, sort of like reputation pagerank.
I don't really think it's offensive, looks like people here are just trying to get attention. You don't need to be a great coder to know that your developers aren't that good. He accepts making a mistake, and really, talking about this issue is beneficial for other companies that will try to prevent this. So it's rather helpful.
I've been developing software for a long time and know what technical debt is. I've seen CEOs with no coding experience effectively judge programmers. I was surprised the first time I saw it, but trust me the good ones can do it.
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.
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.
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.
Are you referring to computer engineers, or other kinds of engineers? (Electrical, Mechanical, Civil etc)
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
So from my perspective (having no internal knowledge) while Digg may have had its downtime, there's no technical reason why it's failing right now. Digg's biggest failures seem to be 1. it doesn't make enough money and 2. its product re-launch was a failure of epic proportions.
Blaming this on the B&C level programming talent is a bullshit way to deflect mistakes he made.
I completely agree. I see this sort of 'shotgun hiring' all the time. It is very difficult to hire a lot of very good developers in a short amount of time. Sorry to say it, but there are an ever increasing amount of awful coders out there. I really do mean awful. Kevin is just telling it like he saw it. I am sure the good devs over at Digg would say the same thing.
The shotgun can work. Put them to work as interns, then mentally review their performance at the 2 week, 4 week, 2 month and 3 month anniversaries.
If at any point you find that they are significantly underperforming, go and find out why. E.g. maybe for the first 3 weeks they were on database stuff, which they love, but they've been reassigned to UI which they hate. Maybe their dog died.
If they underperform at any two of the reviews stages, get rid of them. If they are bad for morale, get rid of them. A great coder that is an energy vampire for your good coders is a net loss.
One place I worked we had a guy who was supposed to be a good programmer. The first week there he was really depressed about Michael Jackson's death. I tried to cheer him up and he perked up for a couple of days in the second week. Then in the third week I discovered he was actively looking for work elsewhere (and telling other devs about it). I pulled him aside and told him to pull his head in. He came right for a while but the next week he was down again. He broke the build every second day, and nobody ever chastised him for it (there might have been some playful ribbing along the lines of 'you broke it, you bought it') but the one time I broke the build he lost his shit and started screaming at me, telling me (in front of managers) that I was incompetent. He had epic mood swings, when he was up he could be the most charming guy in the world, when he was down he was evil up to and including physically attacking and bullying other devs (but never in front of the managers).
And actually, I was careful not to call them performance reviews.
Performance reviews are horrible, and consist of all sorts of minefields and HR BS. E.g. rate yourself from 1 to 5 in these areas, but nobody gets a 5.
When I said mentally review their performance, I meant mentally ask yourself if the person is up to scratch. E.g. is their actual performance good. Now, most managers wouldn't be able to tell you this, so this shouldn't be something that is done by a manager. It should be done by a senior dev who has some kind of knowledge of the area the 'intern' is working in.
Alternately, you could have a tribal council of say three senior devs, and they vote at the 2w,4w,2m,3m periods. Anybody that gets too many downvotes gets to leave the island :D
But note also that if somebody is temporarily under-performing then you need to find out why and fix it (Note: not the same as 'fix them').
The goal is to as fast as possible identify the people who are consistently underperforming, or show enough signs of flakiness, so that you can utilise the built in 'thank you for playing, you are the weakest link, goodbye' clause built in to most contracts.
To be fair, I'm assuming that the percentage of terrible developers is constant, it's just that A: You're hiring more of them, and B: More people are being terrible web developers rather then terrible desktop application developers.
That doesn't seem like a legit assumption though. Combine the sensationalization of tech media with ever-lower barriers to entry for web and mobile development, and it seems almost impossible that there wouldn't be significantly more terrible developers than ever before.
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.
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.
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".
I don't think this applies to a startup environment or anywhere the company size is less than, say, fifty people, assuming 10-20% of them are developers. If you try to build something new with B or C players, you may not have a chance.
That said, once the company grows, there are places where a B or C player in one role could be an A player in another role, and vice versa. I think specifically about people who are promoted to their level of incompetence based on excellent performance and become miserable managers who make everyone around them miserable as well.
The important thing in that situation is to respond decisively and either support the person and train them to be competent, or respectfully return them to the level where they can excel.
Classy, nothing like an exec who blames the hires that came onboard under his watch for his failures. Here is a hint for the next time Rose, you were building a web site, not the space shuttle, you don't need 40 "rockstar" developers, hire fewer people and work slower.
A "C" coder is someone who writes bad code. It's relatively easy to detect and fire a "C" coder.
A "B" coder is one who for the most part writes good code, but doesn't design a good long-term architecture, or makes many small mistakes that add up in the long run, or leaves the code riddled with small bugs that eventually cause frequent problems. The "B" coders are the dangerous ones because really you should fire them or fix them, but it's too easy to ignore them.
An "A" coder writes solid code and is dependable, but doesn't hit the high notes, as Joel Spolsky says.
A star coder is an "A" coder who hits the high notes.
(I don't know what a "D" coder is, but perhaps our scales are offset by one letter grade.)
A "D" coder is outsourcing. or code that is bad, runs slowly, has bugs and is often incomplete. Oftentimes things are written in one heroic coding session and simply cannot be touched after that. BUT it meets the "specs".
ooowww I've seen some of that.
An "A" coder's code is simple to spot: It's boring. There's nothing heroic or clever (that's hard to debug) it's well documented so even junior devs can understand it, and thought has been taken so that it can be extended in the future. To put it simply it shows taste*. That is a rare thing indeed.
I've built many large and small engineering teams. One of the most important lessons I've learned is "A players hire A players. B players hire C players. C players hire D players." It is a fact.
Sometimes you can't avoid hiring B players. But if you do (either by mistake or because you explicitly decided to) you need to be disciplined about either turning them in a A players or ensuring they are not responsible for hiring. If you find you have C or D players get them to move on IMMEDIATELY.
Kevin says something here that is really important, and I think it is part of the lesson he's learned: "It was really hard to get rid of the C & D guys".
This is why I now try to work on the principle that I am far better off not hiring someone than compromising on quality. I have learned the hard way (multiple times) if I don't live by this principle, I WILL pay later.
On (A) first, not everyone works in California (I don't). Second: "inertia". People get attached to people. People are afraid to rip the band-aid. People think "Oh, this is a critical time so we CAN'T fire him/her now! We'll do it later."
"You just fire them" is the right ATTITUDE, but in practice it's rarely so simple.
Related to all this is another lesson I've learned: In almost all cases when it comes to removing people from jobs, or re-organizing teams, it should be done quickly and decisively. Rip the band-aid! As a leader, you are far better off dealing with a mess that exists ON YOUR TERMs than one that exists on other's terms.
This, of course, assumes you have a set of core principles you both believe in and live by. But that's a whole 'nother diatribe.
It's partly a selfish, rational decision. In the borked world of corporate politics, firing someone on your team can reflect badly on you, or reduce your personal power (the size of your bonus pool is often related to headcount). Do you want your boss asking: "Why did you hire them in the first place?" "Why couldn't you just train them?" etc.
It seems fine to me. I regularly interview people with CS degrees (some of every kind!) who couldn't code their way out of a paper bag. If we didn't spend a huge amount of time interviewing people compared to the number of people we extend offers to, we would be hiring "B and C grade developers" too.
That's a clip from the latest episode of "This Week in Tech", http://twit.tv/293 . You can get audio as well as high- and low-def video downloads from there. The clip seems to be from 34:10 into the show.
Who said I was contesting anything? I was agreeing. Well, not agreeing with mocking anyone, but rather praising the Dropbox folks for not trying to make Dropbox work under these circumstances. Trying to make Dropbox do something it wasn't designed to do is hacking. If it doesn't work, fine, I would never mock someone for trying to hack something.
Replies need not be antagonistic, you know. I'm more than a little amazed how quickly people assume disagreement. Aren't we all one big happy family?
In any event, (a) I was coat tailing on your excellent and insightful joke, (b) I quoted someone else's brilliant wit, contributing nothing original, so (c) no matter how people arrived at the idea that my comment wasn't contributing to the conversation, (d) they may be right :-)
This is actually taken a bit out of context in you watch the full interview. This response was to the question of what experiences from Digg are you taking with you to your next startup and what are you going to do differently.
How can you judge what is true when you don't even know what the truth is? Did you work at Digg? I can assure that while there were of course sub-par employees, they are now what I would attribute to v4's failure.