I also think a lot about how I might extend whatever I’m implementing. It’s helped me to make classes more generic and keep things laser-focused so that blocks/methods/classes are reusable.
Nothing grinds my gears like seeing the same block all over a codebase especially if each are just slightly different (time to subclass).
I don't find this helps. More often your assumptions about how something might change are wrong and when the actual change comes in you can end up causing yourself more work undoing the abstractions you made. IMO keep things simple as you can for as long as you can and add in abstractions when they are needed and remove them when they are not. Write code that is easy to change when change is needed, not code that tries to account for all possible future changes as this is impossible to do.
When you're first writing a line of code, you should already be thinking about how you might refactor it in the future, and preparing for that.
This is actually a pro tip.
I also think a lot about how I might extend whatever I’m implementing. It’s helped me to make classes more generic and keep things laser-focused so that blocks/methods/classes are reusable.
Nothing grinds my gears like seeing the same block all over a codebase especially if each are just slightly different (time to subclass).
I don't find this helps. More often your assumptions about how something might change are wrong and when the actual change comes in you can end up causing yourself more work undoing the abstractions you made. IMO keep things simple as you can for as long as you can and add in abstractions when they are needed and remove them when they are not. Write code that is easy to change when change is needed, not code that tries to account for all possible future changes as this is impossible to do.