My recommendation is to start simple and go from there, rather than the other way around. Only build what you need now. Only write the code that fixes the problem. Then optimize/refactor later if necessary and if it will be of benefit (i.e. if it's throw away code for a prototype maybe you don't need to refactor and optimize).
I recognize that some of this comes with practice and experience, so if you still feel yourself going down the rabbit hole, the first step is catching yourself! As I mentioned, timeboxing can be helpful, too. For instance, give yourself an hour to try out a new approach or to figure it out yourself before asking for help.
My recommendation is to start simple and go from there, rather than the other way around. Only build what you need now. Only write the code that fixes the problem. Then optimize/refactor later if necessary and if it will be of benefit (i.e. if it's throw away code for a prototype maybe you don't need to refactor and optimize).
I recognize that some of this comes with practice and experience, so if you still feel yourself going down the rabbit hole, the first step is catching yourself! As I mentioned, timeboxing can be helpful, too. For instance, give yourself an hour to try out a new approach or to figure it out yourself before asking for help.
I also gave a talk on this very subject, which you can watch here: Shiny objects are cool, but so is building products people use