David Veksle does an excellent job of describing them:
Yes, I realize this is one of the self-congratulatory articles that programmers write when they want to describe themselves. But it is still useful to know how good programmers do their work. On the other hand, it is perhaps more useful to understand how some programmers never manage to channel years of experience into writing good code.
There are many kinds of mistakes made by software developers, but the “jump directly into coding and stay coding” is perhaps one of the most common. The reason being that this method works extremely well for small problems, can work with some effort for a few non-trivial problems and totally breaks down for commercial software that requires multiple people on development staff and is used by users of different skills and personalities.
One way of thinking about this is that bad programmers do not care about quality and are only interested in paychecks. This gets us nowhere because there is no solution other than replacing those programmers. A better way of thinking is to assume that bad programmers do not “know” about quality and training can help. This is true for many programmers who can benefit from the knowledge of better tools and techniques. But it also doesn’t entirely really address the problem.
My observation has been that programmers who exhibit the trait of spending all their time in code is that they think they are doing work. They define work as churning out line after line of code. More lines of code, more functions, and more screens mean that they are doing work. Fixing bugs is also work. Another bug fixed means another piece of work accomplished.
To them, refactoring seems a strange thing to do. Why change the code when everything is working fine? Why not spend time working, i.e., getting some more functionality implemented? Especially since the refactoring usually consists of deleting code, i.e., reducing what was done before.
This may seem like sacrilege to good programmers, but there is a correspondence to a real world situation, namely, hoarding. Most people (including me) have a tendency to accumulate junk in our houses. We buy a book, read it and never touch it again, but it occupies a place on a bookshelf. A broken machine sits on a shelf in the kitchen. The basement or garage is full of memories from older days that we no longer care for. We spend little time clearing them out, but we spend extraordinary amounts of time and energy acquiring new things.
The culture at many software companies accentuate this behavior by the use of hard deadlines. For many programmers, it is a less risky proposition to release a low-quality product on time than it is to create a high-quality product that is two weeks late. Even when there are no apparent deadlines (such as an R&D projects), there are deadlines and you need to show something working, not just a design or prototype.
Now, for good programmers, lack of time is not an excuse for shoddy work. Most good programmers write good code and their lack of quality is usually at a higher level in terms of design that could have been better. For weaker programmers, they need an environment that can encourage them to work on improving their quality, in addition to mentoring, code reviews, pair programming and the like.
Finally, there will always be different levels of programmers (good, medium and bad) no matter what you do. It is not just about laziness or ignorance, but also related to innate skills, intelligence and aptitude for the job. Some people can visualize design concepts and create great systems. Others (who might be good in other areas) just don’t have the right engine for it. Some great programmers working in extremely complex code running system software can be very poor at user interface design and vice versa. Different people have different skills, and sometimes people are in the wrong profession.
source : http://www.thoughtclusters.com/2010/09/characteristics-of-great-programmers/
A programmer spends about 10–20% of his time writing code, and most programmers write about 10–12 lines of code per day that goes into the final product, regardless of their skill level. Good programmers spend much of the other 90% thinking, researching, and experimenting to find the best design. Bad programmers spend much of that 90% debugging code by randomly making changes and seeing if they work. […]
Great programmers spend very little of their time writing code – at least code that ends up in the final product. Programmers who spend much of their time writing code are too lazy, too ignorant, or too arrogant to find existing solutions to old problems. Great programmers are masters at recognizing and reusing common patterns. Good programmers are not afraid to refactor (rewrite) their code constantly to reach the ideal design. Bad programmers write code which lacks conceptual integrity, non-redundancy, hierarchy, and patterns, and so is very difficult to refactor. It’s easier to throw away bad code and start over than to change it.
Yes, I realize this is one of the self-congratulatory articles that programmers write when they want to describe themselves. But it is still useful to know how good programmers do their work. On the other hand, it is perhaps more useful to understand how some programmers never manage to channel years of experience into writing good code.
There are many kinds of mistakes made by software developers, but the “jump directly into coding and stay coding” is perhaps one of the most common. The reason being that this method works extremely well for small problems, can work with some effort for a few non-trivial problems and totally breaks down for commercial software that requires multiple people on development staff and is used by users of different skills and personalities.
One way of thinking about this is that bad programmers do not care about quality and are only interested in paychecks. This gets us nowhere because there is no solution other than replacing those programmers. A better way of thinking is to assume that bad programmers do not “know” about quality and training can help. This is true for many programmers who can benefit from the knowledge of better tools and techniques. But it also doesn’t entirely really address the problem.
My observation has been that programmers who exhibit the trait of spending all their time in code is that they think they are doing work. They define work as churning out line after line of code. More lines of code, more functions, and more screens mean that they are doing work. Fixing bugs is also work. Another bug fixed means another piece of work accomplished.
To them, refactoring seems a strange thing to do. Why change the code when everything is working fine? Why not spend time working, i.e., getting some more functionality implemented? Especially since the refactoring usually consists of deleting code, i.e., reducing what was done before.
This may seem like sacrilege to good programmers, but there is a correspondence to a real world situation, namely, hoarding. Most people (including me) have a tendency to accumulate junk in our houses. We buy a book, read it and never touch it again, but it occupies a place on a bookshelf. A broken machine sits on a shelf in the kitchen. The basement or garage is full of memories from older days that we no longer care for. We spend little time clearing them out, but we spend extraordinary amounts of time and energy acquiring new things.
The culture at many software companies accentuate this behavior by the use of hard deadlines. For many programmers, it is a less risky proposition to release a low-quality product on time than it is to create a high-quality product that is two weeks late. Even when there are no apparent deadlines (such as an R&D projects), there are deadlines and you need to show something working, not just a design or prototype.
Now, for good programmers, lack of time is not an excuse for shoddy work. Most good programmers write good code and their lack of quality is usually at a higher level in terms of design that could have been better. For weaker programmers, they need an environment that can encourage them to work on improving their quality, in addition to mentoring, code reviews, pair programming and the like.
Finally, there will always be different levels of programmers (good, medium and bad) no matter what you do. It is not just about laziness or ignorance, but also related to innate skills, intelligence and aptitude for the job. Some people can visualize design concepts and create great systems. Others (who might be good in other areas) just don’t have the right engine for it. Some great programmers working in extremely complex code running system software can be very poor at user interface design and vice versa. Different people have different skills, and sometimes people are in the wrong profession.
source : http://www.thoughtclusters.com/2010/09/characteristics-of-great-programmers/