[Jensson]

The thinking pattern "I don't want to get faster, I prefer writing quality code" is a false dichotomy. The fastest programmers writes quality code, since quality code is much easier to get right and working with which are the most important factors for being a fast coder.

[handrous]

This is sometimes true. On a project long-term, will you keep velocity up by writing quality code? Yes. In certain, narrow areas (very "mathy" code, perhaps, that doesn't interact much with he world) might you go faster by writing quality code from the beginning? Maybe.

However, can one also go much faster by: not writing tests one ought to have written; ignoring security issues; ignoring input edge-cases; ignoring output edge-cases; treating a variety of variables as constant, or as having bounds that they actually do not; not writing enough documentation; et c.? Oh my god, yes. Of course.

Anyone who's ever seen a "we're really happy with the output of our outsourced team on this Rails 'app', they've gotten this MVP ready so fast!" codebase knows that's definitely also a way to be fast, and that a team writing actual quality code and not putting in a ton more hours couldn't have matched that team's "productivity", because they'd have been doing way more work.

[Jensson]

That has to do with managers being bad at telling how productive a team is, it is a completely different problem.

[tdeck]

OK, what you're saying definitely applies when we incentivize speed and forget everything else, or when we compare ourselves to others without knowing the whole story. But this current discussion is in the context of someone's personal goals to improve their own productivity from their existing baseline. Valuing that doesn't necessarily mean they have to stop valuing quality or maintainability.

[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.

[jeffbee]

I agree there's not a natural tension between quality and speed, but the speed part is really hard to measure. You must consider the time of all future readers and maintainers of the code you are writing. Spending time to write a test or comment today is an investment that pays back in future fast iteration. Saving time by skipping code review, dashing off weird and confusing interfaces or variable names without revisiting them in a second pass, that type of thing is the opposite: it can appear to save you time today, but is costing you future time.

[Jensson]

> Saving time by skipping code review, dashing off weird and confusing interfaces or variable names without revisiting them in a second pass, that type of thing is the opposite

Nobody here is saying you should do this, it is a strawman. Rather being fast means that you can revisit your interfaces 10 times rather than 2 times, spend more time thinking about your names, have more time to write tests, review everything several times before code review so no issues are found etc, ultimately producing much higher quality code.

It seems like you think this article is about "I write code quickly by not doing things properly", rather than "I practice to become faster".

[jeffbee]

I have no disagreements with the article at all. I only disagree with the idea that "doesn't understand the language/codebase/requirements" can only cause slowness. That condition is at least equally likely to cause the fast solution.

The real "10x programmers" I have known spend practically all of their time deleting and refactoring code. A handful of fake 10x'ers I have met in my career, who enjoyed a reputation of rapidly dashing off MVPs, were stone-cold idiots, one of whom wrecked an entire company with his 10x-ness.