What Makes a Good Programmer

Haseman has an article on what makes a good programmer presumably this is in opposition to signs you may be a bad programmer. In the commercial world software is developed within the confines of a project and all the organizational boundaries that entails. I would consider what makes a good programmer:


1. Hits deadlines and if they are missing them they tell you quickly and openly that they cannot make it in the alotted time. It is more about honesty as to where a developer is in a task. I have never seen anyone say you will have to find a way to do it in the time, resources, etc are always shuffled to accommodate these kinds of issues. I always reckon one major task will be hopelessly under-scoped and another over-scoped. Moving resources around is rarely an issue.

2. Hits the spec to completeness. Most bugs are not quality flaws, instead they are spec completion issues. Timelines in projects are usually so short and compressed that hitting a spec to perfection in the time a task is intended means that bugs that are found are not about spec completion issues but real quality flaws; ie bugs.

3. Is productive in new technologies quickly. In the last project we did the team used the technologies; Flex, Actionscript, PureMVC, Java, Javascript, Spring, Struts, JSP tags, DHTML, Dojo, SVG, FXG, XML, E4X, etc, etc. Once you go into maintenance mode and bug fixing; any one person on the team may have to work in any or all of those areas even if they are not familiar with it. Being able to do quality work in new technologies is an under-rated skill.

4. No hand holding. One of the things I dislike is when someone is in an area of code and knows that something needs to be done, but are hesitant to go and make the change because of a fear of breaking something, or not wanting to step on someone else's toes, or they lack confidence to make the change, or they would rather someone else do it which is usually impossible when everyone is busy. I always say, "If you need it, go ahead and do it." I prefer developers with that kind of confidence who will modify code at any level of the technology stack. That isn't everyone's cup of tea but developers tend to harden up quickly and grow in confidence when they are given that expectation and responsibility.


There are other engineering considerations, for instance a developer that does not understand object oriented programming or type safety can wreak havoc in a project for a period until their work is caught and examined. But these are fixable things that come with experience.

Bad design and over-engineering are hard to refactor out in a project based environment as they require a 'project' or 'mini-spec' for time to be given to code and engineering improvement. Business focused companies do not want to spend capital on that often and would rather innovate in new revenue streams while keeping existing/working code in place until it needs to be overhauled for reasons of capacity or customer experience degradation.
cam 2009-08-11 10:50:02.0