本文发表在 rolia.net 枫下论坛What Makes a Good Programmer?
I just read two salon articles about Scott Rosenberg's new book Dreaming in Code. His thesis is that "programing is hard" and uses the experiences of the development of the Chandler project to frame the discussion. Scott identifies a common problem in large software development - inconsistent terminology use across the software development team. At the same time he complements the members of the development team as being talented programmers. These two ideas struck me as incongruous. How can a bunch of "ace programmers" end up with such a basic problem? Should programmers encountering this problem really be deserving of the accolade "ace"? And what skills would I expect from an "ace" programmer anyhow?
Before I go any further, I want to make it clear that I don't want to talk down Scottt or the Chandler team. Scott makes a number of great points that reflect my own experiences. Virtually every large software project I've seen has had problems akin to those Scott describes. Especially every large project I've worked on. I'm certainly as guilty of these difficulties as any programmer. But the examples that Scott describes are good grist for discussion about software development.
When people talk about talented programmers they are usually refering to their ability to write correct code, whch solves problems quickly and elegantly. I suspect that that is what Scott was implying by describing the Chandler team as ace programmers. Raw coding skills vary widely across individuals. When it comes down to it some programmers are just more talented than others at writing code. Large team projects - projects with more than 3 programers with schedules of more than a few months - require a whole set of skills beyond raw coding. On large teams, excellent coding skills are a prerequisite. Alone, they qualify you as a beginner, not an ace.
From Beginner to Good
For me, the mark of a good team programmer is someone who does not suggest rewriting everything from scratch. Scott makes the very valid point that programmers like to program - and that they don't like to understand code written by others. Truer words were never spoken. Time and time again I've seen smart novice programmers suggest rewriting code produced by other programmers. I've noticed an inverse relationship betwen the esteem I hold for a programmer and the number of times I've heard them suggest a rewrite of a large software project.
Good team programers are capable and willing to work with a codebase that is too large for a single person to rewrite within the project's schedule. They recognize that the existing codebase has shortcomings and they have the maturity and discipline to know that attempting to 'fix' everyone of those shortcomings will almost certainly kill the project. Instead they identify those areas which must be improved on to deliver the project, and they have the skills to make significant changes to a large and ugly (because every large piece of software is ugly - but that's another story) codebase without causing the whole thing to destabilize.
And From Good To Great
If the mark of a good team programmer is the ability to work (usually grudgingly) with the code of others, then the mark of a great team programer is the ability to produce code that other programmers on the team will gladly use. Programmers are the most fickle sort, and if you can produce code that other, less skilled, coders will use without suggesting a rewrite - then you've elevated yourself to the top of the programing heap. Great programmers produce code that is so good that it will prevent the cross programer problems that plague most large software projects.
Published Sunday, February 04, 2007 4:24 PM by peterhal更多精彩文章及讨论，请光临枫下论坛 rolia.net
I just read two salon articles about Scott Rosenberg's new book Dreaming in Code. His thesis is that "programing is hard" and uses the experiences of the development of the Chandler project to frame the discussion. Scott identifies a common problem in large software development - inconsistent terminology use across the software development team. At the same time he complements the members of the development team as being talented programmers. These two ideas struck me as incongruous. How can a bunch of "ace programmers" end up with such a basic problem? Should programmers encountering this problem really be deserving of the accolade "ace"? And what skills would I expect from an "ace" programmer anyhow?
Before I go any further, I want to make it clear that I don't want to talk down Scottt or the Chandler team. Scott makes a number of great points that reflect my own experiences. Virtually every large software project I've seen has had problems akin to those Scott describes. Especially every large project I've worked on. I'm certainly as guilty of these difficulties as any programmer. But the examples that Scott describes are good grist for discussion about software development.
When people talk about talented programmers they are usually refering to their ability to write correct code, whch solves problems quickly and elegantly. I suspect that that is what Scott was implying by describing the Chandler team as ace programmers. Raw coding skills vary widely across individuals. When it comes down to it some programmers are just more talented than others at writing code. Large team projects - projects with more than 3 programers with schedules of more than a few months - require a whole set of skills beyond raw coding. On large teams, excellent coding skills are a prerequisite. Alone, they qualify you as a beginner, not an ace.
From Beginner to Good
For me, the mark of a good team programmer is someone who does not suggest rewriting everything from scratch. Scott makes the very valid point that programmers like to program - and that they don't like to understand code written by others. Truer words were never spoken. Time and time again I've seen smart novice programmers suggest rewriting code produced by other programmers. I've noticed an inverse relationship betwen the esteem I hold for a programmer and the number of times I've heard them suggest a rewrite of a large software project.
Good team programers are capable and willing to work with a codebase that is too large for a single person to rewrite within the project's schedule. They recognize that the existing codebase has shortcomings and they have the maturity and discipline to know that attempting to 'fix' everyone of those shortcomings will almost certainly kill the project. Instead they identify those areas which must be improved on to deliver the project, and they have the skills to make significant changes to a large and ugly (because every large piece of software is ugly - but that's another story) codebase without causing the whole thing to destabilize.
And From Good To Great
If the mark of a good team programmer is the ability to work (usually grudgingly) with the code of others, then the mark of a great team programer is the ability to produce code that other programmers on the team will gladly use. Programmers are the most fickle sort, and if you can produce code that other, less skilled, coders will use without suggesting a rewrite - then you've elevated yourself to the top of the programing heap. Great programmers produce code that is so good that it will prevent the cross programer problems that plague most large software projects.
Published Sunday, February 04, 2007 4:24 PM by peterhal更多精彩文章及讨论，请光临枫下论坛 rolia.net