What Makes a Good Programmer?

  • Article

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.

Comments

  • Anonymous
    February 04, 2007
    The comment has been removed

  • Anonymous
    February 04, 2007
    Refactor!T for ASP.NET - Free Download [Via: dhayden ] Prototype 1.5 Documentation in PDF [Via: Dion...

  • Anonymous
    February 04, 2007
    Average programmers produce the code that only the guru could understand. They cannot clearly express the idea behind the code - that's why other average programmers want to rewrite the code. Great programmers produce the code that is easy to understand, even for beginners. Even if the code written by great programmer is incomplete, everyone can see how to extend it. The code creation is communication. Ace programmers communicate better than beginners.

  • Anonymous
    February 05, 2007
    WRT to good team programmers, I couldn't agree more.  I think it could also be characterized as the difference between a Beginner and a Journeyman.  Experience with complex software projects, and I agree that they're all ugly in their own way, will/should eventually breed a sense of humility.  Humility for all the layers of complexity added at different times by different players with competing, often conflicting, pressures and goals. I've found that the temptation to "rewrite it all from scratch" is tempered by time invested in understanding the existing code.  That itch may never go away entirely (we are coders after all eh?) but if the codebase complexity is reflective of the underlying app complexity then over time I find myself thinking things like "there is a lot going on here" and, eventually, "Thank goodness I don't have to rewrite this from scratch by next month". I've found that if I think I'd like to rewrite the whole thing from scratch then more often than not I don't understand enough about it to respect just how herculean an effort that will be. On these kinds of projects I've found the biggest victories to be successfully modifying (or repairing) a large subsystem (e.g., logging).

  • Anonymous
    February 05, 2007
    The comment has been removed

  • Anonymous
    February 05, 2007
    First and firemost, a Good programmer uses Java and not Ruby or C++ or any of the other overhyped new fangled languages

  • Anonymous
    February 06, 2007
    The comment has been removed

  • Anonymous
    February 06, 2007
    What would you call a programmer that frequently proposes rewriting his own older code to try to make it better for other programmers to use? At what point does a large refactoring become a rewriting?

  • Anonymous
    February 07, 2007
    Assuming that existing "bad code" has an understandable interface and passes unit tests -- rewriting is not only wasteful but dangerous. However, oftentimes I see bad code and bad interface going hand in hand.  Nothing can stifle the progress and morale of a project team then being forced to use a framework that doesn't provide suitable tools for the problem being solved. BTW:  NoLiveTv makes an excellent, albeit slightly tangential, point.  Understanding the problem space allows a good coder to produce excellent code.

  • Anonymous
    February 07, 2007
    "First and firemost, a Good programmer uses Java and not Ruby or C++ or any of the other overhyped new fangled languages" The are a lot of /Good/ Java programmers. /Great/ programmers simply dont use Java.

  • Anonymous
    February 07, 2007
    The comment has been removed

  • Anonymous
    February 19, 2007
    Welcome to the twenty-first Community Convergence. I'm Charlie Calvert, the C# Community PM, and this

  • Anonymous
    February 19, 2007
    Any judgement of a programmer really has to do with the context they are working in.  A good programmer on one team may not be viewed as "good" on another team even if they write the same code. Great/Journeyman programmers have the ability to write great code regardless of context. The point at which someone becomes a great/journeyman programmer also has to do with their ability to conform the the project they are working on.  A programmer working on a project using CMMI with ISO 900x compliancy has a great deal of influences on the work he produce.  Producing the same code and artifacts for an Agile project is likely a waste of time and--while viewed as gold on the CMMI project--would likely get the programmer shunned. Another aspect of great programmers is they're ability to follow "if it ain't broke, don't fix it".  Many green programmers don't have the experience of how destabilizing "change for the sake of change" is.  I've watched projects self-destruct simply because someone wanted to change the language a project was written in--with no change in functionality.  A great programmer uses the tools they're given (including existing code) to write robust and reliable code.  Also, fixing/abandoning code that does not work (to whatever degree) is not "re-writing"--a programmer that suggests not re-writing code that clearly does not work to some degree cannot be viewed even as "good". But, sometimes a re-write is the best option--it may very well be quicker than fixing all the little problems the design doesn't account for.  But, that's a characteristic of design, not of a programmer. What it really gets down to is does the programmers work fulfill the requirements for the project.  That's the only accurate measurement, but it's no guarantee of good/great/journeyman status in another context.

  • Anonymous
    February 21, 2007
    Having changed a program or two, I have a toolbag full of things to make code I've not seen before understandable to me. A programmer's style is usually consistent, whether it be good or bad, and a little effort towards understanding that style turns on a lot of lights. Those lights allow for easy navigation in existing codesets which, in turn, allows a new programmer to extend it in a fashion that may be better or worse than the programmer he/she is following.

  • Anonymous
    February 21, 2007
    I think the author's original comments were spot on.  Then other clever people joined in.  Just like writing code as a team.   Everyone wants to make their point and have it recognised as valid.  Sometimes this is because they just want to appear better or more intelligent than others in the team, sometimes because they have logic-based concerns that have not been discussed, and sometimes because their skills are being challenged by new technology.   Here is a prediction: in a thousand years no-one is going to be writing code ("...not as we know it, Jim"). The issue in this debate, and when writing code as a team, is being able to go past "scoring points in a debate" and reach a consensus on how to progress. There will be times to rewrite and there will be times for sticking plaster: the best team players know how to get everyone "on side", to assist the project manager and can align with the project manager's decisions even when these over-rule personal opinion. But that is just my personal opinion.

  • Anonymous
    February 22, 2007
    The comment has been removed

  • Anonymous
    February 23, 2007
    To poorly paraphrase another adage: Good programmers know what code to write, Great programmers know what code NOT to write.

  • Anonymous
    February 23, 2007
    The good programmer is one who re uses code available on the internet and makes proper use of it at proper place. Everything is available on net so nowdays programming is a work of cut and paste but obviously that cut and paste need programming logic. I think I m master in it

  • Anonymous
    February 23, 2007
    i think this post is quite fair. I agree to it. I dont call myself a great programmer but i really emphasize on making sure my code is clearly understandable by everyone, reducing the overall headache. But hey, this is why theye suggest 'Good Planning', without good planning and OO code, things get quite difficult.

  • Anonymous
    February 26, 2007
    <blockquote>"First and firemost, a Good programmer uses Java and not Ruby or C++ or any of the other overhyped new fangled languages"</blockquote> kant b an great prohgramer unnles no how to spel and rite. sure, C++ is so new-fangled and overhyped man, you are so smart.