There are so many things I usually have to do before code organization and abstraction. Figure out how to go from A to B, find out if I really want B, find out if I need to pull this apart into more steps, try variations, read docs to see if there are things that might help me etc.
I find it almost always better to write dumb code like this until I it does what it needs doing. It's much more straight forward, in a very literal sense, to find suitable abstraction and compression from there. DRY is about knowledge representation, not about repetition or boilerplate. Solving the former first in a good way lays the foundation for solving the latter, which can then be done with more powerful abstraction tools such as macros.
Yeah, write unclever code then refactor. Unless you know the domain well don't try to get smart upfront. I do this repeatedly, pushing the abstraction layer higher on each rewrite. I rarely start out with the abstraction first. [Edit: as the abstraction starts to take shape, it feels 'right' and 'elegant' not at all forced]
> I think I read somewhere that the worst code comes from the wrong abstractions.
I'd say no, it comes from cut & paste :) seriously
> I find it almost always better to write dumb code like this until I it does what it needs doing
Same! Then I abstract. But others never get past cut & paste.
> DRY is about knowledge representation, not about repetition or boilerplate
err, isn't it exactly about not repeating yourself? I mean, for the ultimate aim of representing the thing better, don't repeat it everywhere, ergo encapsulate?
From the Pragmatic Programmer (coined/popularized the term DRY):
"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system"
To contrast: Data especially can be very repetitive, say you have a bunch of configurations of somewhat similar things, or you have records that represent purchases at a given time of a thing by someone, they will tend to look very similar, maybe even almost the same
DRY is not about reducing this kind of repetition, because this is just like it should be. Sure, you might want to generate/automate repetitive things or compress them into something more readable and so on, but that's not what DRY is about.
Ultimately it is a form of normalization and decoupling. Ideally you want your code to be in a state so when you change things there is as little coordination required as possible.
DRY really isn't about compressing the data on which your code operates. It's about reducing the number of times your code coordinates the same knowledge about those operations across its text. If you add a field to a record and have to edit the code more than a couple of places to deal with that, you're repeating yourself. If you repeat yourself, those different parts of the code are not only more work to understand and to change, but are more likely to diverge from one another as they are edited in slightly different directions.
I find it almost always better to write dumb code like this until I it does what it needs doing. It's much more straight forward, in a very literal sense, to find suitable abstraction and compression from there. DRY is about knowledge representation, not about repetition or boilerplate. Solving the former first in a good way lays the foundation for solving the latter, which can then be done with more powerful abstraction tools such as macros.