You can categorize developers by how much they care or how much drive they have to learn and the level of innate technical ability or skill they possess.
TYPE A: HIGH DRIVE HIGH SKILL
TYPE B: HIGH DRIVE LOW SKILL
TYPE C: LOW DRIVE HIGH SKILL
TYPE D: LOW SKILL LOW DRIVE
Firstly. management needs to vigorously avoid or jettison type D people - nothing much will motivate or improve them. Secondly, there must be enough of a critical mass of the Type A folks to be able to bring up the types B and C. The reality for most is that their teams will be largely comprised of B, C, and D people. Theoretically C people have the most potential, but even B types can be useful workhorses (albiet often frustrating because of the mistakes they make). The common excuses for a status quo of mediocrity or worse in development are:
- It cannot be done diffently in this company/environment/project
- All other ways are too complex
- There is a thousand good ways to solve a problem
- I don't have the energy or will to find another way
- I don't have the time to find another way
- I know this way and it works just fine
- Others will not be able to maintain a complicated solution,
- My favorite: I barely understand WHAT we are solving and the only way I can relieve this stress is to use a tried and tested HOW
I don't want to detract by responding to each of these excuses..there's a lot that can be said for each though! Anyhow, the most effective techniques I have seen to motivate the B and C people is plain old talking and whiteboarding with the A folks and the As leading by example (without severely hurting anyone's egos). Naturally, the type A folks have to be willing and patient to share information and not be the types who like to hammer away at code alone in a deep dark dungeon.
Do B and C know what they are doing differently?
Do B and C know there are better ways that are not too hard or too complex (rather simpler and more elegant)?
Do B and C know how A solves problems?
Can A share how he understands the problem?
Can A share his solution to the problem?
Can A share the solutions he rejected and why?
Final must have: B and C must not despise A for being a smart arse and A can talk to people without being too much of a smart arse.
Honestly, more than often, I feel the biggest problem is that people do not want to take the time to understand WHAT problem they need to solve so they are unable to effect the HOW to solve it in the right direction. I believe a culture of design simplicity and elegance and understanding problems (before you try and solve them) can be very exciting and rewarding to developers .. they just need to know it is possible (in their workplace).