I've been a professional coder for a several years. The comments about my code have generally been the same: writes great code, well-tested, but could be faster.

So how do I become a faster coder, without sacrificing quality? For the sake of this question, I'm going to limit the scope to C#, since that's primarily what I code (for fun) -- or Java, which is similar enough in many ways that matter.

Things that I'm already doing:


Write the minimal solution that will get the job done
Write a slew of automated tests (prevents regressions)
Write (and use) reusable libraries for all kinds of things
Use well-known technologies where they work well (eg. Hibernate)
Use design patterns where they fit into place (eg. Singleton)


These are all great, but I don't feel like my speed is increasing over time. I do care, because if I can do something to increase my productivity (even by 10%), that's 10% faster than my competitors. (Not that I have any.)

Besides which, I've consistently gotten this feeback from my managers -- whether it was small-scale Flash development or enterprise Java/C++ development.

Edit: There seem to be a lot of questions about what I mean by fast, and how I know I'm slow. Let me clarify with some more details.

I worked in small and medium-sized teams (5-50 people) in various companies over various projects and various technologies (Flash, ASP.NET, Java, C++). The observation of my managers (which they told me directly) is that I'm "slow."

Part of this is because a significant number of my peers sacrificed quality for speed; they wrote code that was buggy, hard to read, hard to maintain, and difficult to write automated tests for. My code generally is well-documented, readable, and testable.

At Oracle, I would consistently solve bugs slower than other team-members. I know this, because I would get comments to that effect; this means that other (yes, more senior and experienced) developers could do my work in less time than it took me, at nearly the same quality (readability, maintainability, and testability).

Why? What am I missing? How can I get better at this?

My end goal is simple: if I can make product X in 40 hours today, and I can improve myself somehow so that I can create the same product at 20, 30, or even 38 hours tomorrow, that's what I want to know -- how do I get there? What process can I use to continually improve? I had thought it was about reusing code, but that's not enough, it seems.

I like Jeff Atwood's approach to this which can be found here http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html.  

Basically in the article he references a passage from the book Art & Fear by David Bayles and Ted Orland.  The passage goes:


  The ceramics teacher announced on
  opening day that he was dividing the
  class into two groups. All those on
  the left side of the studio, he said,
  would be graded solely on the quantity
  of work they produced, all those on
  the right solely on its quality. His
  procedure was simple: on the final day
  of class he would bring in his
  bathroom scales and weigh the work of
  the "quantity" group: fifty pound of
  pots rated an "A", forty pounds a "B",
  and so on. Those being graded on
  "quality", however, needed to produce
  only one pot - albeit a perfect one -
  to get an "A". Well, came grading time
  and a curious fact emerged: the works
  of highest quality were all produced
  by the group being graded for
  quantity. It seems that while the
  "quantity" group was busily churning
  out piles of work - and learning from
  their mistakes - the "quality" group
  had sat theorizing about perfection,
  and in the end had little more to show
  for their efforts than grandiose
  theories and a pile of dead clay.


Essentially getting your hands dirty faster and more often improves your skills better, than spending your time studying and theorizing about the "perfect" way to do it.  My advice, keep practicing, keep up with technology, and study design.
