I’ve just read Kevin Schroeder’s post:
and I wanted to post my reply about the definition of the “good developer”, but it seems that you can’t post to his blog a comment longer than 2048 character, so I had to create this blogpost, sorry for the grammar and such.
My opinion is that there are many kind of good and bad developers.
Usually for a project, you need at least one lead developer, who knows his stuff(development workflow, architechtural challanges, migration, deployment, relational databases, OOP, design patterns, etc.), can see the whole picture: can work with the teammembers, with the project management, with the IT, the owner, the customers.
Its important, because without this kind of knowledge, and empathy, he can’t make good decesions, because he can’t comprehend the weight of that decesions.
It’s a good thing, if you have somebody with devops skills, either an IT guru, who is a above-avarage developer, or vica versa, because there are many problems/decisions which requires good understanding on both fields, and I’ve seen many cases, when a single-minded developer and a similar non-programmer sysop/sysadmin could get to the best solution, because they one of them didn’t understand the problem, the other one wasn not aware of the possible solutions. :/
And it can be a good idea, if you have somebody, who is either a performance or QA guru or UX, etc. but usually it’s a good thing, if he isn’t a dedicated person, just a “regular” developer who likes and knows that particular field better than the average dev.
There can be cases, when it’s a good thing, if you have an all-around person, who has greet experience and/or he is up-to-date with the current AND the past tools, best practices, etc. Just try to hire somebody, who is willing to help and share his knowledge with the other teammembers. There are many “superstars” and “gurus” out there, but if he/she can’t play in team, then you suck more with them, than without.
And the mostly underrated, but I think the most necessary part of your development team is the “grunts”.
They contribute most of the work, and you want to select them carefully. Maybe they don’t have flashy skills, or 3 years cassandra experience, but if you tell them what to do, they will do it.
If you select them well, they can work wonderfully, but you have to support them with your sages, because they not the best for architectural decisions, or so, but they can work, and they can do the work, that your “pros” wouldn’t want to dirty their hands with. :/
So I think that the most important skills of a developer can have:
– responsible (does his job, and you can count on his estimates.)
– teamplayer (can ask for help, can accept critique, etc.)
– enthusiastic (enjoys the work)
– openminded ( not afraid to try/learn new stuff )
– obsessed with learning stuff
that’s my 2 cents