[Dudeman112]

>The fastest programmers writes quality code

I've spent effective years of my life unfucking code written by fast programmers because no one can extend, change or understand their code.

As far as I am concerned the probability that a fast programmer also writes quality code is approximately 0.

There are outliers out there. But if you tell me someone is a fast programmer I'm not betting they write quality code.

[Jensson]

If you tell me a programmer wrote a thing in a month, and another programmer wrote a similar thing in a year, I'd assume the 1 month project is easier to understand and work with.

Fast programmers writes most shitty code, yes, but that is because fast programmers writes most code period. I have seen nothing to suggest that an average slow programmer actually produces quality code when given the time, it seems to be the opposite, most slow programmers have terrible mental models and create even bigger messes if you give them the time to do it.

Are there slow programmers who produce quality code? Yes, but in my experience those are the exception and are even rarer than fast programmers who produce quality code.

[paleite]

If you tell me a programmer wrote a thing in a month, and another programmer wrote a similar thing in a year, I'd assume nothing about either, because there’s too many parameters at play.

If a project took only 1 month, I’d be very cautious with calling it easier to work with, because it likely means fewer tests (leading to lower velocity long-term) and fewer hours spent by other developers trying to understand it, and giving feedback on how to improve legibility.

Creating something quickly can be really important in specific contexts, but actually KEEPING something flexible to work with, hard to break, and easy to understand is more important when dealing with software that’s supposed to last over many developers and a long period of time.

Maintaining velocity requires you to spend more time on keeping the code base healthy.

I find the notion of being a fast programmer irrelevant in a business-context. Because there I think it’s more valuable to be a programmer that can ensure business goals are met on time, ensuring the correct problems are solved, ensuring contracts aren’t broken, while still keeping the code base professional (i.e. well-tested, clean, consistent).

Being a fast programmer is great and all, but being reliable is the more favorable trait if I had to pick one. Both require huge amounts of active training.