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.


 


Comments (20)

  1. Joe Chung says:

    So what you’re saying is that good programmers have to live with the —- that is bad programmer’s code?

    Well said, like a manager.  *golf clap*

  2. Refactor!T for ASP.NET – Free Download [Via: dhayden ] Prototype 1.5 Documentation in PDF [Via: Dion…

  3. ~AVA says:

    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.

  4. arnshea says:

    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).

  5. Brice Richard says:

    I could not DISAGREE more with this article and its patent definition of a good programmer.

    When something like this is stated; "For me, the mark of a good team programmer is someone who does not suggest rewriting everything from scratch," I say that sometimes the code NEEDS to be rewritten because you can’t continue to put a "band-aid" on every functional hole in a code base.

    Too many such "band-aids" in code CAN introduce major unanticipated problems in functionality and latent bugs….

    Spaghetti code is also a manifestation of incorporating "band-aid" code within a solution. And guess who is blamed once you begin applying "band-aid" fix-it-up code to a code base that needs to be rewritten and then subsequently breaks? YOU get the blame….the Johnny come lately who made a myopic recommendation to incorporate "band-aid" code to a problematic code base that needed to be rewritten in the first instance.

    No thank you. I will ALWAYS recommend rewriting code when I think TOO many "band-aids" to code have been mixed into a code base.

    This article is WAY off target….

  6. Hasaam Hasheeb says:

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

  7. NoLiveTv says:

    Coding?…hell, that’s the simple part.  

    As hands-on development manager who has worked on the spectrum of tiny to extremely large projects, imho your head is way too far down in the weeds.    

    A programmer is incapable of being either good or great if they do not communicate well and are not capable of understanding the business/functional context in which they are working.  Even a mediocre coder can be a good programmer if they are able avoid problems/functional errors in the code (theirs or others) because they have their heads up and are looking around at what is going on in the project and how their piece fits into it.  The good programmer understands their tasks’ functional and technical designs (if the programmer isn’t doing the technical designs him/herself), asks lots of questions, challenges assumptions or approaches, proactively communicates with other developers whom he/she is dependent upon and who are dependent upon him/her, and oh by the way creates code that helps the project get "there."

    I currently have the good fortune of working with one of the best programmers I have ever worked with.  Not only does he create great, well-written, robust, understandable, elegant, ery-close-to-bug-free code, but before he writes a single line of code for a task, he has actively pursued all the non-coding items I mentioned above.  He hardly ever suggests recoding unless it contributes to moving the project forward towards its business objectives.  He also accepts "that’s just the way it is because …whatever reason…" after asking "Why is it like this instead of that?"  He continues to proactively ask questions both as he is coding to ensure the objective of his task hasn’t moved (and often it has), and long after his task is done to ensure that "things" haven’t changed in a way that negatively impacts his code.  

    And he does this all with tremendous tact.

    Programming, that’s a skill for which coding a only a piece.  Great programmers are at least good coders with a bunch of other soft and techie skills added on.

  8. chuck says:

    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?

  9. CrankyPants says:

    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.

  10. galo says:

    "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.

  11. doc0tis says:

    @Hasaam

    First, C++ (early 80’s) was around before Java (early 90’s).

    Second, a Good programmer can use the tools at hand and determine which tools are best for the job, VBA/C#/Java/COBOL/Assembly all may correct tool in different circumstances.

    @Brice & Joe,

    I think that you have misinterpreted the "Don’t re-write" line. I believe that Peter would be fine with a re-write if it’s warranted, but too often coders will say "I can do this better" but in fact they will duplicate code, spend valuable hours and introduce bugs. And the only reason they want to do the rewrite is because they don’t want to learn the interface of existing codebase.

    Take for instance Microsoft Word. I believe that Word takes up too much memory for the tasks that I use it for. I don’t need a whole bunch of that functionality. I "could" re-write Word to do only what I need and at half the memory use, but would that be a good use of my [company’s] time? I am guaranteed to introduce bugs etc… A better use of my time would be to learn how to use Word better and to optimize it.

    I know that in my ERP there is code that is inefficient, that is buggy, that is wrong, but I have to deal with business value, as my job as a programmer is to support the business. Does reducing the time that it takes "Report A" to run from 1 hour to 58 minutes make a difference to business users? Does it make sense for me as a programmer to do this? No! BUT, if "Report A" is unmaintainable due to horrible coding and I am asked to make a change, there may be a reason to "re-write" this module.

    –doc0tis

  12. Welcome to the twenty-first Community Convergence. I’m Charlie Calvert, the C# Community PM, and this

  13. Peter Ritchie says:

    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.

  14. Joss Miller says:

    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.

  15. Simon Masters says:

    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.

  16. Perry says:

    What makes a good plumber?

    A good plumber is not going to rip out all the pipes in your house just because you need a new hot water heater.  On the other hand, if the house is all lead pipes and leaking, a good plumber might well suggest replacing all the pipes, right?

  17. Corey Haines says:

    To poorly paraphrase another adage:

    Good programmers know what code to write, Great programmers know what code NOT to write.

  18. Sandeep Borhade says:

    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

  19. Kamran says:

    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.

  20. emjayess says:

    <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.