My company is making a business of identifying great developers (gild.com). It is a notoriously difficult task, even with the wealth of information developers tend to make public about themselves.
We are making assessments of code made public, and combining it with how active people are in places like stackexchange. You can argue that code evaluated from github is not necessarily indicative of a good developer, but it's a good place to start rather than shotgun LinkedIn spam from recruiters.
Not sure why hubspot is having issues, I'll have to talk to the marketing guys who maintain the hubspot pages... Currently we don't let people claim their profiles, but will in the future. "login" is really just for customers at this point.
...even with the wealth of information developers tend to make public about themselves.
I guess I'm gonna be a negative Nancy here, but I know some very good developers that don't make anything about themselves public. I expect some of the very best are completely invisible on the internet, at least by their real name, because they're too busy working on things their employers would rather keep as trade secrets.
I suspect you're right, though I'd rather they share the non trade secret advice that they have in a more public fashion, such as a blog or stackoverflow.
For sure, we can only evaluate what we can get access to. We're trying to scour as many sources as possible, but if you're exceedingly quiet, you wouldn't be in our system.
I hear this statement all the time. Great developers are 20x more productive than average developers.
I've been a software engineering manager for 20+ years.
I've worked with great teams and I've worked with teams where it fell on me to fix a bug because no one else could figure it out.
In my experience, it's more complicated than good developers vs. average developers.
There are best practices that great developers demonstrate. There are great developers who are terrible team players and there are terrible developers who turn out to be great product managers. There are average developers who have a critical ability to keep the team together and to get even more out of the top developers.
In my experience, I prefer the right attitude, the right drive, and a person who is constantly striving to do better.
There's a lot of arrogance in our industry. I'm not sure it's something that we should continue to embrace.
I agree with you wholeheartedly, and I think the points are complimentary. I also wrote a post prior to this one, in which I argue that a team of good developers that can work together is far better than a team with one technically superior developer who can't work with others. If you can find the developer who is both technically great, and can communicate effectively in a team, you've found a very special person indeed.
This article is operating on an assumption that you let any given developer access your entire codebase. By partitioning developers into certain projects, you can isolate bad developers and move them into less harmful positions, while moving the majority of your great developers into critical infrastructure areas. There are ways to handle this that do not include missing out on good developers.
I agree that it operates on that assumption, and that the full-stack developer assumption is a good one. Have a read of this blog post for the mindset:
Are we done with having original thoughts now? Why was this written? Programming bloggers that are in some kind of management or, especially, founders write this exact same post 100 times a day ... We get it ... The "20x rock star progammer" meme is real and we have to pay attention !!!!
Ok, whatever. Stop talking about it. I think it is probably true that great programmers are order of magnitude BUT please don't flame over that because I don't care.
However, why do most of these CRUD projects think rock stars want to work for them or why do they think they are doing "really important stuff" when they are really just doing CRUD, and in some cases plain old boring CRUD.
Anyway, this whole concept, true or not is just cliche at this point.
This post feels a bit too much self-congratulatory. "look! I'm a great developer! And if you're one too, upvote!"
For one thing, the problem is that it's not a simple dichotomy of great developers vs. average developers. I have nothing to back it up, but I'm guessing it's a fairly typical normal distribution of talent… Then, where does "greatness" start? 20x sounds fantastic, but what's the difference between a great developer and a developer that just a bit less good? Will I get a 2x at least?
The other thing that bothers me is that it's a very selfish and elitist idea. I'm pretty sure that most of the great developers didn't start as such. To become "great", they worked and learned from others who were better than them. And they certainly did so by working in teams that accepted a "not-great" developer amongst them. The horror.
If everybody did like you're saying, we'd eventually run out of great developers, because the not-great-by-a-hair would have to work with the terrible horrible average developers and wouldn't progress as they should/could. (except for the rare breed of truly great developers who were better at 14 than most developers will ever be)
edit: in this last paragraph, it sounds like I consider myself a great developer. Let it be known that I think no such thing.
This article was very confusing. They go on to praise the great developers, and how much companies need them, etc, but then they end with this:
>If after you interview a candidate you find that you aren’t completely sure about them, don’t hire them. If you can’t tell if they are good or not, don’t hire them. If 2 out of 6 people on the interview loop are either ‘no’ or ‘maybe’, don’t hire them. The consequence of letting a bad developer in the door is far greater than maybe missing a good one.
This is exactly what people do, and it's the exact reason why finding great developers is hard. And ironically, this tip is posted under the section "We’re Awful At Distinguishing Great Developers."
Great developers are difficult to spot because they can look like bad developers. Great developers are often honest about what they know and don't know. If you ask if they know mysql, their answer might be that they're very familiar with it, but there's a lot about it they don't know. Great developers can often lack the confidence that average developers exude to make up for their lack of skill. If you ask how to do something, they might express that their way may not be the best. Great developers can be nervous, because they can believe that they may not be as qualified as a company is seeking.
All these signals make people doing the hiring uncertain. To put a filter of "unless 1000% certain, do not hire" just ensures you get someone of, at absolute best, your skill level, and at worst, a fantastic bullshitter.
Would you agree that being a great communicator, and growing as a person to be less nervous are aspects in the makeup of a great developer? (I'm not saying they are, just curious what you think).
I don't think hiring great developers is something everyone must do. After all, there are not enough of them to go around. Instead I'd say that the ability to hire great developers is a key advantage to being a smaller company.
Also, I'd say that the notions of "10x" or "20x" greater productivity from the best developers are set on the wrong footing entirely. Such ideas presuppose that development is just production work, when in reality it is highly creative. The advantage of good developers isn't just that they do what others would do but more efficiently, the advantage is that they do much more. Often times they expand your business. Quite often the genesis of a multi-million dollar product or services offering doesn't come from the top-down, conceived in management and merely implemented by the rank and file, but instead comes from the bottom-up, from a wacky idea that a developer has and rolls into a tech demo. Without great developers that's the sort of thing you miss out on.
Really? You're quantifying ability? What is a unit of programmer ability? You can track LOC or bugs or maybe even revenue generated, but none of those are exact measures of ability.
In my experience hiring great developers brings more challenges then benefits.
They are difficult to retain, They are difficult to be made satisfied, you need to change your company compensation rules to accommodate them and various other problems.
It's much better in my experience to hire a mediocre developer and train him in your domain.
If it requires changing your company compensation rules, you have different problems at hand. Great developers don't cost more in dollar signs so much as they do in operating in an environment with other great developers, working on great challenges.
33 comments
[ 5.9 ms ] story [ 67.6 ms ] threadThat sounds like a fantastic way to find scads of mediocre developers. Development isn't about language, it's about comprehension.
I guess I'm gonna be a negative Nancy here, but I know some very good developers that don't make anything about themselves public. I expect some of the very best are completely invisible on the internet, at least by their real name, because they're too busy working on things their employers would rather keep as trade secrets.
I've been a software engineering manager for 20+ years.
I've worked with great teams and I've worked with teams where it fell on me to fix a bug because no one else could figure it out.
In my experience, it's more complicated than good developers vs. average developers.
There are best practices that great developers demonstrate. There are great developers who are terrible team players and there are terrible developers who turn out to be great product managers. There are average developers who have a critical ability to keep the team together and to get even more out of the top developers.
In my experience, I prefer the right attitude, the right drive, and a person who is constantly striving to do better.
There's a lot of arrogance in our industry. I'm not sure it's something that we should continue to embrace.
Agreed, these are all attributes that help make the job of managing corporate developers much easier.
As opposed to those stubborn, arrogant, stud developers who are only useful for doing things like rewriting the unix kernel and open-sourcing it.
http://codercake.com/benefits-of-becoming-a-full-stack-devel...
Ok, whatever. Stop talking about it. I think it is probably true that great programmers are order of magnitude BUT please don't flame over that because I don't care.
However, why do most of these CRUD projects think rock stars want to work for them or why do they think they are doing "really important stuff" when they are really just doing CRUD, and in some cases plain old boring CRUD.
Anyway, this whole concept, true or not is just cliche at this point.
http://www.joelonsoftware.com/
For one thing, the problem is that it's not a simple dichotomy of great developers vs. average developers. I have nothing to back it up, but I'm guessing it's a fairly typical normal distribution of talent… Then, where does "greatness" start? 20x sounds fantastic, but what's the difference between a great developer and a developer that just a bit less good? Will I get a 2x at least?
The other thing that bothers me is that it's a very selfish and elitist idea. I'm pretty sure that most of the great developers didn't start as such. To become "great", they worked and learned from others who were better than them. And they certainly did so by working in teams that accepted a "not-great" developer amongst them. The horror.
If everybody did like you're saying, we'd eventually run out of great developers, because the not-great-by-a-hair would have to work with the terrible horrible average developers and wouldn't progress as they should/could. (except for the rare breed of truly great developers who were better at 14 than most developers will ever be)
edit: in this last paragraph, it sounds like I consider myself a great developer. Let it be known that I think no such thing.
>If after you interview a candidate you find that you aren’t completely sure about them, don’t hire them. If you can’t tell if they are good or not, don’t hire them. If 2 out of 6 people on the interview loop are either ‘no’ or ‘maybe’, don’t hire them. The consequence of letting a bad developer in the door is far greater than maybe missing a good one.
This is exactly what people do, and it's the exact reason why finding great developers is hard. And ironically, this tip is posted under the section "We’re Awful At Distinguishing Great Developers."
Great developers are difficult to spot because they can look like bad developers. Great developers are often honest about what they know and don't know. If you ask if they know mysql, their answer might be that they're very familiar with it, but there's a lot about it they don't know. Great developers can often lack the confidence that average developers exude to make up for their lack of skill. If you ask how to do something, they might express that their way may not be the best. Great developers can be nervous, because they can believe that they may not be as qualified as a company is seeking.
All these signals make people doing the hiring uncertain. To put a filter of "unless 1000% certain, do not hire" just ensures you get someone of, at absolute best, your skill level, and at worst, a fantastic bullshitter.
Also, I'd say that the notions of "10x" or "20x" greater productivity from the best developers are set on the wrong footing entirely. Such ideas presuppose that development is just production work, when in reality it is highly creative. The advantage of good developers isn't just that they do what others would do but more efficiently, the advantage is that they do much more. Often times they expand your business. Quite often the genesis of a multi-million dollar product or services offering doesn't come from the top-down, conceived in management and merely implemented by the rank and file, but instead comes from the bottom-up, from a wacky idea that a developer has and rolls into a tech demo. Without great developers that's the sort of thing you miss out on.
We should get over the "x times more productive" notion altogether. Emphasis should be on doing things right than "fast".
They are difficult to retain, They are difficult to be made satisfied, you need to change your company compensation rules to accommodate them and various other problems.
It's much better in my experience to hire a mediocre developer and train him in your domain.