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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
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.
and how you could test it easily! it’s incredible how much it helps for cleaner architectures
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.
This is actually a pro tip.
Except if your adhd includes the perfectionist trait, because then you will never get to write the next line of code.