I think the quality of the code depends a whole lot more than the speed at which it is written. Badly written code wastes everyone else's time, and can often be ridiculously difficult to maintain (or debug). The other "time sink" is bad design choices with the result that most (or even all) of the code needs to be rewritten. When working in a team, what's important is "everyone's time", not just the time of one coder.

On the flip side, if a person can code fast because their code has very few bugs (or bugs are caught early), or because they look things up on Google / Stack Overflow a lot less frequently than the average coder, or because they follow best practices + a very efficient workflow, then I think the credit is deserved. And even more so if the person is able to translate those skills to help everyone else on the team to become better coders (it's a team effort after all).

In my experience, coding slowly creates more thoughtful, stable code that lasts a good long time -- especially if the "slowness" is due to spending time creating rigorous tests.

I consider myself to be a slow coder, so my thoughts may be somewhat biased.

I have worked with fast coders and to see them work is incredible. Clearly, they are on another level of thought or plane of existence - at one with the system perhaps?

I have also at times had moments of being able to code rapidly.

What I've learned is it comes down to 3 things:

1. experience with the underlying technology (library, framework, language),
2. familiarity with your tools, and
3. completely understanding the scope of work.

And I'd go so far as to say that point 3 is the most important one. If you can form a mental path in your head about what code to write to achieve the desired functionality, your coding will be speedy.

On the other hand, even if you have a fair degree of muscle memory for your chosen language and preferred tools, you could still be "slow" if the task at hand is totally new to you and requires you to take your time.

The biggest downside to being a fast coder is your error rate will be very high. And if you try to be fast in the context of a domain you don't understand, you will most likely introduce problems that you don't fully appreciate until much later, by which point it could be too late.

The fast do not always win the race!

If making something new, slow is better unless you're a genius.

If making a small piece / component to spec then fast is better unless you don't read the spec properly.

no it's not ! I actually prefer people who think about what they are doing. But there is a difference between slow because of thinking through every step and slow because you don't understand the problem.

If you take 2 weeks on a piece of code and I never have to touch it again unless to add something or adapt it. It's better than finishing something in 3 days and I have to clean up that shit because you didn't think it through.