It also reduces cognitive overhead. A lot of people seem to spend a Lot of energy thinking about whether a project needs proper coding or not.
IMHO, this is far better than starting from scratch. Both code and SQL are meant to refactored. Don’t over-engineer from the beginning adding usecases we know nothing about.
In the big, the n-th rewrite will be just as constrained by how much we can keep in our head at the same time as the original attempt. Refactoring essentially means offloading to the computer what you already have in a computer-readable format. What an opportunity!
What I mean with rewriting in the small is taking an existing logic-wart and, while trying to decipher it, taking notes in the form of a rewrite. After finishing the first approximation you take a long, skeptical look at both versions, "is that simple, elegant thing really doing the same?" and then you see the additional corner cases (and/or bugs, sometimes you'll never know) in a clarity that would be impossible to achieve just looking at the original code. It's mostly a reading tool. Sometimes I will trash the rewrite, but often the new version, with the non-obvious bits added will be far more readable than the original because it was written from the perspective of a reader with little knowledge of what the code should do, not by someone deeply immersed in the problem space.
Before this all came to a head, I started doing proof of concept work as command line only. This allowed me to give them estimates they had to listen to, instead of them just assuming that because they could see a UI that we could just pretty it up and ship it next month. Clearly, they reasoned (as if anything they did resembled reason) my two to three month estimate was sandbagging and it was okay to tell the customer we’re almost done.
I got to hear it from the coworker who was best at deadpan jokes, so I didn't believe him the first time when I asked, "Did I miss anything?"
Still there is a huge opportunity cost if getting the wrong code up to production quality prevents working on the next prototype that gets you closer to the right thing. And I’m not talking about best coding practices, but putting in extensive comments, doing a bunch of tests, etc...
I also tend to wonder how often research results are tainted by subtle implementation bugs that may have been more obvious with better coding habits.
A good abstraction requires knowing how you'll be expanding the code (e.g. will there be more images in the future? Hundreds or billions? Or will that feature Y need to be built out?). Building that abstraction right away can definitely slow you down, as you'll be fighting it a lot of the time.
That's not the goal. You want code that can be refactored with reasonable effort.
For example if the number 3 signifies some factor that's used several times over the the code, make it a constant with a descriptive name. This makes even the prototyping easier and whoever takes over the code has a much easier life.
Or don't copy the same 5 lines all over the code with some minor changes but make it a function.
This is really not hard and has huge payoff if you don't overthink it.
And no, the goal isn’t always (or even often) to produce code that can be easily refactored, quite the opposite in practice. This is why having prototypes done in a separate org can be really useful (since they are writing code to serve designer needs rather than production developer needs).
In an IDE I can quickly type out a full function body with 1-character variable names, then run it and see what happens. Immediately after I have seen it work I can go back and rename all of the variable names into something more descriptive. This is also easier now because you know exactly what the variables are used for.
You can do the same immediately for constants (most of the IDEs will allow you to "extract the given expression as a constant on the module level" or alike).
This can never work in a text editor because you need to know how that specific 1-letter tokens.
There is no reason to write non-descriptive code unless you're trying to save maybe 5% of your time. At a job where timelines can easily go orders of magnitude higher than expected, you're trying to shave off a minor portion of your net time spend...
Maybe you save a bit of time during very initial prototyping, when you're just trying to create the exact algorithm for something (eg working with a dozen or so lines of code).
As soon as it's actually used, even if in a "proof-of-concept" prototype, you'll easily spend double that time on cognitive overhead (eg, the next day/week, trying to remember what that variable is) or just in typing out comments. If other people are ever looking at or using the code, it's easily 10x the work you're creating.
Another way of saying this: once your code exists for more than a couple hours, it should have good (not necessarily perfect) variable/function/token names. I agree on the ide vs text editor comment, and add: another nice thing about using a good ide is you can rename the declaration and let the ide update everything else.
I can't write an algorithm without coming up with decently descriptive names for the components. Of course, sometimes I come up with better ones later, but the entire idea of using placeholders is deeply foreign to how I think.
Which isn't to say I don't use single-letter variables, `d` is a perfectly cromulent way to spell delta although `Δ` is better if it's allowed. It's uncommon, and when I do, they're no more likely to change than any other name.
Good enough naming can be tremendously easy, sloppy even, once you've learned which names don't pass that bar. Where naming does get hard, and where inconsistencies become painful, is when you have too many things that could have the same name.
In the wrong context `Foo foo` can be confusing though -- at best this leads to someone reading the code just spending more time, and at worst, it leads to someone modifying the code adding bugs. Just calling it something like `Foo currentUserFoo` is often enough to avoid this, and really doesn't take more than a couple extra seconds to write.
No need to separate it: we just need to keep the minimal good habits all the time!