- Posted by justin on January 31, 2007
I have to say that I completely agree with the blog post below. I have experienced many developers that could code but were not good developers.
Original Blog Post From: http://codebetter.com/blogs/jeremy.miller/archive/2007/01/31/Being-a-Better-Programmer.aspx
There's a flurry of great posts and comment discussions going on right now about the divide between good developers and bad developers
The Great Divide
Like Jeff Atwood, I do believe there is an almost binary switch between effective and ineffective developers. I'm not exactly sure why this is, but if you'll indulge me, I've got a couple pet theories:
- People that are good coders are able to do make code work faster, which leads to getting more experience than their slower , and spare more thought cycles for how to do things better next time. The innately talented developer is able to get better and faster each time, which gives him or her more time to invest in getting better. From there I think it's simply a snowball effect.
- To Phil Haack's point that it's not entirely innate ability, any degree of contemplative thoughtfulness on the part of a developer will make that developer much better over time. The smartest guy in the world can still be intellectually lazy (but I don't see how you *could* be smart without intellectual inquisitively). Thoughtful people gain more valuable experience. People who aren't thoughtful may only be practicing their typing skills.
- Joannes added this as a prerequisite for being a great developer: "… a passionate curiosity for software related matter …." Every very good or great developer I've ever worked with enjoyed software development. I've been interviewing developer candidates lately, and a passion and intellectual curiosity about software development counts far more with me than Trivial Pursuit Q&A exchanges.
- Software development takes a very strong ability for abstract thought. I don't think that concrete thinkers have an easy time with software that's by definition a mental model of something else. I'd say visualization is important, but I've worked with good developers who had zero visualization ability. All the great developers I've worked with did though. People do think differently and have different modes of learning.
You can get Better
Like everyone else I believe that your best bet is to hire the best and brightest, but in reality you have who you have. Maybe the hiring process gets you the wide swings in productivity, but wringing out a 10-30% productivity gain out of journeyman developers is still a substantial gain. Training, coaching, discipline, better practices, communication techniques -- they can all contribute to productivity. "It's not the methodology, it's the man" is a hackneyed and cheap way to get some sort of imaginary high ground in any discussion, but it's partially BS. Anybody can get better, even if it's only in the way they interract with other people in the team. Besides, it's extremely unlikely that you can instantly go and replace poorly performing team members with better developers at will. You're largely stuck with the folks that you have. Making them better is probably your only option.
Following a tangent, when any debate about software practices or processes is going on some clown always pulls out this phrase: "you should just pick the best practices from waterfall, XP, Agile, RUP, whatever..." Hah! I've now seized the high ground you might think. No you haven't, you've simply indulged in the intellectual equivalent of empty calories. It's a worthless statement. The question "what *is* the best way to work" is still on the table. If we knew what the best of everything was, without a shred of doubt, we wouldn't be having the debate, now would we? Plus it's even harder than that because mix and match practices might not work well because many practices reinforce each other. I think you could happily add TDD and CI to any methodology and get some benefits, but they shine a bit more in an adaptive process. On the other hand, doing continuous design or adaptive project management on a codebase without automated tests and CI sounds dangerous to me.